US E-authentication and the Culture of Compliance RL “Bob” Morgan University of Washington CAMP, June 2005.

US E-authentication and the Culture of Compliance

RL “Bob” Morgan

University of Washington

CAMP, June 2005

2

TopicsTopics

• US E-Authentication Program

• E-auth and Internet2 Interfederation Interoperability Working Group

• Assessment can be fun (aka getting CAFed and liking it)

• An initial E-Auth application

• usPerson schema project

3

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

• E-Authentication Partnership advisory group

4

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 Dec 2005

• compare federation models

• propose alignment steps

• validate with federation members, via concrete application trials

• implement via next e-auth, InCommon phases

5

IIWG elementsIIWG elements

• federation comparison (E-Auth, InCommon)

• modify Shib software to work with E-Auth• part of Shib 1.3

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

• deploy HE access to a real USG app• NSF FastLane; learn from this experience

• propose alignment steps for E-Auth and InC

• propose interfederation structure

6

E-Auth + InC alignment pointsE-Auth + InC alignment points

• Basic divergence: loose vs tight coupling• membership: IdP-centric vs SP-centric

• E-auth driven by requirements of e-government AAs• some CSPs will be govt agencies, but mostly external

• InCommon driven by requirements of university IdPs, encouraging SPs to federate with us

• assurance: facilitated vs guaranteed• InCommon IdPs publish their processes,

SPs decide whether they're OK

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

of both agency apps and credential servicesbased on NIST-defined criteria

7

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 only

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

interaction between IdPs and SPs

• E-auth portal mediates flow, adds user navigation and LoA adaptation point

8

Alignment points 3Alignment points 3

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

• E-Auth specifies extensive profile on top of SAML 1.0(also supports cert authentication for higher LoAs)

• intend to converge on SAML 2.0

9

NSF FastLane via E-AuthNSF FastLane via E-Auth

• FastLane: a good first application• used by 300,000 HE users, PIs and research admins

• early E-Auth participant

• assessed at Level 1

• NSF seeking process improvement

• Process:• 4 campuses get CAFed, deploy Shib 1.3, join E-A

• NSF deploys E-Auth capable FastLane

• campus users “account link” once by authenticating via E-A, entering old account/password

10

Campus Compliance IssuesCampus Compliance Issues

• Level 1 is pretty easy• be a real organization, with basic docs

• have a user database (but no ID proofing reqts)

• run a secure authentication system

• Password-guessing protection is the hurdle• system should protect against brute-force guessing

• implies guessing-limitation, -monitoring, lockout

• none of participant campuses doing this today

• various plans: monitor, remove e-auth authz• only need apply to E-Auth application users

11

E-Auth support in ShibbolethE-Auth support in Shibboleth

• Shibboleth protocol interaction is SAML 1.1• with various choices to enable interop, eg name

formats, common attributes, metadata, req message

• demonstrated interop with other SAML 1.1 products

• E-Auth/SAML is today a profile of SAML 1.0• using Artifact method, attribute push, etc

• Shibboleth version 1.3 supports E-Auth profile• can run in parallel with traditional Shib profile

• motivated changes in IdP structure

• Shib 1.3 SP intended to be compliant too

12

SAML 2SAML 2

• SAML 1.x doesn't cover many interop elements

• SAML 2.0 covers the waterfront• authentication request

• logout

• identifier management

• WS-Federation• SAML alternative promoted by some big vendors

• will it be brought into E-Auth approved tech space?

13

US person schemaUS person schema

• motivated by HE interest in attribute-based authorization for E-Auth

• modeled on Educause/Internet2 eduPerson spec and its use in Shibboleth and InCommon

• not list of attributes, but framework on which agency/app definitions can be built

• not just SAML, but generic information model, mapped to LDAP, SAML, XML provisioning

• starting by looking at improved processes for NSF, USDA applications, using campus-sent attributes,also national schema efforts from EU countries

• ambitious? yes ... proposal due June 2006

14

E-Auth and InCommon peeringE-Auth and InCommon peering

• E-Auth doesn't want 1000 university members• or 1000 banks, or anything else

• rather, wants to peer with federations in these industry sectors

• federation peering is new territory• though some prior reusable work in PKI Bridge CA

interop/mapping

15

ConclusionConclusion

• E-Authentication is strong standardizing factor in many industry sectors

• US HE is working to ensure that E-Auth meets our needs