US E-authentication and the Culture of Compliance RL “Bob” Morgan University of Washington CAMP,...
-
Upload
cleopatra-price -
Category
Documents
-
view
222 -
download
3
Transcript of US E-authentication and the Culture of Compliance RL “Bob” Morgan University of Washington CAMP,...
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