Currently, GridShib and CAS bind self-issued SAML assertions to proxy certificates. !GridShib, for example, has the ability to bind an authentication assertion (i.e., an assertion containing an AuthenticationStatement=) to a proxy. Similarly, CAS binds an assertion containing an =AuthorizationDecisionStatement
to a proxy. These and other anticipated [X509BindingSAMLUseCases have been documented elsewhere.
Note: A poster entitled "An X.509 Binding for SAML", which was presented at the Midwest Security Workshop 2006, is attached to this wiki topic.
The question naturally arises as to what SAML blob should be bound to a certificate in general. There are two obvious choices:
<saml:Assertion>
element (like GridShib and CAS do now)<samlp:Response>
element (obtained directly from a Shibboleth !IdP)Does it make sense to always bind a <saml:Assertion>
element to a certificate? If so, a Shibboleth response must be decomposed into its constituent <saml:Assertion>
elements, all of which are subsequently bound to the certificate. This is problematic for the following reasons:
<samlp:Response>
element (if it exists).<samlp:Response>
element. Moreover, these can not be patched since the assertions themselves may be signed.In the case of multiple assertions, binding each assertion to its own extension is difficult due to the following requirement from RFC 3280:
A certificate MUST NOT include more than one instance of a particular extension.
Moreover, it is not feasible to have a separate OID for each "type" of assertion since the number of possibilities is theoretically infinite. Thus we must use a single extension (OID) to bind multiple assertions.
We bind an ASN.1 SEQUENCE of <saml:Assertion>
elements at a well-known, non-critical X.509 v3 certificate extension.
The following lines are taken from the SAML V1.1 Bindings and Profiles specification SAMLBind:
In the discussion of the web browser SSO profiles, the term SSO assertion will be used to refer to an assertion that has a
<saml:Conditions>
element withNotBefore
andNotOnOrAfter
attributes present, and also contains at least one or more authentication statements about the subject. Note that an SSO assertion MAY also include additional information about the subject, such as attributes.
Definition An SSO assertion bundle consists of one or more assertions obtained as a result of a web browser SSO profile. At least one of these assertions is an SSO assertion as described in SAMLBind.
In what follows, we use the term "SSO assertion" to refer to any assertion in an SSO assertion bundle.
Many use cases transform Shib-issued SSO assertions into attribute-bearing grid credentials. With this in mind, it is useful to enumerate the types of responses obtained in conjunction with a Shibboleth browser profile:
AuthenticationStatement
AttributeStatement
AuthenticationStatement
and the other containing an AttributeStatement
Today, the Shib SP exposes the last response it receives from the !IdP. In the case of attribute pull (the default), this is an attribute response. In the case of attribute push, the authentication response is exposed. Thus the assertion payload depends on the protocol flow (push or pull). In both cases, however, an assertion containing an AttributeStatement
is exposed by the Shib SP. It is this attribute assertion that is of primary interest.
Note: As required by the SAML request-response protocol, Shib-issued SSO assertions are contained by a <samlp:Response>
element, which may be signed. Additionally, the assertions themselves may be signed.
Finally we observe that SAML assertions are not easily classified. For example, we often use the term "authentication assertion" to refer to "an assertion that contains an
AuthenticationStatement |
" but this definition is vague since other statements can (and do) appear in such assertions, namely, AttributeStatement
. So be aware that our working definitions of "authentication assertion" and "attribute assertion" overlap somewhat.
To solve this problem, let's classify embedded SAML assertions into three distinct groups:
For all these assertion types, we insert a top-level <saml:Assertion>
element into the certificate (as done now by GridShib and CAS) at a well-known certificate extension. In the case of SSO assertions, we routinely insert a <saml:Assertion>
element into the <saml:Advice>
element of a self-issued assertion.
Definition If the certificate is an end-entity certificate (EEC), and the Issuer of the assertion is the Issuer of the EEC, the assertion is called a CA-issued assertion.
NotBefore
and NotOnOrAfter
attributes SHOULD be omitted. If these attributes are present, their values MUST be equal to the values of the NotBefore
and NotOnOrAfter
fields (resp.) of the EEC.<saml:NameIdentifier>
element of a CA-issued assertion MUST have a Format
attribute whose value is equal to urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
. The value of the <saml:NameIdentifier>
element MUST be equal to the Subject DN of the EEC.SubjectConfirmation
element. A relying party MAY ignore a SubjectConfirmation
element in a CA-issued assertion.Definition If the certificate is a proxy certificate, and the Issuer of the assertion is the Subject of the proxy, the assertion is called a self-issued assertion.
NotBefore
and NotOnOrAfter
attributes SHOULD be omitted. If these attributes are present, their values MUST be equal to the values of the NotBefore
and NotOnOrAfter
fields (resp.) of the proxy.<saml:NameIdentifier>
element of a self-issued assertion MUST have a Format
attribute whose value is equal to urn:oasis:names:tc:SAML:1.1:nameid-format:X509SubjectName
. The value of the <saml:NameIdentifier>
element MUST be equal to the Subject DN of the proxy.SubjectConfirmation
element. A relying party MAY ignore a SubjectConfirmation
element in a self-issued assertion.<saml:AttributeStatement>
elements. The assertion is considered invalid if it contains any other type of statement.<saml:Advice>
element with one or more nested SAML assertions. The nested assertions contain third-party assertions that the relying party MAY use in making its access control decision.Definition An assertion that is neither a CA-issued assertion nor a self-issued assertion is called a third-party assertion.
SubjectConfirmation
element with subject confirmation method holder-of-key
.SubjectConfirmation
element with subject confirmation method holder-of-key
. In this case, the relying party MUST confirm the subject, that is, the relying party MUST verify that the subject (who is also the requester) possesses the corresponding private key.<saml:Assertion>
element into the <saml:Advice>
element of a self-issued assertion. Thus an SSO assertion is a nested assertion (unlike a top-level assertion).<samlp:Response>
element (if it exists) before stripping the <samlp:Response>
element and binding the enclosed assertion to the certificate.entityID
of the SAML issuer. A relying party MAY query the !IdP based on the entityID
in the SIA extension.<hr /> |