A fragment of the authorization statement is presented below: <element name=”AuthorizationDecisionStatement” type=”saml:AuthorizationDecisionStatementType”/> <complexType name=”AuthorizationDecisionStatementType”> <complexContent> <extension base=”saml:SubjectStatementAbstractType”> <sequence> <element ref=”saml:Action” “maxOccurs =”unbounded”/> <element ref=”saml:Evidence” minOccurs=”0/> </sequence> <attribute name=”Resource” type=”anyURI” use=”required”/> <attribute name=”Decision” type=”saml:DecisionType “use=”required”/> </extension> </complexContent> </complexType> Copyright © OASIS Open (2001, 2002). All Rights Reserved There is nothing very new in this fragment, so you should be able to figure out what this schema means. We’ve described the meaning of all the elements except the Deci- sion, which returns the results of a decision. A Decision element may take one of the val- ues: ■■ Permit ■■ Deny ■■ Indeterminate Assertion Example Now that we have gone through a detailed explanation of the SAML assertion schema, let’s take a look at what a simple assertion itself would look like. The following XML document is an attribute assertion that says that dflinn has the attribute Payroll Administrator. <saml:Assertion xmlns:saml=”urn:oasis:names:tc:SAML:1.0:assertion” MajorVersion=”1” MinorVersion=”0” AssertionID=”4bef456bba6” Issuer=”http://www.quadrasis.com/easi” IssueInstant=”2002-08-20T10:30:32Z” > <saml:Conditions NotBefore=”2002-08-20T10:28:32Z” NotOnOrAfter=”2002-08-20T11:28:32Z” > <saml:AudienceRestrictionCondition> <saml:Audience> http://www.bigbiz.com/accounting </saml:Audience> </saml:AudienceRestrictionCondition> Security Assertion Markup Language 115 </saml:Conditions> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier NameQualifier=”www.quadrasis.com” Format=”urn:oasis:names:tc:SAML:1.0:assertion #WindowsDomainQualifiedName” > ne\dflinn </saml:NameIdentifier> </saml:Subject> <saml:Attribute AttributeName=”role” AttributeNamespace=”http://www.quadrasis.com/easi” > <saml:AttributeValue> PayrollAdministrator </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement> </saml:Assertion> The code starts out defining this as a SAML assertion, version 1 0. It then gives a unique ID for the assertion followed by identifying the issuer and issue time. This sat- isfies the common portion of the assertion. We next add some condition elements that identify the time period for which this assertion is valid and who the intended audi- ence is. The next section of the assertion is an attribute statement that identifies the subject of the assertion, ne\dflinn, and states his attribute as the role PayrollAdministrator. Notice that the format of the name uses one of the standard formats defined by the specification, a WindowsDomainQualifiedName. The definition of a WindowsDomain- QualifiedName is an optional Windows domain, ne in our case, followed by the Win- dows user name, dflinn. SAML Protocols The SAML usage model, as opposed to the SAML specification, discusses services or authorities that issue the authentication, attribute, and authorization assertions and attest to the truth of their assertions. As a consequence, a necessary part of the specifi- cation is to define a protocol for requesting assertions from such third parties and returning the completed assertion in a response message. How the service authorities carry out their mission is not in the province of SAML, just the standardization of the request and reply messages and the means of transport- ing these messages. SAML calls the means or protocols for transporting the messages to and from the authorities the SAML bindings. In addition to getting the SAML assertions, there needs to be a means of transport- ing the assertions from the initiator of a request to the target of the request. That is, what protocols does SAML use to transport the assertion and where does one place the 116 Chapter 5 SAML assertions in the message protocol used between the initiator and the target? These protocols are called SAML profiles. We cover the format of the request and responses as well as the bindings and profile protocols in this section. SAML Request/Response 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. SAML Request A SAML request is a format used by SAML to ask specific questions of an authentica- tion, 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. Security Assertion Markup Language 117 The RespondWith element 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 RespondWith element are Authentication- Statement, AttributeStatement, and/or AuthorizationStatement. Multiple statements are indicated by multiple RespondWith elements. RespondWith is 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. <element name=”Request” type=”samlp:RequestType”/> <complexType name=”RequestType”> <complexContent> <extension base=”samlp:RequestAbstractType”> <choice> <element ref=”samlp:Query”/> <element ref=”samlp:SubjectQuery”/> <element ref=”samlp:AuthenticationQuery”/> <element ref=”samlp:AttributeQuery”/> <element ref=”samlp:AuthorizationDecisionQuery”/> <element ref=”saml:AssertionIDReference” maxOccurs=”unbounded”/> <element ref=”samlp:AssertionArtifact” maxOccurs=”unbounded”/> </choice> </extension> </complexContent> </complexType> Copyright © OASIS Open (2001, 2002). All Rights Reserved 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 ele- ment 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- mation that 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: authen- tication, 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 AuthenticationQuery element of the SAML request asks the question, to quote from the specification, “What authentication assertions are available for this subject?” The schema for the AuthenticationQuery only adds the element AuthenticationMethod that has been defined in the SAML assertion. This is a URI that identifies the type of authen- tication 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 AuthenticationMethods is assigned a URI by the specification. Security Assertion Markup Language 119 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 asser- tion. The schema for the AttributeQuery is quite straightforward. There are only two elements added to a request for the AttributeQuery. They are an optional AttributeDes- ignator that was defined by the SAML assertion schema and an optional resource. The schema is shown below. <element name=”AttributeQuery” type=”samlp:AttributeQueryType”/> <complexType name=”AttributeQueryType”> <complexContent> <extension base=”samlp:SubjectQueryAbstractType”> <sequence> <element ref=”saml:AttributeDesignator” minOccurs=”0” maxOccurs=”unbounded”/> </sequence> <attribute name=”Resource” type=”anyURI reference”use=”optional”/> </extension> </complexContent> </complexType> Copyright © OASIS Open (2001, 2002). All Rights Reserved The AttributeDesignator is used to tell the attribute authority what attributes the requestor wants returned. In order to make this request, the AttributeDesignator contains 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 con- trol and a language for access control. This will have the effect of more fully defining attributes and authorization. AuthorizationQuery An AuthorizationQuery is 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 AuthorizationQuery are the name of the resource, the actions to be performed, and optional evidence. The resource is defined by a URI. Both the Actions and the Evidence are defined in the SAML assertions. The schema for the autho- rization decision query is: <element name=”AuthorizationDecisionQuery” type=”samlp:AuthorizationDecisionQueryType”/> 120 Chapter 5 <complexType name=”AuthorizationDecisionQueryType”> <complexContent> <extension base=”samlp:SubjectQueryAbstractType”> <sequence> <element ref=”saml:Action” maxOccurs=”unbounded”/> <element ref=”saml:Evidence” minOccurs=”0” maxOccurs=”1”/> </sequence> <attribute name=”Resource” type=”anyURI” use=”required”/> </extension> </complexContent> </complexType> Copyright © OASIS Open (2001, 2002). All Rights Reserved Here we see that Actions are composed of a sequence of potentially many Action ele- ments and optional Evidence, both of which are defined by the SAML core. The authorization authority may use the assertions in the Evidence attribute in mak- ing its authorization decision. SAML Response The response, similarly to the request, starts out with a common portion that contains many of the same elements, such as version number, Subject, and so on. The new attrib- utes in the response common section are the ResponseID and the InResponseTo attributes. The purpose of the InResponseTo attribute is to tie the response to its corresponding request, if any. This is accomplished by setting the InResponseTo attribute of the response equal to the RequestID of the request to which it is responding. The Response element itself follows a structure similar to the request in that it is derived from the ResponseAbstractType. The main element returned in a SAML response is the appropriate assertion or assertions. The other major element returned in a Response element is a sequence of statuses, which can be one of Success, VersionMismatch, Requestor, or Responder. The meaning of the first two is pretty obvious. The Responder status needs some explanation. This means the request couldn’t be performed because of an error at the receiving end. The Requester status indicates that the request couldn’t be performed because of an error in formulating the request. In addition to the status errors, SAML defines a number of optional sub statuses. The element SubStatusCode has defined the following values, the meaning of which should be obvious: ■■ RequestVersionTooLow ■■ RequestVersionTooHigh ■■ RequestVersionDepreciated ■■ TooManyResponses ■■ RequestDenied ■■ ResourceNotRecognized Security Assertion Markup Language 121 There is also an optional StatusMessage, which is a string that allows an explanatory message to be returned. Bindings The protocols that carry the request or response message to or from the SAML authen- tication, attribute, or authorization authorities are what SAML calls bindings. In addi- tion to the binding protocols defined in the specification, other binding protocols can be defined. The specification details the steps required to propose a new binding. There is only one binding protocol defined in the first version of SAML, the SOAP binding. We will discuss this binding next. SOAP Binding We have discussed the details of the SOAP protocol in Chapter 2, so we will not go into the details of SOAP here. Our purpose in this section is to talk about how SOAP is used to transport the SAML request and responses. The SOAP specification states that security information for a SOAP message is to be carried in the SOAP header. However, the purpose of a SAML SOAP binding is not to secure the SOAP message but to request and receive SAML security information, specifically SAML assertions. Therefore, the SAML information, in this case, is the message and is to be carried in the SOAP body, as is the case for any other SOAP message. There must not be any data other than the SAML request or reply in the SOAP mes- sage body when it is used to send a request or response for SAML assertions to or from a SAML authority. To keep the protocol simple, there cannot be more than one request or response in the SOAP message. The response is a SOAP message containing either a SAML response in the SOAP body or a SOAP fault code. The SOAP fault code is returned when the responder cannot process a SAML request. If there is an error in the processing of the SAML request or response, then a SOAP fault code is not sent, but a SAML error is returned. Establishing the security of the SOAP message used in a SAML binding is optional and is outside the SAML specification. From a system security point of view, this is an important consideration. You should treat the SOAP binding message as you would any other sensitive message, and perform authentication between the SAML authority and the requestor. Similarly, you should look at the confidentiality and integrity of the SOAP binding message and assess its security needs. Profiles A SAML profile is the description of how a SAML assertion is to be transported from one application to another. The SAML TC has submitted a SOAP profile to the Web Ser- vices Security TC, which is working on supporting transport of SAML assertions in a WS-Security token element. The effort of the Web Services Security TC is just begin- ning as of this writing. We will discuss the topic of WS-Security and SAML at the end of this chapter. 122 Chapter 5 There are two profiles defined for the initial SAML specification, the Browser Arti- fact profile and the HTTP POST profile. Both of these profiles are browser-based and are intended to support SSO. The browser is assumed to be a common commercial browser. The architecture for the browser-based profiles is depicted in Figure 5.2. The browser accesses what the specification calls a source site. This is some authority that can generate SAML assertions to be used by the browser for consumption by some tar- get. The browser accesses the source site by some means not defined by the specifica- tion. It may reach the source site by being redirected there by the target when the target discovers that the browser request does not have the required SAML assertion(s). Alternately, the browser may access the source site on its own to obtain the necessary security evidence to access a target. The browser must authenticate itself to the source site by some means, which is also outside the specification. It may accomplish this by using SSL/TLS, basic authentication, or any authentication method common to the source site and the browser. The source site itself is assumed to have a means of keep- ing track of an authenticated browser such as retaining session information or some other means outside this specification. Given this, the browser will only be required to log in to the source site once for the length of a session. Once an authenticated browser accesses the source site, Step 1 in Figure 5.2, the source site generates some evidence for the browser and returns it to the browser. The browser then contacts its intended target, Step 2 in Figure 5.2, presenting the evidence received from the source site. The target evaluates the evidence, optionally contacting the source site, Step 3, to gather additional evidence to ascertain whether to accept the evidence presented. If it accepts the evidence, then the browser is deemed to be authenticated. The browser may use the evidence from the source site to access other targets and to make additional calls on these targets. Thus, the browser will have accomplished SSO for the length of the session held by the source site. Figure 5.2 Browser artifact profile. Browser Target Source Site 2 31 Security Assertion Markup Language 123 SAML Artifact The first of the two profiles defined by version 1.0 of SAML uses a level of indirection in presenting its security evidence. The browser first obtains from the source site a small identifier called an artifact by SAML. Artifacts are used so that SAML assertions may fit into an HTTP URL from a Web browser. Typically a browser would pass security information in a cookie. However, cookies cannot be used in cross-domain applications, so the URL may be used instead to pass security data. Browsers put a limit on the size of the URL length that they will support, and SAML assertions containing a large number of attributes may not fit into a URL. Note that the browser manufacturers, not the HTTP specification, impose a limit on the URL size. For example, Microsoft Internet Explorer imposes a limit of 2 KB on the HTTP URL size. We discuss the topic of session tracking on the Web in more detail in Chapter 6, “Principles of Securing Web Services.” We will first describe the format for an artifact and then describe how it is used. SAML Artifact Structure The artifact structure consists of a mandatory 2-byte field followed by optional addi- tional data and is defined as follows: SAML_artifact := B64(TypeCode RemainingArtifact) TypeCode := Byte1Byte2 The B64 notation means that the artifact is base64 encoded. Base64 encoding trans- forms any binary representation to text by substituting ASCII text character groups for any non-ASCII characters, thus allowing you to treat binary encodings as text. The TypeCode is defined as: TypeCode := x0001 The RemainingArtifact field is composed of a SourceID followed by an AssertionHan- dle where: SourceID := 20 byte sequence AssertionHandle := 20 byte sequence. Copyright © OASIS Open (2001, 2002). All Rights Reserved Thus, for this release of the SAML specification, the artifact is 42 bytes long. The SourceID is to be used by the target to determine the identity of the source site. This encoding is not defined, but it is assumed that the target will store a table of source site identifiers keyed by SourceID. The source site identifier must be rich enough for the target to identify and contact the source site. The source site uses the AssertionHandle to locate an assertion for a particular browser user. It is assumed that the source site will keep a table of assertions or suffi- cient information to construct a particular assertion keyed by AssertionHandles. The requirement is that, when a source site is presented with an artifact, it will be able to return the correct assertion to the requestor. 124 Chapter 5 [...]... WS -Security SAML is used in a SOAP profile that is being developed by another OASIS technical committee, the Web Services Security TC That profile uses a specification called WSSecurity, which we discussed in Chapter 4, “XML Security and WS -Security. ” The Security Assertion Markup Language SAML TC has submitted a specification to the Web Services Security TC to include a SAML token The Web Services Security. .. securing Web Services that will tie together the security concepts we introduced in the last few chapters: XML security, WS -Security, and SAML CHAPTER 6 Principles of Securing Web Services In earlier chapters, we defined security services and explained how they could be provided In this chapter, we would like to focus on several of these security services and describe them within the context of Web Services. .. the Web Services interface, we are concerned about authentication, authorization, confidentiality, and integrity Web Services Example In our discussion of some of the details of securing Web Services, we’ll start with the Web Services online storefront example introduced in Chapter 1 We will extend the original purchasing scenario to provide an opportunity to discuss a variety of Web Services security. .. Services We will also look in more detail at possible security solutions and determine how they fit into security for Web Services We will do this by considering a Web Services usage scenario and seeing how the security solutions can be applied For this discussion, we will limit our scope to the Web Services interface That is, we will look at the security of XML-based SOAP messages, as they are communicated... ePortal via a Web Services client purchasing system in addition to using a browser Figure 6.1 illustrates the purchasing example 133 1 34 Chapter 6 Buyer: Joe eBuyer.com Purchasing System ePortal.com eBusiness.com ePortal.com accounting Figure 6.1 Web Services purchasing example Web Services operations can be complicated and can involve many different entities There is the initiator of the Web Services transaction,... user to the next tier to get work done securely under the identity of the user This topic will be covered in greater detail in Chapters 7, Security of Infrastructures for Web Services, ” 8, “Securing NET Web Services, ” and 10, “Interoperability of Web Services Security Technologies,” with a discussion of the several possibilities for supporting impersonation The authentication system can provide a... speaking, a Web Services issue since it does not occur at the Web Services interface Nevertheless, it is significant and we will discuss why later User Presentation Tier Application Component Tier Back-office Tier Web Server Display Preparation/ Business Logic Data Repository/ System of Record Single Enterprise Figure 6.2 Single domain, multitiered environment Principles of Securing Web Services User... browser rather than a Web Services client to start the transaction going Then, there is the Web Services subscriber, who will be a business or a business unit There are two Web Services subscribers in the example First, the eBuyer purchasing system is a service subscriber to ePortal eBuyer users may also be initiators of transactions at ePortal Second, ePortal is a subscriber to services provided by... assertion alone, the context of the WS -Security token must be resolved separately System Characteristics Given what we know about the possible security solutions, we need to understand some key characteristics of our system What authentication is already performed and can the results be used for Web Services? Most applications require some kind of authentication Since Web Services require cooperation between... RSA (ANSI 1998a) or DSA (NIST 2000) We discussed standards for signing messages in Chapter 4, “XML Security and WS -Security. ” These standards specify what portions of the message are signed, how the data is encoded, what algorithms are used, and other cryptographic parameters For Web Services, XML Signature and WS -Security are the logical formats to use They are tailored to SOAP and XML-based documents . discussed in Chapter 4, “XML Security and WS -Security. ” The 130 Chapter 5 SAML TC has submitted a specification to the Web Services Security TC to include a SAML token. The Web Services Security TC has. these security services and describe them within the context of Web Services. We will also look in more detail at possible security solutions and determine how they fit into security for Web Services. We. Securing Web Services CHAPTER 6 Figure 6.1 Web Services purchasing example. Web Services operations can be complicated and can involve many different entities. There is the initiator of the Web Services