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.
The reason i asked this question was like you mentioned my Midpoint
integration. I theoretically know how to do it. You have to write a custom
connector like in the docs here.
The connector's task is just to sync back and forth objects from its source to
Midpoint. Thats were the AdminMgr comes into play :)
Whenever i am getting an event of "user creation" i need to pull data out of
the Midpoint object and then call the AdminMgr methods like addUser.
That just solves the basics. But currently if i would need to add some extra
information ( like aux classes or attributes ) i would have to open an extra
ldap conenction to update the
user object in the DIT. Thats just a bit of overhead because in the background
Fortress will also make a LDAP connection to create the user.
In my understanding Midpoint should not be responsible to take care of fortress
attributes like ftProps or something else. Its up to the connector to make a
between the two systems in an API like way. So whenever something needs to be
altered in Fortress the way should be via the AdminMg. Also the conenctor is
define what kind of schema it want to provide to midpoint. There is no need to
sync ftPros or something else.
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: