Grouper Users - Open Discussion List

["Bee-Lindgren, Bert A" <>]

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