> On Oct 18, 2016, at 4:30 AM, Patrick Brunmayr <p.brunm...@linzag.at> wrote:
> 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.

Correct, inetorgperson + password + groups / roles

> On Oct 18, 2016, at 4:30 AM, Patrick Brunmayr <p.brunm...@linzag.at> wrote:
> 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 )

correct again, props are just name / value pairs.

> On Oct 18, 2016, at 4:30 AM, Patrick Brunmayr <p.brunm...@linzag.at> wrote:
> 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 ?

There are a couple of ways to look at this problem.

1. fortress as the caretaker of all the user attributes.

2. some other system as the caretaker of fortress attributes

I am open to the idea of adding an extension mechanism that would allow adding 
custom aux classes into user add / updates.  The amount of work is non-trivial 
but not particularly difficult or unusual.  Of course this would have to extend 
past the core into the rest and web components.

But the 2nd option is probably the sensible approach.  You mentioned midpoint 
recently.  We don’t know how to get it to manage fortress style attributes yet 
but assuming it’s doable and considerably less than work than option 1.  

The Penn State team uses a SCIM services to combine their edu attributes into 
fortress (or perhaps vice versa).  Some of that code has recently been donated 
to this project and forms the basis of SCIMple.

In any case it’s a very good question.  I’d like to hear from the community 
what they think the best approach is.


Reply via email to