[Freeipa-devel] Integration with the provisioning systems
Dmitri Pal
dpal at redhat.com
Mon Apr 22 12:48:24 UTC 2013
On 04/22/2013 07:34 AM, Martin Kosek wrote:
> On 04/21/2013 09:14 PM, Dmitri Pal wrote:
>> Hello,
>>
>> Please review the design page for the following ticket:
>> https://fedorahosted.org/freeipa/ticket/3583
>> http://www.freeipa.org/page/V3/Integration_with_a_provisioning_systems
>>
> Hello Dmitri,
>
> The design looks fine, I would just like to discuss the schema enhancements.
>
> I'd propose to not create our own artificial attributes, but rather use a
> standard existing userClass attributeType defined in RFC 4524 which is already
> present in 389-ds schemas and which semantics seems to match what we want:
>
> ...
> 2.25. userClass
>
> The 'userClass' attribute specifies categories of computer or
> application user. The semantics placed on this attribute are for
> local interpretation. Examples of current usage of this attribute in
> academia are "student", "staff", and "faculty". Note that the
> 'organizationalStatus' attribute type is now often preferred, as it
> makes no distinction between persons as opposed to users.
>
> ( 0.9.2342.19200300.100.1.8 NAME 'userClass'
> EQUALITY caseIgnoreMatch
> SUBSTR caseIgnoreSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
I tried to find something like this but I did not see this attribute as
a part of the object classes used for user accounts ("person" and
derivatives).
This would perfectly match the need and would not require a creation of
the new attribute.
Ack!
>
> The DirectoryString (1.3.6.1.4.1.1466.115.121.1.15) syntax and the
> 'caseIgnoreMatch' and 'caseIgnoreSubstringsMatch' rules are described
> in [RFC4517].
This is fine to. And it is MV which is good.
> ...
>
> What about simply adding this attributeType as a MAY attribute for ipaHost
> objectClass?
I was thinking about this too but then we would have it in a bit
asymmetric way.
I am fine with that too.
>
> As for user objects, what about adding new auxiliary objectClass called ipaUser
> storing miscellaneous attributes like this one?
This is fine except this is much more intrusive.
I was looking for a very simple, low cost fix that can be added with
very limited impact.
While creation of the ipaUser is probably the correct step it sounds a
bit bigger than I want it to be for now.
>
> Or is there a benefit of having a specialized objectClass holding just this one
> MAY attribute?
No.
So here is what I suggest:
Split the ticket into two steps (tickets):
Step 1: add the userClass attribute to ipaHost - do it now. That should
be a very low impact change.
Step 2: sort out the right class hierarchy for user - this is a
candidate for next round of refactoring.
Step 1 is the only requirement at the moment so let us go just for it.
>
> Thanks,
> Martin
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
More information about the Freeipa-devel
mailing list