Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

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: [mailto:] 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