It's not important, it's just very convenient. Le vendredi 21 octobre 2016, Patrick Brunmayr <[email protected]> a écrit :
> Some very valid aspects here :) > > The kind of question is what makes InetOrgPerson so important ? In my > understanding a basic user is > > about uid and a password. Thats very abstract but the minimal form of a an > identity > > > Am 20.10.2016 um 16:51 schrieb Emmanuel Lécharny: > > Some thoughts about Users and fortress (I have read teh full thread, and > there are many aspects being discussed, I'd like to provide some general > ideas here, nt to reply to any specific question). > > > Fortress uses its own AttributeType and ObjectClasses, and relies on > existing ObjectClasses : typically, InetOrgPerson for Users. The other > Fortress objectClasses are AUXILLIARY, and taht allows any entry to be > extended with attributes that are no conflicing with any STRUCTURAL > ObjectClass. > > > The thing is that an Entry in LDAP *must* have a STRUCTURAL ObjectClass, > otherwise you won't be able to add it. This is the reson Fortress is > using InetOrgPerson. > > > Now, that does not fit everyone, because you may want to use a different > STRUCTURAL ObjectClass, and that is not possible if it's not inheriting > from InetOrgPerson in this case. > > 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... > > > 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. > > > From Commander POV (the UI), that is a different story. The point being > that it's impossible to anticipate all the possible needs for all the > possible application out there. One solution would be to expose the User > using a tabular representation, regardless of the attribute content and > order (that means we lose all teh semantic). Anothe roption, way more > complex, would be to define templates that will be specific : they will > tell teh GUI what and how to expose the data. This is definitively be a > very complex change in Commander... > > > Bottom line, I think some changes are required in Fortress, to stp using > InetOrgPerson. Changes in Commander are certainly going to be heavy... > > > Le 18/10/16 à 11:30, Patrick Brunmayr a écrit : > > > Hi > > In my understanding Apache Fortress claims the sovereignty over creating > users. Thats just fine but i see a problem here. After reading the > docs here > > https://directory.apache.org/fortress/gen-docs/latest/apidoc > s/org/apache/directory/fortress/core/AdminMgr.html#addUser- > org.apache.directory.fortress.core.model.User- > > > there is no way of assigning custom auxialiary object classes or > attributes to the user. The user just represents inetOrgPerson which in > most of the cases will be fine. > > In our scenario users MUST have two extra auxialiary object classes and > some extra attributes set to be a valid user. ( I know about ftProps but > these represent no attributes ) > > I am writing an adapter which transfers users from different systems > into Apache Fortress by using the AdminMgr. My problem is calling > addUser may create a valid inetOrgPerson object > > but not a valid user object for our system. I would need to make an > extra LDAP call to assign this object classes and attributes. This would > even make the web interface quite unusable for our admins > > beacause we can not manage our users on a central place. Apache Fortress > may create a valid inetOrgPerson but i would need an extra UI or config > tool to set the other > > object classes. > > > What can i do about this ? > > Thank u > > > LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste > A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, > E-Mail: [email protected]<mailto:[email protected]> > > > > > > > > LINZ AG für Energie, Telekommunikation, Verkehr und Kommunale Dienste > A-4021 Linz, Wiener Straße 151, Postfach 1300, Tel. +43/732/3400-0, > E-Mail: [email protected] > > > -- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
