directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <>
Subject Re: Custom object classes and attributes
Date Tue, 18 Oct 2016 13:29:51 GMT

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


View raw message