Project

General

Profile

Task #3513

Task #3394: Deploy Shibboleth provider for KNB LDAP accounts

Task #3395: Deploy Shibboleth instance at UCSB

Determine accounts to include for KNB IdP

Added by Ben Leinfelder over 8 years ago. Updated almost 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
2013-01-23
Due date:
% Done:

100%

Milestone:
None
Product Version:
*
Story Points:
Sprint:

Description

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.

History

#1 Updated by Ben Leinfelder over 8 years ago

Trees to consider:

ou=Account (1000+ users)
o=NCEAS (469)
o=KU (32)
o=MSU (14) -- recommend ignoring these accounts
o=NAPIER (4)
o=OBFS (66)
o=OSUSB (7)
o=SDSC (27)
o=unaffiliated (5000+)
o=UVM (3)

Referrals:

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 8 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)

Other considerations:

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.

Referrals:
TBD

#3 Updated by Ben Leinfelder over 8 years ago

  • Target version changed from 2013.2-Block.1.1 to 2013.10-Block.2.1

#4 Updated by Ben Leinfelder over 8 years ago

  • Parent task changed from #3394 to #3395

#5 Updated by Ben Leinfelder about 8 years ago

  • Target version set to 2013.10-Block.2.1

#6 Updated by Ben Leinfelder about 8 years ago

  • Target version deleted (2013.10-Block.2.1)

#7 Updated by Ben Leinfelder almost 8 years ago

  • Status changed from New to Closed
  • translation missing: en.field_remaining_hours set to 0.0

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)