ACOnet Identity Federation Policy Experiences Peter Schober ACOnet TERENA EuroCAMP @ 4 th GN3 Symposium 15-16 October 2012
Agenda 1. The Politics behind Federation Policies 2. Tales from a Federation Operator: On-boarding of prospective members 3. Identity Assurance
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
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
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), . . .
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
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, . . .
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”
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!
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.
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 ?
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
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?
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
Identity Assurance, 4 ◮ Work in progress ◮ Come back in a year ◮ Or stay for the panel discussion
Recommend
More recommend
