ACOnet Identity Federation Policy Experiences

Transcription

1 ACOnet Identity Federation Policy Experiences Peter Schober ACOnet TERENA 4 th GN3 Symposium October 2012

2 Agenda 1. The Politics behind Federation Policies 2. Tales from a Federation Operator: On-boarding of prospective members 3. Identity Assurance

3 1. It all depends (?) The Politics behind Federation Policies Policies reflect their political/contextual surroundings Also true for the policy template Your experience/context is probably still missing

4 It all depends, 2 The Politics behind Federation Policies Eligibility: Be as inclusive or neutral as possible Don t limit eligibility too early/narrowly: Research & collaboration doesn t stop at NREN member / regional / sectoral boundaries Aim for ubiquity from the beginning Some use cases will only come if you have the potential for 100% (of whatever) While still being a Trust Framework Provider Modular policy and approach

5 It all depends, 3 But there are recurring themes There s (academic) life beyond your Federation Create/modify local Policy by looking at others You ll need to interop with them at some point Things we all need to deal with Laws (however different), Contracts with common SPs, common Business requirements (e.g. out-/cloud-sourcing),...

6 2. On-boarding of prospective members Constituency (examples from ACOnet): Service Providers (external) Home Orgs: NREN participants Attribute Authorities?! How Require signed Service Agreement from * Signee must be able to legally bind org

7

8 On-boarding SPs So far we didn t have to deny any SPs But we may ask questions Esp. when required info was not provided Necessary (vs. optional) attributes Documentation regarding position of Signee Sometimes we consult with the community: Library consortia/buyers club, REFEDS,...

9 On-boarding SPs, 2 The old Authentication!= Authorization rears its ugly head SP: We don t require any attributes. Turns out license terms only cover: students, staff, faculty, patrons Federation not really involved, still might want to avoid fingerpointing and bad practices Policy Template now contains SP responsible for implementing access control

10 On-boarding HomeOrgs Identity Management Practice Statement (IDMPS) Establish baseline against which audits could be performed, e.g. in context of incidents Create awareness that with Identity Federation (formerly purely) internal processes of an institution will affect other members!

11 On-boarding HomeOrgs, 2 Quick-and-dirty Making it easy to sign up (no new barriers): Fact No MUST for an IDMPS in Policy + No documentation + No examples = Not a single submitted IDMPS So don t do that.

12 On-boarding members What you can do check out prior art: Haka: IdM-Description JISC Identity Management Toolkit What attributes are relevant for an SP (REFEDS Wiki) Kantara IAWG Federation Operator Guidelines GÉANT FOP(P) Template?

13 Identity Assurance Level of Assurance (LoA) [The] degree of certainty that the user has presented an identifier (a credential in this context) that refers to his or her identity. In this context, assurance is defined as 1) the degree of confidence in the vetting process used to establish the identity of the individual to whom the credential was issued, and 2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued. OMB M-04-04, 2003

14 Identity Assurance, 2 Rightsizing the problem space Not all SPs care about high(er) LoA Higher standard IdPs and lower standard IdPs How to match them up?

15 Identity Assurance, 3 By communicating those facts in an agreed-upon way (Higher) LoA won t need to cover all identities in the IdM system (Higher) LoA [probably] optional for HomeOrgs

16 Identity Assurance, 4 Work in progress Come back in a year Or stay for the panel discussion