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
