Le 22/10/16 à 15:05, Shawn McKinney a écrit : >> On Oct 21, 2016, at 1:41 PM, Emmanuel Lécharny <[email protected]> wrote: >> >> Le 21/10/16 à 15:56, Shawn McKinney a écrit : >>>> On Oct 20, 2016, at 9:51 AM, Emmanuel Lécharny <[email protected]> wrote: >>>> >>>> One option would be to let the developper to decide which STRUCTURAL >>>> class should be the root of the Users Entries, but that does not fit >>>> well with Fortress, because te 'cn' and 'sn' attributes are mandatory in >>>> te InetOgPerson ObjectClass. Moreover, Fortress is expecing may of the >>>> InetOrgPerson attributeType to be present... >>> Not exactly. Yes, we use inetorgperson as a structural oc, but the only >>> required attributes are uid and ou. All others are optional from the >>> caller’s perspective. >> Then the best possible fit for your ObjectClass would be Account, or a >> flavor of Account. It makes the uid attribute mandatory, and the ou >> attribute as optionnal : >> >> objectclass ( 0.9.2342.19200300.100.4.5 NAME 'account' >> SUP top >> STRUCTURAL >> MUST uid >> MAY ( description $ seeAlso $ l $ o $ ou $ host ) ) >> > Neither inetorgperson nor its parent organizationalperson, require uid or ou > be present.
Shawn, your previous sentence was : "the only required attributes are uid and ou". uid and ou can be added into an inetOrgPerson, but they are not mandatory. My point is that if you make those attribute mandatory, then you have 3 options : - use an existing ObjectClass that makes those AttributeType mandatory (and inetOrgPerson or Account don't fit - and I was wrong to suggest using Account) - define a dedicated ObjectClass where ou and uid are in the MUST part - or enforce the presence of those atttribute prgramatically. My get is that you chose the 3rd option, and it's fine to do so.. >> On Oct 21, 2016, at 1:41 PM, Emmanuel Lécharny <[email protected]> wrote: >> >> Le 21/10/16 à 15:56, Shawn McKinney a écrit : >>>> On Oct 20, 2016, at 9:51 AM, Emmanuel Lécharny <[email protected]> wrote: >>>> >>>> The idea would be for Fortress to still let the user select which >>>> STRUCTURAL ObjectClass to use, and to default to a specific FortressUser >>>> STRUCTURAL ObjectClass, taht would mimic InetOrgPerson (but wth no >>>> mandatory attributeTypes). All teh needed attributes will be defined >>>> into AUXILLIARY ObjectClasses (including cn and sn). >>>> >>>> Fro teh API point of view, thsi is easy, and it will just require a >>>> configuration: the STRUCTURAL to use. >>>> >>> I’m not opposed to this idea but it will be a lot of work and has potential >>> to make fortress complicated and brittle. >> Why is that ? > A longstanding axiom in computer science: > > Static (simple / easy) <—————————————————> Dynamic (complex / hard) > > That is making things dynamic necessarily makes them complicated. Here we > would have to establish a metadata to describe the mapping between attributes > in the logical and physical data model. This would make things more > complicated. That mapping will not always be right as users will get > confused on how it works and make mistakes, that will make it brittle. > > I am not opposed to making a change like you suggest, i.e. pluggable > structural object class, but we must understand where the complications are > in the design in order to decide if the change is worth the trouble. That's a choice I won't argue with :-) > >> On Oct 21, 2016, at 1:41 PM, Emmanuel Lécharny <[email protected]> wrote: >> >> Le 21/10/16 à 15:56, Shawn McKinney a écrit : >>> Speaking of, that would be my design criteria, if it increases either by >>> much, I will not be in favor. >>> >>> Inetorgperson is far from perfect but it is the closest thing we have to a >>> standard entity model for user in the computing world. The SCIM standard >>> is largely based off of it. Speaking of, where does it fit in this >>> discussion? >> It's all abot forcing the application to have a User that has to >> implement an ObjectClass, above another. If one aplication based its >> user on top of a specific ObjectClass, not inheriting from >> InetOrgPerson, then they will have to redisign the application to use it >> with fortress - or add some glue in the API calls... >> >> As an API, we should probably avoid any adherence that makes it difficult > I understand the rationale and don’t disagree with your logic. What I don’t > understand is the need, as in who needs this today? My assumption is > everyone is perfectly happy with our adherence to inetorgperson thus there is > none. So it's fine. I just wanted to open teh door a bit more for the future requirement of some users. That would be appropriate to discuss the need later on (3.0 or later). -- Emmanuel Lecharny Symas.com directory.apache.org
