> 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. * objectclass ( 2.16.840.1.113730.3.2.2 * NAME 'inetOrgPerson' * DESC 'RFC2798: Internet Organizational Person' * SUP organizationalPerson * STRUCTURAL * MAY ( * audio $ businessCategory $ carLicense $ departmentNumber $ * displayName $ employeeNumber $ employeeType $ givenName $ * homePhone $ homePostalAddress $ initials $ jpegPhoto $ * labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ * roomNumber $ secretary $ uid $ userCertificate $ * x500uniqueIdentifier $ preferredLanguage $ * userSMIMECertificate $ userPKCS12 * ) * ) * ------------------------------------------ * </pre> * * 2. organizationalPerson Structural Object Class. * <pre> * ------------------------------------------ * objectclass ( 2.5.6.7 * NAME 'organizationalPerson' * DESC 'RFC2256: an organizational person' * SUP person * STRUCTURAL * MAY ( * title $ x121Address $ registeredAddress $ destinationIndicator $ * preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ * telephoneNumber $ internationaliSDNNumber $ * facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ * postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l * ) * ) But both are req’d semantically inside fortress. The uid for obvious reason, the ou, for ARBAC controls to work. Of course we could not require the user to pass a valid ou on create, and use a default value instead. I have chosen to make it required, specifically to force users to understand the importance of the ou in the first place. So we can change the structural object class, but it will have no bearing on this aspect, as these attributes must still be required. > > 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. > > 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. > > On Oct 21, 2016, at 1:41 PM, Emmanuel Lécharny <[email protected]> wrote: > > But i'm just expressing a concern, which may be addressed - or not - > later on. I just want to be sure that these aspects are being discussed. Your comments are well received. Let’s open a ticket so this requirement can be captured, and specifics of design proposals can be gathered. Thanks, Shawn
