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/apidocs/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]
