ACOnet Identity Federation Policy Experiences Peter Schober ACOnet - - PowerPoint PPT Presentation

ACOnet Identity Federation Policy Experiences

Peter Schober

ACOnet

TERENA EuroCAMP @ 4th 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