150 likes | 275 Views
RL “Bob” Morgan University of Washington CAMP, June 2005. US E-authentication and the Culture of Compliance. Topics. US E-Authentication Program E-auth and Internet2 Interfederation Interoperability Working Group Assessment can be fun (aka getting CAFed and liking it)
E N D
RL “Bob” Morgan University of Washington CAMP, June 2005 US E-authentication and the Culture of Compliance
Topics 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
US 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
InCommon + 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
IIWG 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
E-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
Alignment 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
Alignment 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
NSF 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
Campus 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
E-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
SAML 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?
US 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
E-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
Conclusion E-Authentication is strong standardizing factor in many industry sectors US HE is working to ensure that E-Auth meets our needs