Grouper Users - Open Discussion List

["Hyzer, Chris" <>]

Thanks Tom, to expand on this:

 

In subject source – speak:

 

The subjectId is the opaque personId

The subjectIdentifier is any of the things Tom said that uniquely identifies that user for that source (AccountId, CardId, eppn, etc)

When searching freeform, you can filter things (like only show active people), or you can put a rule on a folder that restricts certain populations to be added to groups.  Also you might be able to only allow certain types of users to see fringe population in the subject source.

 

Not sure what your question is about the loader.  What makes the loader difficult in this setup?

 

Yes, one grouper is best J

 

Thanks

Chris

 

From: [mailto:] On Behalf Of Tom Barton
Sent: Tuesday, July 05, 2016 9:56 AM
To:
Subject: Re: [grouper-users] Person and Account Subjects

 

Hi Bert,

I assume you've got a "PersonID", the fundamental identifier for People, and that you are able to realize mappings from PersonID to AccountID and from PersonID to CardID. These may be multivalued, or null valued for some values of PersonID. And that all of these are uniquely identifying, ie, a given non-null value of AccountID is associated with at most one PersonID and similar for CardID. If all that's the case, you can present your Grouper instance with a representation of your registry as one that contains People with associated identifying Accounts and Cards, as attributes of the People. All group memberships would be in terms of PersonID, but members can be picked using that or AccountID or CardID, and memberships can be provisioned into downstream systems using any of those identifiers.

Does that help?

Tom

On 7/3/2016 1:34 PM, Bee-Lindgren, Bert A wrote:

This email is seeking information, experience and advice about representing Subjects that have relationships with other Subjects: People and the Account(s) issued to them.

 

Background:

At Georgia Tech, we separately model People and Accounts within our IdM and Person Registry, with different multiple sources of people (eg, "Regular," Guests or Applications/Services) and with links from Accounts to People as well as between certain types of People (eg, From Guests to Sponsors). This People+Accounts model represents situations where a Person might have different number of accounts:

* 0 Accounts: eg, Alumni before email-for-life, Recruiting Prospect, Incoming Employees, Summer-Camp Participant, Catering Vendors, employees of related or space-leasing businesses, etc

* 1  account: eg, normal, active GT Person, or 

* >1 accounts: eg, admin accounts, file-/resource-ownership separation for student-employees, testing accounts, person deduplication, or name changes. 

 

While separating people and accounts has some advantages, it is unusual and can  increase friction when integrating with off-the-shell systems, like Grouper. Hence, this email....

 

 

Our active migration from a homebrew Authz system to Grouper is focused on Physical Access/Door Controls (fwiw, we'll talk more about this at the next IAM Online). For better or worse, this brings most of our Zero-Account use cases into the forefront as there are many people with physical access that do not have computer accounts. Here is what we think we know about People & Account Subject Sources:

 

1) Door-Access groups only need to contain People... which can be mapped to their ID Card (BuzzCard) Number... which can be provisioned into our person repository and then into the door-access system.

2) Manual additions are easy: The custom, grouper-api-using Door-Access UI can keep additions scoped to Person subject sources

3) Loaded Groups bring most of the Person/Account complexity, but also provide ~70% of the benefit we expect from doing door-access in Grouper (The other 30ish% is transparency/auditability as well as automated cleanup of manual additions).

 

So, what to do with Loaded Groups??? We have three ideas:

a) Have two groupers -- Person & Account -- and have the Person-Grouper Loader populate loaded groups with Person Subjects. (Fwiw, Person Groups become Loaded Groups in the Account Grouper and, maybe, vice versa... whee).

 

b) Have a single grouper:

b1) Have multiple sets of Loaded Groups (People, Accounts, PrimaryAccounts), and pull in the people groups into the Door-Access groups and pull the others into whatever types of subjects the group wanted. (We'd probably use Attributes and Hooks to keep manual additions scoped to the correct Subject source when the normal grouper UI is used.) Or

b2) Have a single set of Loaded Groups into which both Person & Account subjects are loaded. The Door-Access groups would just pull them in, and (an enhanced) PSPNG could just ignore the account subjects, likely based on a member-filtering or member-adjusting attribute. Other (non-door-access)  groups could define other pspng attributes to get the subjects they wanted provisioned downstream.

 

We generally like the idea of having a single grouper as well as a single set of loaded groups. But we worry that it is too weird... eg, to have such filtering provisioning or, similarly, to have members of all these groups stored and shown in Grouper that aren't really member-eligible subjects.

 

Thanks for reading all of this and a double-thanks for any thoughts or advice you can share!!!

 

Sincerely,

  Bert Bee-Lindgren

  Georgia Tech