Presentation on theme: "Federated Identity for Grid Architects Tom Scavo NCSA"— Presentation transcript:
Federated Identity for Grid Architects Tom Scavo NCSA firstname.lastname@example.org
Goals l General goals: u Enable secure attribute sharing among Grid virtual organizations and higher-educational institutions u Bridge X.509 and SAML l Specific goals: u Integrate the Globus Toolkit® with Shibboleth® u Add attribute-based authorization to Globus Toolkit®
Implemented Software l Globus Toolkit extensions u Grid SP protects Grid resources l Shib IdP extensions u Provides name mapping plugins and certificate registry UI l Shib-enabled CA u Issues short-lived X.509 end-entity credentials to be stored on the desktop l SAML Tools u Issues short-lived SAML and X.509 for VOs
IdP Proxy l Another essential VO middleware component is the IdP Proxy (e.g., myVocs) l An IdP Proxy is useful because: u There is a paucity of campus attributes (and campus admins are loathe to add more) u VOs have unique attribute requirements u A layer of abstraction between the campus IdPs and the Grid SPs provides flexibility l Much activity in this space (UAB, MAMS, USC, D-Grid)
Grid Requirements l The Shib-enabled CA, the IdP Proxy, and the Shib-enabled Science Gateway have the same technical requirements: u Persistent, non-reassignable identifier u Additional authn context, including LoA u Per-SP user ARPs at the IdP u Exposing validated assertions at the SP u Account linking at the SP and IdP Proxy u Support for attributes in SP metadata
Attribute Push vs. Pull l To push or to pull, that is the question! attributes user AA Grid SP user AA request attributes Pull Push
Attribute Pull l Like the Shib SP, the Grid SP requests SAML attribute assertions from the Shib AA (via a SOAP back-channel exchange) l The Grid SP trusts the IdP (and vice versa) l This mode requires a NameIdentifier the IdP can understand l Attribute pull gives rise to the IdP Discovery problem
Shib Browser Profiles l Lets review the Shibboleth profiles l Current technology (Shibboleth 1.3) defaults to Browser/POST with Attribute Query l Future technology (Shibboleth 2.0) will default to Browser/POST with Attribute Push l In either case, the IdP both produces and consumes a NameIdentifier
M -1 : NameIdentifier -> LocalPrincipal M: LocalPrincipal -> NameIdentifier Attribute Assertion Attribute Query AttributesLocal Principal AuthN Assertion Local Principal AuthN Request + REMOTE_USER AuthN Request Request Response Local AuthN Service SSO Protocol Handler AuthN Authority Attribute Authority Attribute Resolver Query Protocol Handler Name Mapping Space Attribute Store User Store
NameIdentifier Formats l Shibboleth 1.3 supports no SAML V1.1 name identifier formats (except X509SubjectName, in a most trivial way) l Shib proprietary name identifier formats: u ShibHandle (transient, opaque) u CryptoShibHandle (a stateless ShibHandle) l Shib does have a flexible name mapping plugin interface, however
Standalone Attribute Query l A Standalone Attribute Query involves the Attribute Authority at the IdP and the Attribute Requester at the SP l The SSO Service at the IdP and the SSO Consumer at the SP are not involved l In other words, there is no front-channel Authentication Request-Response l This leads to some interesting problems!
The IdP has to compute the inverse of a name mapping that may not exist! Standalone Attribute Query (contd) M -1 : NameIdentifier -> LocalPrincipal Attribute Assertion Attribute Query AttributesLocal Principal RequestResponse Attribute Authority Attribute Resolver Query Protocol Handler Name Mapping Space Attribute Store ?
The LionShare Approach l LionShare, a pioneer in this space, uses CryptoShibHandle to encrypt the local principal name into the NameIdentifier l Characteristics: u Shared local authentication service u Shared (symmetric) key u Shared CryptoShibHandle code l GridShib follows in LionShares footsteps
Classic GridShib l In the Classic GridShib profile, a Grid SP pulls attributes from a Shib IdP l The Client presents an X.509 cert to the Grid SP l The Grid SP uses the Subject DN to query the IdP l The Client is assumed to have an account (i.e., local principal name) at the IdP 3 4 2 1 IdP Grid SP CLIENTCLIENT CLIENTCLIENT
Reconciling the Namespaces l The Grid knows its users by X.500 distinguished name (DN) l Campuses know their users by NetID (username), which extends across domains as attributes ePPN or ePTID l Much effort has been spent to establish the following name mapping: (DistinguishedName, PrincipalName)
Privacy Considerations l The campus IdP has a mandate to maintain privacy (FERPA) l The Grid SP requires identity (for billing and accounting) l This disconnect creates tension between partners l One solution is to allow end users to expose their identity by choice (see, e.g., ProtectNetwork.org)
Attribute Push l Traditional approach involves X.509 attribute certificates [VOMS] l Current approach is based on X.509 certificates (end-entity or proxy certs) with bound SAML [GridShib] l This mode requires a NameIdentifier the Grid SP can understand l Attribute push gives rise to SP Discovery
Anatomy of a Grid Certificate l Short lifetime (in the case of a Science Gateway, a very short lifetime) l SAML assertion(s) bound to a well-known certificate extension l SSO assertion(s) nested in the Advice element of a bound SAML assertion l IdP entityID in Subject Information Access extension l SAML Subject in the Subject Alt Name extension
Your consent to our cookies if you continue to use this website.