[Freeipa-devel] Integration with the provisioning systems

[Simo Sorce]

On Mon, 2013-04-22 at 08:48 -0400, Dmitri Pal wrote:
> 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.

+1, go for it!

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York