1. Federated Identity for Grid Architects Tom Scavo NCSA trscavo@ncsa.uiuc.edu

2. 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®

3. 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

4. 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)

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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!

12. 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 ?

13. 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

14. 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

15. 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)

16. 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)

17. 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

18. 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

19. Subject Issuer Public Key Validity Signature IdP entityID SAML Subject …

20. X.509 Binding for SAML l In general, bind an ASN.1 SEQUENCE of SAML assertions to an X.509 certificate l Assertions bound by value or reference: l Use SAML Tools to bind SAML to X.509

21. SAML Tools Shib-backed SAML Issuer Tool Standalone SAML Issuer Tool SAML X.509 Binding Tool SAMLSAML SAMLSAML (inputs) X.509 SAML SAML Attribute Query Client (inputs) Shibboleth IdP Config Config File

22. Bound SAML Assertion l.....................

23. GSI Attribute-based Authz Authz based on identity? Authz based on push? Authz based on push/pull? Query? Authn? START ALLOW DENY Y YYY YNN NNN