Grouper Users - Open Discussion List

["Black, Carey M." <>]

Dominique,

The general idea of mapping one Subject ( Subject API ) to N accounts ( target objects in a downstream system) is very appealing to me. And I suspect others too.

However, there are some real challenges to sort out with an implementation of such a feature. And I think they all have their own downsides. But mostly it becomes a very complex map.

 

Your suggestion of using subject attributes has been discussed. And that is certainly one way to do it.

 

I think the downside of that approach is the scale of attributes that Grouper would need to be aware of as well. And the organizational management of them.

                Keep in mind that Grouper does not cache all subject attributes. Rather the project works very hard to not do that. And let the values change in the authoritative systems whenever they need to change. Which means that Grouper only “notices the changed values” the next time an event or maybe when a full sync happens.  (And it means that all those values need to be “looked up” during an event/full sync too. )

 

That design also brings with it the challenge that the Subject might have the attribute, but for some reason in a specific downstream provisioning system the user should only have N-2 of their total identifiers provisioned.  ( Due to attribute reuse, and or restrictions on a system or the Subject. )  So it become more challenging to know which attribute values, for which subjects should be provisioned or not. And how to “prevent some values” vs allowing all values.

 

 

 

 

The more I have thought about this problem the more I tend toward a different approach.

                I think “Accounts” ( Subjects local to a target system ) are likely better “imported” as Local entities in Grouper when they DON’T match the provisioner’s subject single attribute map.

                                This way the Subject API can feed one and only one Account per system.

                                And if “other local accounts” need to be managed they could be “loaded” into a space in Grouper to give them “subject IDs” that are specific to that system.

 

                Add to that: a possible feature in the provisioner/groups that would “auto-pull in” memberships from the Local entities, or maybe “suggest adding additional members when a Subject is added manually”. And I think it approaches a full solution to my eye.

 

NOTE: Local Entities in Grouper are “just a group” that can have a maximum of zero members. And it can have attributes associated with it in Grouper too.

That attribute map (between Subject and Local Entities for this provisioner ) is how the “Auto-pull in” logic could be mapped and work. Bring attributes from the connected system when the Local Entity is created and synced. When a subject ( with subject.attribute.foo=“X123” ) is added to a group see if any “local entities” are tagged with ‘ foo=“X123” ‘ and auto add them too. (or not based on config of the provisioner/group).

 

It also allows for the idea that some provisioners could create objects in the target system for “non-personal accounts” (but a distinct type/function of account in the target system) that could be “back synced” into the provisioner Local entities set too. ( AKA: Subject attributes could still provision on a “one to one basis” for each provisioner. And you can have as many of those as you want. You would need to make them “non-overlapping” in the target system too. A task left for configuration/deployment design for the given target system.)

 

I think that splits the hairs in the “right way” and allows for “service accounts” that do not map to external “Subject API” sources too. ( Does not add more Subject API connections in the process. 😊 ) Yes it means “more groups” and “more attributes” but those are “internal sources” and don’t require external lookups/maps to find them.  Sure, attribute sync processing too, but some of that “sync work” seems unavoidable if you want the connected system to be authoritative for anything. 😊

 

Just my two cents on the topic.

 

--

Carey Matthew

 

From: <> On Behalf Of Dominique Petitpierre
Sent: Tuesday, September 29, 2020 10:52 AM
To:
Subject: Re: [grouper-users] PSPNG: synchronize one Grouper group member to two target directory group members?

 

Hello,

 

I was asking

 

On 18.09.20 06:44, Dominique Petitpierre wrote:

- Is anybody interested as well?

Well, two people were, long time ago:

Ldappc should have option to ignore elements in LDAP that are outside of some name space

https://todos.internet2.edu/browse/GRP-343

 

May be they were able to do this with the attribute resolver in PSP.
In PSPNG it is possible for groups but not for users (memberships).

 

Since  a replacement for PSPNG is being developed:

- what keyword or other indication should  be used in JIRA to log a similar request so it is related to the successor of PSPNG?

 

Thanks in advance for your answer.

 

Regards.

 

On 18.09.20 06:44, Dominique Petitpierre wrote:

Hello again,

 

for such a selection what could be used  are properties analogous to groupSelectionExpression and allGroupsSearchFilter:

 

subjectSelectionExpression to select the subjects of a Grouper group to consider for synchronizing
e.g. ${subject.attributes("employeeType").equals("student")}

 

allMembersSearchFilter to select which target members can be mapped to subjects and to exclude members that should not be removed from the target group
e.g. (employeeType=student)

With something like this many provisioners could provision the same group.
Each provisioner would only synchronize the subset of the Grouper members they care for, thus avoiding the expensive one to zero correspondence check.

 

This, together with a method containsAttribute, would allow to do what I was describing in my original post (cf. [grouper-users] PSPNG: synchronize one Grouper group member to two target directory group members?):
Two provisioners, one taking care of the student members and the other of the staff members in the same target group could be configured with the following properties:

changeLog.consumer.activedirectory_student.subjectSelectionExpression: ${subject.attributes.containsAttribute("employeeType","student")}

changeLog.consumer.activedirectory_student.allMembersSearchFilter: (employeeType=student)

changeLog.consumer.activedirectory_staff.subjectSelectionExpression: ${subject.attributes.containsAttribute("employeeType","staff")}

changeLog.consumer.activedirectory_staff.allMembersSearchFilter: (employeeType=staff)

The configured selections insure a one to one correspondence of the members in each provisioner (in the target directory student and staff persons have separate entries, each either student or staff but not both).
This preserves the current behaviour of PSPNG that does not handle one to many correspondances . But it allows the resulting target group to have one to many correspondences with members of the Grouper group.

If feasible and sound, I propose this as a Request For Enhancement for PSPNG, as a fallback alternative to the one to many correspondences RFE proposed in my recent post (Re: [grouper-users] PSPNG: synchronize one Grouper group member to two target directory group members?).

- Is anybody interested as well?

Regards.

 

On 14.09.20 10:02, Dominique Petitpierre wrote:

Hello,

 

On 10.09.20 04:07, Dominique Petitpierre wrote:

Alternatively,
- is it possible to have two provisioners, one taking care of the student members and the other of the staff members in the same target directory group?
(I don't quite see how full sync would work but asking just in case I am missing something!)

- Is it possible to select which Grouper group members should be synchronized? (eg. only students or only staff members)

If both source and target members could be selected, then such two provisioners could work.

 

-- 

Mr Dominique Petitpierre, user=Dominique.Petitpierre domain=unige.ch

IT Division, University of Geneva, Switzerland

 

-- 

Meilleures salutations,

Dominique Petitpierre

* Unsolicited commercial email is NOT welcome at this address. *

Mr Dominique Petitpierre       Email: User@Domain

IT Division                    User=Dominique.Petitpierre

University of Geneva                  Domain=unige.ch

24 rue General-Dufour          Voice: +41 (0)22 37 97117

CH-1204 GENEVA                 Fax  : +41 (0)22 37 97986

(Switzerland)                  WWW  : http://www.unige.ch/dinf/