federated identity for grid architects tom scavo ncsa [email protected]
TRANSCRIPT
Goals
General goals: Enable secure attribute sharing among Grid
virtual organizations and higher-educational institutions
Bridge X.509 and SAML Specific goals:
Integrate the Globus Toolkit® with Shibboleth® Add attribute-based authorization to Globus
Toolkit®
Implemented Software
Globus Toolkit extensions Grid SP protects Grid resources
Shib IdP extensions Provides name mapping plugins and certificate
registry UI Shib-enabled CA
Issues short-lived X.509 end-entity credentials to be stored on the desktop
SAML Tools Issues short-lived SAML and X.509 for VOs
IdP Proxy
Another essential VO middleware component is the IdP Proxy (e.g., myVocs)
An IdP Proxy is useful because: There is a paucity of campus attributes (and
campus admins are loathe to add more) VOs have unique attribute requirements A layer of abstraction between the campus
IdPs and the Grid SPs provides flexibility Much activity in this space (UAB, MAMS, USC,
D-Grid)
Grid Requirements
The Shib-enabled CA, the IdP Proxy, and the Shib-enabled Science Gateway have the same technical requirements: Persistent, non-reassignable identifier Additional authn context, including LoA Per-SP user ARPs at the IdP Exposing validated assertions at the SP Account linking at the SP and IdP Proxy Support for attributes in SP metadata
Attribute Push vs. Pull
To push or to pull, that is the question!
attributes
user
AA
Grid SP
user
AA
request request
attributes
Pull Push
Attribute Pull
Like the Shib SP, the Grid SP requests SAML attribute assertions from the Shib AA (via a SOAP back-channel exchange)
The Grid SP trusts the IdP (and vice versa) This mode requires a NameIdentifier the IdP
can understand Attribute pull gives rise to the IdP Discovery
problem
Shib Browser Profiles
Let’s review the Shibboleth profiles Current technology (Shibboleth 1.3) defaults
to Browser/POST with Attribute Query Future technology (Shibboleth 2.0) will
default to Browser/POST with Attribute Push In either case, the IdP both produces and
consumes a NameIdentifier
M-1: NameIdentifier -> LocalPrincipal
M: LocalPrincipal -> NameIdentifier
Attribute Assertion
Attribute Query
Attributes Local Principal
AuthN Assertion
Local Principal
AuthN Request+ REMOTE_USER
AuthN Request
Request
Request
Response
Response
Local AuthN Service
SSO Protocol Handler
AuthN Authority
Attribute Authority
Attribute Resolver
Query Protocol Handler
Name Mapping
SpaceAttribute
StoreUserStore
NameIdentifier Formats
Shibboleth 1.3 supports no SAML V1.1 name identifier formats (except X509SubjectName, in a most trivial way)
Shib proprietary name identifier formats: ShibHandle (transient, opaque) CryptoShibHandle (a stateless ShibHandle)
Shib does have a flexible name mapping plugin interface, however
Standalone Attribute Query
A Standalone Attribute Query involves the Attribute Authority at the IdP and the Attribute Requester at the SP
The SSO Service at the IdP and the SSO Consumer at the SP are not involved
In other words, there is no front-channel Authentication Request-Response
This leads to some interesting problems!
The IdP has to compute the inverse of a name mapping that may not exist!
Standalone Attribute Query (cont’d)
M-1: NameIdentifier -> LocalPrincipal
Attribute Assertion
Attribute Query
Attributes Local Principal
RequestResponse
Attribute Authority
Attribute Resolver
Query Protocol Handler
Name Mapping
SpaceAttribute
Store ?
The LionShare Approach
LionShare, a pioneer in this space, uses CryptoShibHandle to encrypt the local principal name into the NameIdentifier
Characteristics: Shared local authentication service Shared (symmetric) key Shared CryptoShibHandle code
GridShib follows in LionShare’s footsteps
Classic GridShib
In the “Classic GridShib” profile, a Grid SP “pulls” attributes from a Shib IdP
The Client presents an X.509 cert to the Grid SP
The Grid SP uses the Subject DN to query the IdP
The Client is assumed to have an account (i.e., local principal name) at the IdP
3
4
2
1
IdPIdP
Grid SPGrid SP
CLIENT
CLIENT
Reconciling the Namespaces
The Grid knows its users by X.500 distinguished name (DN)
Campuses know their users by NetID (username), which extends across domains as attributes ePPN or ePTID
Much effort has been spent to establish the following name mapping:(DistinguishedName, PrincipalName)
Privacy Considerations The campus IdP has a mandate to maintain
privacy (FERPA) The Grid SP requires identity (for billing
and accounting) This disconnect creates tension between
partners One solution is to allow end users to
expose their identity by choice (see, e.g., ProtectNetwork.org)
Attribute Push
Traditional approach involves X.509 attribute certificates [VOMS]
Current approach is based on X.509 certificates (end-entity or proxy certs) with bound SAML [GridShib]
This mode requires a NameIdentifier the Grid SP can understand
Attribute push gives rise to SP Discovery
Anatomy of a Grid Certificate Short lifetime (in the case of a Science
Gateway, a very short lifetime) SAML assertion(s) bound to a well-known
certificate extension SSO assertion(s) nested in the Advice
element of a bound SAML assertion IdP entityID in Subject Information Access
extension SAML Subject in the Subject Alt Name
extension
SubjectIssuerPublic KeyValiditySignature
IdP entityIDSAML Subject<Assertion> …</Assertion>
X.509 Binding for SAML In general, bind an ASN.1 SEQUENCE of SAML
assertions to an X.509 certificate Assertions bound by value or reference:
<saml1:Assertion><saml1:AssertionIDReference><saml2:Assertion><saml2:EncryptedAssertion> <saml2:AssertionIDRef><saml2:AssertionURIRef>
Use SAML Tools to bind SAML to X.509
SAML Tools
Shib-backedSAML Issuer
Tool
StandaloneSAML Issuer
Tool
SAMLX.509 Binding
Tool
SA
ML
SA
ML
(inputs)
(inputs)
X.509SAML
SAMLAttribute Query
Client(inputs)
Shibboleth IdP Config
ConfigFile
Bound SAML Assertion <saml:Assertion ...>
<saml:Advice> <!-- assertion issued by campus IdP --> <saml:Assertion ...> ... <saml:AuthenticationStatement ...> <saml:Subject>...</saml:Subject> ... </saml:AuthenticationStatement> <saml:AttributeStatement> <saml:Subject>...</saml:Subject> <saml:Attribute ...> <!-- campus attribute --> </saml:Attribute> ... </saml:AttributeStatement> </saml:Assertion> </saml:Advice> <saml:AttributeStatement> <saml:Subject>...</saml:Subject> <saml:Attribute ...> <!-- VO attribute --> </saml:Attribute> ... </saml:AttributeStatement></saml:Assertion>
GSI Attribute-based Authz
Authz based on identity?
Authz based on
push?
Authz based on push/pull?
Query?Authn?
START
ALLOW
DENY
Y
YYY
Y NN
NNN