There are more things to take into account
1. Objects like roles, groups and users should be extendable via aux
classes and attributes ( thats what the discussion is all about )
2. As an integrator i would flag all roles, groups and users which i
want to expose with a custom object class like "exposeMidpoint"
3. In my connector software i would just filter all those objects from
fortress which have an aux class "exposeMidpoint"
So basically its that what you are saying :)
The background to this is for example i don't want all the fortress
roles like ( fortess-web-super-user, fortess-web-super-user, etc ) to be
transfered to midpoint. If this would be possible
someone could gain access to fortress by assigning them the needed role
( if they would be allowed to ). The second point is i don't want to
provide options like roles to users which are not of
interrest for them :)
Hope this describes it
Am 24.10.2016 um 14:43 schrieb Shawn McKinney:
On Oct 24, 2016, at 1:34 AM, Patrick Brunmayr <[email protected]> wrote:
No the other way round! I would decorate Fortress roles and groups with
an additional objectclass to have some
filter possibilities. Basically in my connector i would only query
objects from fortress having aux class "exposeMidpoint"
to only expose those roles and groups. Not everything in Fortress should
go to Midpoint :)
OK I’m starting to understand. One more question….
The discriminator must limit which objects of a particular type will be
processed? In other words not all roles (or groups) within a fortress DIT need
be processed by MP, but only a subset of each.
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]
