The questions is more where to make these changes! Is it useful to have some 
more generic methods on the User class like

 *   getObjectClass
 *   getAuxClasses
 *   setAuxClasses
 *   hasAuxClass
 *   getAttributes
 *   getAttribute
 *   setAttribute
 *   hasAttribute

Is this to LDAP specific ?

Or another approach would be to have some kind of Eventlistener to react on the 
add and update methods. There
you get an LDAP connection and the user object as parameters. You can then 
implement your custom logic there.

More generic is to have access to the methods above and the add and update 
methods must check the extra
aux classes and attributes and reflect them back into LDAP.

Would be nice to have some kinde of configuration which extra classes to handle 
in the web UI. Then there
should be a the possibility to edit there attributes if its not much effort.

Am 18.10.2016 um 16:25 schrieb Shawn McKinney:

On Oct 18, 2016, at 9:15 AM, Patrick Brunmayr 
<><> wrote:

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 
transparent transfer

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 
responsible to

define what kind of schema it want to provide to midpoint. There is no need to 
sync ftPros or something else.

Let’s assume that we decide it’s a good idea to extend the fortress api to 
support custom user aux objects.  What would that change look like?

user add and update methods have some sort of call back for you to add your 
custom attributes to the ldap entity.

What else - user page in fortress web?  Or can midpoint handle the data 
collection part with its UI?


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:

Reply via email to