Mastering Web Services Security phần 4 doc

want to use these addresses, so they provided that option. Another element is what is called an AuthorityBinding. This is information that may be used to contact the SAML Authority that made the assertion in case the target wanted to get additional informa- tion on the authentication. The AuthenticationMethod identifies the type of authentication that was carried out, while the AuthenticationInstant contains the time that the authentication took place. All times in the schema are in Coordinated Universal Time (UTC). Attribute Statement The attribute statement returns the attributes that the issuer of the assertion asserts are associated with the Subject identified in the common portion of the assertion. The schema definition of an attribute is: <element name=”AttributeStatement” type=”saml:AttributeStatementType”/> <complexType name=”AttributeStatementType”> <complexContent> <extension base=”saml:SubjectStatementAbstractType”> <sequence> <element ref=”saml:Attribute” maxOccurs=”unbounded”/> </sequence> </extension> </complexContent> </complexType> Where the attribute element contains the AttributeValues as shown below: <element name=”Attribute” type=”saml:AttributeType”/> <complexType name=”AttributeType”> <complexContent> <extension base=”saml:AttributeDesignatorType”> <sequence> <element ref=”saml:AttributeValue” maxOccurs=”unbounded”/> </sequence> </extension> </complexContent> </complexType> Similarly to the AuthenticationStatement, the AttributeType inherits from the Attrib- uteStatementType. The AttributeDesignatorType is included below. <element name=”AttributeDesignator” type=”saml:AttributeDesignatorType”/> <complexType name=”AttributeDesignatorType”> <attribute name=”AttributeName” type=”string” use=”required”/> <attribute name=”AttributeNamespace” type=”anyURI” use=”required”/> </complexType> Copyright © OASIS Open (2001, 2002). All Rights Reserved Security Assertion Markup Language 113 You may have noticed that it is easy to run into some terminology confusion in this fragment. The XML schema defines a term called an attribute, which we first encoun- tered in the fragment describing the SubjectConfirmation. Security also defines the term attribute, which is associated with a security principal. These two usages of the term attribute have totally disjoint meanings, so try not to be confused by them. As can be seen from the two schema fragments, the required elements of a security Attribute are a sequence of attribute values for that type. Attribute values may be of any type, which means that the type of an attribute value may be of any valid XML type, including structured types. Since the attribute is derived from an AttributeDesignator, an attribute inherits an AttributeName and an AttributeNamespace in which the AttributeName is defined. The representation of the attributes of a subject in the SAML schema is relatively straightforward. The problem lies in the interpretation of the attributes when the domain of the sender and receiver are not the same. We will discuss this problem in Chapter 10. Authorization Statement SAML authorization deals with conveying the decision on whether some action or actions may be performed on some resource. The algorithms necessary to reach an authorization decision may be very complex, but SAML itself is only concerned with delivering the outcome of that decision. Since the infrastructure for authorization may be complex, SAML does define a few additional constructs that can be involved in an authorization decision. These are a PEP, which is responsible for enforcing the results of an authorization decision. There also exists a PDP, where the authorization decision is carried out. In order to satisfy an authorization request the PEP makes a request on the PDP, passing authentication and/or attribute assertions as evidence that the PDP can use to make an authorization decision. SAML doesn’t say much about the decision-making process—this is left up to the XACML specification or some other access decision specification. The authorization statement portion of the SAML schema defines additional ele- ments that are used in making an authorization decision. The first of these is an action element that is used to describe what is to be done to the second element, the resource. The action has maxOccurs=”unbounded”, so you can have multiple actions on a resource. A simple example is authorization to read, write, and execute a file, where the file is the resource to be acted upon. Actions are not limited to the traditional operating system paradigms. An action may be the attempt to countersign a contract, where the action is countersign and the resource is the contract. Actions, like subjects, may be qualified by a namespace. As you can imagine, the authorization model is potentially very rich. In addition to the actions and resource, the specification lets you pass evidence to aid the PDP in making or confirming the authorization decision. The evidence takes the form of an assertion. As a result, you can pass an attribute assertion and/or an authentication assertion as evidence. Of course, since this is an authorization, we need an element to indicate whether the authorization was granted or not. Therefore, the schema also provides a decision element. 114 Chapter 5 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 [...]... 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... 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 and have the flexibility that is needed... 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... based on the message Resolving the intent of the signer is complex and varies from document type to document type These relationships are not within the scope of a standard For Web Services, the signer and receiver of a signed message must make sure that they agree on the meaning of a signature Principles of Securing Web Services While certain aspects of securing the signature are covered by the specification, . 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. developing. 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 WS- Security, . 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