SAML Request

As you might imagine, there are three variants of SAML request and response, one each for authentication, attributes, and authorization. Similar to the assertions them- selves, the requests and responses are XML documents and have a header portion that is common, a portion that is specific to a request, and a portion that is specific to a response.

The header portion of a request/response contains a definition of the namespaces used and the import of other specification schemas used by the SAML request/response. In the present specification, these imported schemas are the digital signature specification, the SAML assertion schema, and the XML schema itself. Fol- lowing the header portion, the request schema is defined, followed by the definition of the response schema.

Both the request portion and the response portion of the SAML request/response schema begin with an abstract element. As we described above, in an XML schema, as in a programming language, one cannot have only abstract elements. There has to be a concrete portion that derives from the abstract portion to have a valid schema. In addi- tion, abstract elements can be used as an extension point. SAML defines the Request- Type as inherited from the abstract complexType, RequestAbstractType. Since

RequestAbstractType is abstract, other elements or complex types could be derived from it in the future. Similarly, all responses are inherited from the abstract element

ResponseAbstractType.

In the next two sections, we take a look at the SAML request and response in more detail.

A SAML request is a format used by SAML to ask specific questions of an authentication, attribute, or authorization authority. For an authentication authority, the question is: Has this subject been authenticated? The requester is expecting a response in the form of a SAML authentication assertion. For an attribute authority, the question is: What are the attributes for this authenticated subject? The requester is expecting an answer in the form of a SAML attribute assertion. For an authorization authority the question is: Can this subject perform the specified action on the specified resource optionally using the supplied evidence? The requester is expecting an answer in the form of a SAML authorization assertion.

The request portion of the SAML protocol starts out with an abstract type called the

RequestAbstractType. This is followed by the version of the specification and the time of issuance of the request.

Optionally, the request may be digitally signed. The digital signature must follow the W3C Digital Signature specification.

The RespondWithelement in the request is a statement by the requestor that it can handle the responses set in this element. The responder must conform to this request. The types of responses that are defined for the RespondWithelement are Authentication- Statement, AttributeStatement, and/or AuthorizationStatement. Multiple statements are indicated by multiple RespondWithelements. RespondWithis an optional statement. If it is not sent then the responder may send any assertions with any statements.

The request element fragment of the schema is shown below.

</extension> </complexContent> </complexType>

You can see from the schema that the request type is derived from the RequestAb- stractType. You might have noticed that several of the choices are prefixed by samlp

rather than saml. This is the namespace for the SAML Protocol schema. A request type can take any of seven forms. It can be a:

■■ Query ■■ SubjectQuery ■■ AuthenticationQuery ■■ AttributeQuery ■■ Authorization Query ■■ AssertionIDReference ■■ AssertionArtifact

The Query and the SubjectQuery are both abstract types, with the SubjectQuery

derived from the Query. Therefore, they cannot be the only choice, and both of these elements may be used to define new elements in the request. In the specification, the remaining choices are derived from the abstract element SubjectQuery. The Query element is simply an extension point, whereas the SubjectQuery contains the SAML Sub- ject that we discussed earlier, as well as being an extension point.

The SAML SubjectConfirmation in the request raises some interesting points. As we mentioned earlier, SAML does not explicitly define a means to request that an 118 Chapter 5

authentication be carried out. However, the SAML assertion defines the SubjectConfir- mationthat contains the ConfirmationMethod, the SubjectConfirmationData, and the Key- Info elements. According to the specification, these elements are not to be used to authenticate the subject, only to verify the authentication. Since authentication is not defined by the initial SAML specification, a principal is expected to authenticate itself to the authority in such a manner that the authority is able to unambiguously assert that the authentication has taken place. One way that this can be done is to have the authentication take place in the same session as the request for authentication. For example, a client could perform mutual SSL authentication at the same time it requests the SAML assertion, or it could use one of the HTTP authentication methods. At the very least, the authentication authority must associate the SAML authentication with absolute knowledge that the authentication has successfully taken place.

The next three additional elements in the choice are what you would expect: authentication, authorization, and attributes. The next to last element in the choice, Assertion- IDReference, lets you use an assertion ID to point at an assertion, that is, the assertion may be external to this request.

The last element in the request, the AssertionArtifact, is something that we have not run across before. This is a somewhat complex construct that is used to help solve the “dumb browser” problem. By “dumb,” we mean that when it comes to security, today’s browsers do not have sufficient capabilities to operate at the level of security that we would like in a Web Services environment. The artifact construct, which we will discuss a little later in this chapter, attempts to mitigate this problem.

AuthenticationQuery

The AuthenticationQueryelement of the SAML request asks the question, to quote from the specification, “What authentication assertions are available for this subject?” The schema for the AuthenticationQueryonly adds the element AuthenticationMethodthat has been defined in the SAML assertion. This is a URI that identifies the type of authentication that has been performed.

The specification identifies a number of authentication methods that may be used in the AuthenticationMethod, which include:

■■ Password

■■ Kerberos

■■ Secure Remote Password

■■ Hardware Token

■■ SSL/TLS certificate-based client authentication

■■ X.509 Public Key

■■ SPKI Public Key

■■ XKMS Public Key

■■ XML Digital Signature

■■ Unspecified

Each of the AuthenticationMethodsis assigned a URI by the specification.

AttributeQuery

An AttributeQuery extends (that is, derives from) the SubjectQueryAbstractType. It is used to request that an attribute authority return certain attributes in an attribute assertion. The schema for the AttributeQueryis quite straightforward. There are only two elements added to a request for the AttributeQuery. They are an optional AttributeDes- ignatorthat was defined by the SAML assertion schema and an optional resource. The schema is shown below.

</complexContent> </complexType>

The AttributeDesignator is used to tell the attribute authority what attributes the requestor wants returned. In order to make this request, the AttributeDesignatorcontains an attribute name and a namespace in which the attributes are defined. For example, one could ask for all the attributes of type “role” in the namespace “J2EE”. As you can see from the schema, one can ask for the attributes related to an unlimited number of types. The resource element is an optional field that the requester can use to tell the attribute authority that this request is made in response to an authorization request for access to a particular resource.

It should be noted that the XACML TC is working on fully defining the access control and a language for access control. This will have the effect of more fully defining attributes and authorization.

AuthorizationQuery

An AuthorizationQueryis used to request that the authorization authority answer the question of whether the particular subject is permitted to perform the stated actions on the given resource, optionally based on the evidence sent in the request.

The elements in the AuthorizationQueryare the name of the resource, the actions to be performed, and optional evidence. The resource is defined by a URI. Both the

Actionsand the Evidenceare defined in the SAML assertions. The schema for theautho- rization decision queryis:

<element name=”AuthorizationDecisionQuery”

type=”samlp:AuthorizationDecisionQueryType”/>

<element ref=”saml:Action” maxOccurs=”unbounded”/> <element ref=”saml:Evidence” minOccurs=”0”

maxOccurs=”1”/> </sequence>

</complexContent> </complexType>

Here we see that Actionsare composed of a sequence of potentially many Actionelements and optional Evidence, both of which are defined by the SAML core.

The authorization authority may use the assertions in the Evidenceattribute in mak- ing its authorization decision.

In document Mastering Web Services Security pdf (Page 144-148)