Grouper Users - Open Discussion List

["Black, Carey M." <>]

Chris,

 

Thanks for the quick and concise reply.

 

Maybe I am thinking about the Subject API a bit sideways… so let me try to confirm a few “core” concepts too.

 

1)      Grouper entities are one of three types ( ‘Person’[users}, ‘Application’, or ‘Group’ ).

 

2)      Every entity in Grouper must have one and only one ‘Subject ID’.

a.       The ‘Subject ID” can conceptually be thought of as a “RDBMS Primary key” for the entity in Grouper relative to the Subject API that created the entity. (Yes there are internal GUID used to link the entity’s together, but those are “grouper made up aliases for internal use” for the Subject ID values. )

 

What I am not sure about is if each “Subject API”(connected system) keeps its own ‘Subject ID’ on each entity when the entity exists in more than one source/destination system. ( Thinking more like having “RDBMS Foreign Key to the external system”, where an entry might have one for each “Subject API”, and/or PSP/PSPNG connection for the entity. The value would still be unique in the FK values from each ‘Source’ space, but the values would not be unique across all sources/FK values. )

 

3)      Every entity has a set of “Subject identifiers” ( Stored in Grouper [ I hope ], or fetched in real time?) from the Source system via the Subject API.

                This functions to provide “other strings” that help make the entity human relatable. ( Things like Fist name, last name, user names, etc…)

                I don’t yet know how many, what data types, etc.., etc… “limits”/”rules” exist for “additional identifiers” on an entity in Grouper.

                I don’t yet know if these things can be used during membership publication. (PSP/PSPNG)

 

4)      All entities ( supplied from any Subject API) are available to all other entities in the Grouper system.  There is no inherent way to limit entities from specific sources  (“A, b and C ONLY”) from a given folder/group level down. I am guessing it could be down with custom hooks or notification code based processing during membership changes, but not baked into the app at this time.

 

 

 

 

So back to my original questions…

 

1.       RE: 1: GUID vs IDM identifier

 

For our environment, all users (currently planned to be brought into Grouper) will be from our IDM system. And as a general rule, all of those users have both a IDM identifier (custom attribute added for our business reasons) and a GUID (created by the IDM system/tech). This set does contain “external people” who are registered with the IDM system.

 

Also, most users have no idea that they have an IDM identifier value nor its value. So it is virtually as opaque as the GUID, but shorter and would be easier to share.

 

If (and I think this is a big if for our current plans) an additional source of users is identified to be brought into Grouper then how would any overlap between those sources/sets work in grouper?

I am left with the impression that it does not work out well.  (REF:  https://spaces.internet2.edu/display/Grouper/Subject+API  “You should not have the same subject in more than one source.” ß should that “subject” be “Subject ID” or entity?)  And that this condition should generally be “an IDM system function to resolve”.

 

I am not sure if I should be concerned about these later events before I select the Subject ID from our IDM system or not?

                There might be a time that Grouper is later asked to help out an application to manage “local accounts”/”groups” too. The “local accounts” may not be sourced from our IDM system. ( At this time, I am not sure how to avoid “duplicate user’s” in grouper for those cases either. Assuming that IDM is also working with that application or if the application uses the same identifier as IDM for the “non-local” accounts.)

 

2.       Lookup up provisioning target IDs

So if a grouper group has 500 members ( or some really big size, 10,000+) then it sounds like grouper needs to do a lot of searches to find each user’s DN via the PSPNG-LDAP provisioning. ( I would hope that single user membership change in a large grouper group would not require the whole group membership to be checked, but that is just an assumption on my part at this time.)

 

I am not sure that I can depend on the users ‘Subject ID’ (from IDM) always being in all of the possible downstream systems that Grouper might need to manage groups in.  Especially if I pick the GUID. The IDM GUID is currently only sent to very few systems. I was kind of expecting to need to bring in several “keys” (and keep them as “subject identifier attributes” in the entity) from IDM for all of the users, and then “send out” the correct key (AKA: “subject identifier attribute” ) for the target PSP/PSPNG system based on the data that system has/needs.

 

 

FWIW (in terms of understanding what I am trying to do with grouper at the present time):  At this point I am expecting two “outbound” connection types: “RDBMS tables”, not “RDBMS users/roll”(but maybe someday in the future),  and possibly LDAP groups to be Grouper’s outputs.

 

 

--

Carey Matthew

 

From: Hyzer, Chris [mailto:]
Sent: Wednesday, February 8, 2017 5:27 PM
To: Black, Carey M. <>;
Subject: RE: Guidance request... Subject API ( type= User ) ... How to best pick a Subject ID value from an IDM system.

 

1.       GUID vs IDM identifier

 

I think they both can change or migrate, so seems similar.  I agree GUID seems slightly better.  At penn we use IDM identifier and it has been fine.  The “memberChangeSubject” utility is how you change the subjectId from something to another.  Is there ever a case were an entity would have one and not the other?  E.g. external people?  Maybe they have a GUID and not an IDM identifier?  If that is the case then def pick GUID.

 

2.       Lookup up provisioning target IDs

 

Is there a way to look up users in LDAP based on one of the subject identifiers in the subject API?  If so then the PSPNG can lookup the user based on that, and translate to the directory id.  Ok?

 

Thanks

Chris

 

 

From: [] On Behalf Of Black, Carey M.
Sent: Wednesday, February 08, 2017 5:04 PM
To:
Subject: [grouper-users] Guidance request... Subject API ( type= User ) ... How to best pick a Subject ID value from an IDM system.

 

Hello All,

 

First let me say that I am new to Grouper. I have been doing some reading/video/scratching my head. I think I have a few questions worthy of asking someone who knows much more about Grouper than I have been able to gleam from the docs.

 

As I am starting out I am trying my best to plan out the Subject API data and make sure I don’t make too much of a mess in the initial attempt.

 

Question 1:

Quoting the docs here ( https://spaces.internet2.edu/display/Grouper/Subject+API )

“

Subject ID: should be unchangeable, unrevokable.  Usually this an opaque id (number or uuid etc).  The source that a subject is associated with also should not change.

Subject Identifier: anything that can refer to a subject uniquely.  Usually these are netIds, eppns, etc. 

“

 

I have LDAP access to our primary IDM system. ( good )

And I have two possible identifiers that I can use for the Subject ID value for our users. I think each have pros/cons and I wanted to bounce that off this list.

                Option1 : GUID

                                                Value is unique in the IDM data set.

                                                It is really hard to have an IDM admin muck with over time.

                                                (So “unchanging over time”, and Unique.)

                Option2: IDM Identifier

                                                Value is mostly unique in the IDM data set.

                                                                The “mostly issue” is < 0.1% of the data set. It really is a “early days” problem for the identities too. If they “survive 24 hours” then they likely will not fall into that whole.

                                                Also, it is possible to have an IDM admin muck with the value over time. However, it is also not a “standard practice” either. And does happen from time to time due to IDM exception processes.

                                                ( So “mostly unchanging over time”, and “mostly unique”. Except for when it “needs to be changed” to fix IDM process problems. )

 

 

My heart/gut points me to using the GIUD.

                However, I expect to have those “IDM process problems” (from time to time) possibly turn it to a request to “move all groups from GUID1 to GUID2” as well.

                So is there a way to “correct”  the “Subject ID” values over time? (What does it look like? How does it work?)

               

                Maybe I am over thinking all of this?

 

 

 

 

Question 2: How do entity (type = User) in grouper support N outbound “subject ID values”? ( In the context of using the subject in “downstream systems” to grouper.)

 

NOTE: I have not yet read up on the PSP side of this process….

 

Assume that:

                Grouper gets Users only from IDM.

                                and

                Grouper is the source of a Group that is to be distributed to N(let’s say 3) LDAP systems.

 

                I am not clear on the details of how an entity (type = User) would “find” or “know” the DN’s for the user in each of the downstream LDAP systems.

 

                More detailed for this example/question ….

                                Group in group is called “Special users”. It has 3 users in it. ( Bob, John, and Sally)

 

                                The “Special Users” group exists as 3 different DN’s in the downstream LDAP services:

                                                LDAP1: cn=special,ou=groups,ou=top

                                                LDAP2: cn=very-special,ou=groups,ou=other-top

                                                LDAP3: cn=Not-special-here,ou=groups,ou=still-other-top

 

                                Each user  exists as 3 different DN’s in the downstream LDAP services:

                                                Bob:

                                                LDAP1: cn=bob,ou=users,ou=groups,ou=top

                                                LDAP2: cn=bob,ou=bad-users,ou=other-top

                                                LDAP3: cn=bob,ou=good-users,ou=still-other-top

 

                                                John:

                                                LDAP1: cn=john,ou=users,ou=groups,ou=top

                                                LDAP2: cn=john,ou=odd-users,ou=other-top

                                                LDAP3: cn=john,ou=normal-users,ou=still-other-top

 

                                                Sally:

                                                LDAP1: cn=Sally,ou=users,ou=groups,ou=top

                                                LDAP2: cn= Sally,ou=,more-users,ou=other-top

                                                LDAP3:     Just for fun, let’s say the user does not exist in this ldap.

 

                                I can understand how the Subject API for each of the LDAP services could maybe be mapped to the grouper “Special users” group. (matching somehow… TBD…)

 

                                What I don’t understand is how the User’s DN’s are found/stored? (So that the memberships in grouper can be expressed in each of the target LDAP systems.)

                                                Does Grouper need Subject API connections to any destination system for all types of data (users, groups) that it is managing in addition to the “PSP” connection to do the provisioning?

                                                                So that the subject API can pull in the Subject ID for each User and group?

                                                                If so, then how does grouper know that “this PSP connection” should use “That subject API connection’s subject ID value” to publish data here?

 

Thanks in advance for any helpful replies.

 

--

Carey Matthew