We manage many accounts for many different kinds of users with different organizational affiliations and institutional agreements. When we set up one (or more) IdP services against these accounts we need to determine which accounts should be used where and what kind of migration strategy we want to employ.
#1 Updated by Ben Leinfelder over 9 years ago
Trees to consider:
ou=Account (1000+ users)
o=MSU (14) -- recommend ignoring these accounts
o=LTER -- they have set up their own IdP and those users should use that for authentication
o=PISCO -- consult with them about direction to go. Perhaps they would like to become an IdP as well.
o=SANParks -- perhaps roll them into our larger "KNB" IdP. Need to consider international policy here.
o=SAEON -- similar to SANParks. Consult with Judith and Victoria about this
o=UCNRS (126) -- they may be using these accounts for other operations within their organization
#2 Updated by Ben Leinfelder over 9 years ago
- Assignee changed from Ben Leinfelder to Matthew Jones
Proposal for preparing NCEAS IdP:
Use ou=Account as the root for the NCEAS IdP¶
Move accounts from o=XXX into ou=Account where uid does not collide and the user should continue to have affiliated status with NCEAS.¶
If account from o=XXX exists in ou=Account use the latter and reset password¶
Map all ou=Account accounts to the old o=XXX identities using a pre-computed CILogon DN (from them)¶
Maintain additional IdPs for each distinct organization we wish to support so that we keep them distinct and can provide identities at different levels of assurance (basic vs silver, etc).¶
Notably, o=unaffiliated contains the bulk of our accounts but with no assurance that they are real people with useable email addresses. This is very different than the o=NCEAS tree which is well-curated and contains people with which we largely have first-name familiarity.¶
By maintaining o=unaffiliated as an independent IdP we let our existing user base continue to access their account, but via a different mechanism.¶