Interfederation

RL “Bob” Morgan

University of Washington and Internet2

Digital ID World 2005

San Francisco

2

TopicsTopics

• Federation and Interfederation

• US E-Authentication Program and Internet2

• USperson schema

3

Federations definedFederations defined

• created to support community• interesting ones are multi-IdP, multi-SP

• embodies agreements on many levels• membership, technology, assurance, key mgt, legal,

attributes, privacy, appropriate use, etc

• facilitates member federated interactions• many potential sub-communities and their apps

• operational support• key/config distribution, IdP discovery, etc

• doesn't preclude non-fed arrangements

4

Federations happeningFederations happening

• i.e., SAML-based (or similar) federations• in Europe, natural extension of HE NREN

services• Switzerland, Finland, Netherlands, UK, Spain, France,

etc

• in US• InCommon Federation in higher ed

• also state-level planning, vertical apps such as student loan management

• US government E-Authentication Program

• also much non-fed or pre-fed deployment among fed members

5

InterfederationInterfederation

• an immediate consequence of federation• brand-new federations don't have well-defined

boundaries or service scopes

• it's the Internet, we're all connected

• many interesting SPs are global, e.g. Elsevier

• Interfederation workshop, Oct 2004• Upper Slaughter, UK (a nicer walled garden?)

• many countries, including CERN

• many agreements on direction, future work

6

... but it's a nice garden... but it's a nice garden

7

Interfederation modelsInterfederation models

• parallel universes• members simply participate in many if needed

• consistent with fundamental pairwise nature of app-level relationships

• scaling, diversity not addressed

• peering• transitive assurance, legal, policy, maybe ops

• too tight a coupling?

• league of federations?• some historical examples ...

8

US E-AuthenticationUS E-Authentication

• http://cio.gov/eauthentication• for authoritative info

• facilitates trusted access to e-government

• e-auth elements• credential providers (CSPs), agency apps (AAs)

• credential assessment framework (CAF), application risk assessment, defined LoAs

• approved technologies, products (X.509, SAML)

• e-auth ops: membership, portal (aka “Fed fed”)

• agency mandates

9

InCommon E-Auth alignmentInCommon E-Auth alignment

• promote interop for widespread higher-ed access to USG applications• grants process, research support, student loans ...

• process• project started Oct 2004, thru Sept 2005

• compare federation models

• propose alignment steps

• validate with federation members, via concrete application trials

• implement via next e-auth, InCommon phases

10

Alignment pointsAlignment points

• Basic divergence: loose vs tight coupling

• assurance: facilitated vs guaranteed• InCommon participants publish their processes

• E-auth participants audited, approved by GSA• level of assurance is fundamental characteristic

• membership: IdP-centric vs SP-centric• E-auth driven by requirements of e-government AAs

• InCommon driven by requirements of university CSPs

• operation: metadata-centric vs portal-centric• InCommon-managed metadata supports interaction

• E-auth portal mediates flow, adds adapation point

11

Alignment points 2Alignment points 2

• user identity: application-supporting attributes vs fixed identifier set• InCommon relies on Internet2-defined eduPerson,

promotes attribute-based authorization

• E-Authentication specifies delivery of identifiers

• technology: SAML and profiles• InCommon specifies Shib profile of SAML 1.1

• E-authentication specifies extensive profile on top of SAML 1.0

• intend to converge on SAML 2.0

12

Validation stepsValidation steps

• universities undergo trial by CAF• assess whether compliance is likely across HE

• U Washington, Penn State, Cornell

• pretty darned close: 50% all-OK, others do-able

• deploy access to a real USG app• summer 2005

• requires E-Auth acceptance of univs as CSPs

• app will modify existing provisioning process

• practical feedback to alignment recommendations

13

US personUS person

• motivated by InCommon desire for attribute-based authorization

• modeled on Internet2 eduPerson spec

• framework on which agency/app definitions can be built

• not just SAML• generic information model, mapped to LDAP,

SAML, XML provisioning

• ambitious? yes ...