The WS- Family of Security Specifications
| < Day Day Up > |
The WS-* Family of Security SpecificationsIn April 2002, IBM and Microsoft published a joint whitepaper called "Security in a Web Services World: A Proposed Architecture and Roadmap." [1] This whitepaper describes a far-reaching, comprehensive vision of a set of security standards and technologies meant to create a unifying approach for dealing with security in a Web services world. The proposed architecture attempts to bring together for Web services what, to date, had been disparate worlds in security. Just as WS-Security allows security mechanisms such as Public Key Infrastructure (PKI) and Security Assertion Markup Language (SAML)to participate in Web Services Security, the Web Services Architecture Roadmap generalizes many of the security functions that previously existed in other domains and proposes a framework for meeting the security requirements of the Web services domain. It provides an evolutionary strategy for putting the different pieces of the security puzzle in place. The proponents of this framework, and the standards bodies they are working through, are accomplishing this by first rolling out foundational specifications such as WS-Security (which, in turn , was built on XML Signature, XML Encryption, SAML, and various other security token standards) and then following with other standards that rely on these foundational standards. Figure 9.1 repeats the diagram shown previously in Chapter 7; in this figure, you can see the related WS-Security standards as well as the dependencies.
Figure 9.1. The WS-Security family of standards built on SOAP. As a quick review, WS-Security describes SOAP extensions for securing messages. It is a general-purpose mechanism for associating security tokens with SOAP messages. WS-Security builds on and is fully compatible with established, mature security technologies such as SSL, IPsec, XML Signature, and XML Encryption. It is designed to address message integrity, message confidentiality, message authentication, and the encoding of security tokens that must travel with the messages they are securing. WS-Security provides the foundations for the set of composable security building blocks in Figure 9.1 built on top of WS-Security. By composable , we mean that various building block standards can be combined to provide new and different security standards to solve specific security challenges. For example, WS-Privacy is composed from WS-Security plus WS-Trust and WS-Policy. These composable standards provide a "use only what you need" approach to securing Web services. The composable specifications still under development together with WS-Security are built on a core foundation of technologies such as SOAP, WSDL, XML Signature, XML Encryption, and SSL. What is amazing is that, with this model, for the first time users have an approach that allows integration of Kerberos, X.509/PKI, and other security models. Building up from WS-Security are the following composable building blocks:
Note The purpose of describing all these "standards" here, even when some of them are as yet unpublished, is two-fold. First, we hope our introduction to these evolving specifications will help you avoid re-inventing the wheel on an area you need for your Web services to be successful. Second, our goal is to let you know that significant work is being done on these standards, and progress is rapid. Consequently, if these standards are important to you, you will be able to find some useful guidance by scouring the Web and the standards bodies' repositories. WS-Security and the layers above it support what could be called the triangle of distributed message-based security that is composed of trust, interoperability, and integration. The triangle of WS-Security specifications is shown in Figure 9.2. Figure 9.2. The WS-* Security triangle of trust, integration, and interoperability. The first point of the security triangle is trust. Trust, of course, is fundamental to security. No trust, no security. In a Web services world, trust is very complex. Trust is represented in relationships; it can be explicitly established, or it may be presumed . Assertions are used to represent trust and trust relationships. WS-Trust is the WS-* security standard building block focused on trust relationships. The other trust-related standard in this point of the security triangle is WS-Privacy. WS-Privacy specifies the rules that must be followed when an entity trusts a service with its self-descriptive (that is, personally identifiable) data. The second point of the security triangle is interoperability. You can think of interoperability in terms of communication standards that allow distinct systems to cooperate. This capability is especially important when those communications are secured. Secure communications adhere to several different protocols, so interoperable secure communications must be able to map one protocol to another. Besides WS-Security itself, the two other WS-* security family standards that relate to interoperability are WS-Policy and WS-SecureConversation. The third point of the security triangle is integration. Web services' primary raison d'etre is for application and organizational integration. Integration involves one system that previously did not communicate with another extending its architecture to be able to do so. It means that existing services are reused for new purposes. This necessarily means that identities and the trust model under which they operate need to interoperate and do so across heterogeneous environments. An important issue this raises is federation. Federation is the agreement among a group of entities that they will share identities as well as the attributes of those identities with other members of their group. Two of the WS-* family of standards relate to integration: WS-Federation and WS-Authorization. WS-* Security Specifications for Trust RelationshipsThe following sections address the two specifications for trust relationships. First, we cover WS-Trust and then WS-Privacy. WS-TrustThroughout this book, we have described the technical issues around securing Web services. Although these issues can be complex, they are still only technical issues. By far, the most difficult issues arise around the more subtle business and personal issues of trust. Think about your own definition of trust and how you determine whom to trust. Do you trust someone who has been referred by someone else you trust? Do you trust in some people in relatively low-risk situations but not in a high-risk situation? How you determine trust might be called your personal trust model . A lot of work and thought has gone into defining, describing, and implementing trust models, and much of the complexity in Public Key Infrastructure technology derives from the complexity of modeling trust. A major Web services trust problem arises when credentials are issued in one trust domain and then presented in another. Say your employer, ABC Supply, is a supplier to XYZ Truck Company, and XYZ Truck Company has decided to expose its critical business systems to its suppliers. One strategy could be for XYZ Truck Company to directly issue credentials to each individual within every supplier and take on the management of these credentials. This would mean that, even if you do not work for XYZ, you would receive a credential from the company to present to its Web service when using its Bid for Order Web service. But how would XYZ Truck Company know if you were to be fired from ABC Supply or change positions ? It would be very difficult, if not impossible , for XYZ Truck Company to manage the credentials given to those privileged few employees of ABC Supply allowed to directly order at XYZ. Another approach that XYZ could choose is to blindly trust ABC Supply (and all its employees). From a technical perspective, this strategy might mean that X.509 certificates issued by ABC Supply (probably with certain attributes) could be presented to XYZ Truck Company for access to its Web services. You can probably see the trust issues here immediately. Perhaps these are highly sensitive capabilities that XYZ Truck Company is allowing access to, so much so that even its own employees must show up in person to be granted a credential. Suppose XYZ Truck Company has tight procedures for periodically refreshing credentials and revoking them when they are lost or the employee changes responsibilities. If ABC Supply Company does not have similar rigorous procedures, XYZ Company has seriously degraded its security by opening up the company to ABC's much lower standards. This level of trust becomes the arena of contracts and law because that is the way that companies express their trust, or lack thereof, and the way violations of that trust become enforceable. Prior to having secure communications, each party needs to determine whether it can "trust" the asserted credentials of the other party. WS-Trust defines extensions to WS-Security that provide
Similar to SAML, WS-Trust defines a request/response mechanism for obtaining security tokens. The most important attributes of WS-Trust to understand are
Security Token Services form the basis of trust by issuing security tokens that can be used to broker trust relationships between different trust domains. As Figure 9.3 shows, a Security Token Service is a trust broker ready and willing to provide a Web service with a way to determine whether it will trust an incoming request from a different (possibly unknown) trust domain. A policy statement at the Web service provider notifies the Web service requestor that a security token is required for use of this service. The requestor provides such a token, either having obtained it previously or by the requestor now sending a <RequestSecurityToken> to the Security Token Service. The so-obtained WS-Security “compatible security token is then provided when requesting service from the Web service provider. WS-Trust also provides for a challenge-response protocol for the Web service provider to strongly validate the efficacy and timeliness of the requestor's security token. The Web service security model defined in WS-Trust is based on a process in which a Web service can require that an incoming message prove a set of claims (for example, name , key, permission, capability, and so forth). If a message arrives without having the required proof of claims, the service ignores or rejects the message outright . A service can indicate its required claims and related information in its policy as described by the WS-Policy and WS-PolicyAttachment specifications described in detail in Chapter 8. A requestor can send messages that demonstrate its ability to prove a required set of claims by associating security tokens with the messages and including message signatures that demonstrate proof of possession of (the contents of) the tokens. If the requestor does not have the necessary token or tokens to prove the claim, it contacts a Security Token Service and obtains the tokens. These "authorities" may, in turn, require their own set of claims. The WS-Trust model illustrated in Figure 9.3 shows that any requestor may also be a service and that the Security Token Service is itself a Web service, including expressing policy and requiring security tokens. This general messaging model ”claims, policies, and security tokens ”subsumes and supports several more specific models, such as identity-based security, access control lists, and capabilities-based security. It allows use of existing technologies such as X.509 public key certificates, XML-based tokens, Kerberos shared-secret tickets, and even passwords. The general model, in combination with the WS-Security and WS-Policy primitives, is sufficient to construct higher-level key exchange, authentication, policy-based access decisions, auditing, and complex trust relationships. A quick overview of the WS-Trust model is that a Web service has a policy applied to it, receives a message from a requestor that possibly includes security tokens, and may have some protection applied to it using WS-Security mechanisms. The following steps are performed by the trust engine of a Web service:
If these conditions are met, and the requestor is authorized to perform the operation, the service can process the service request within the specified trust model just described. Now that you know how the model is supposed to work and you understand the key relationships between Web service provider, requestor, and Security Token Service, it's time to look at the two key WS-Trust elements needed to perform its prescribed functions: <RequestSecurityToken> and <RequestSecurityTokenResponse> . <RequestSecurityToken>Listing 9.1 shows a request to have a security token issued. Listing 9.1. The <RequestSecurityToken> Element<RequestSecurityToken> <TokenType>...</TokenType> <RequestType>...</RequestType> <Base>...</Base> <Supporting>...</Supporting> </RequestSecurityToken> Now let's explore each element that makes up a <RequestSecurityToken> element. <TokenType> The optional <TokenType> element describes the type of security token requested , specified as a QName (see the following section). That is, it describes the type of token that will be returned in the <RequestSecurityTokenResponse> message. <RequestType> The <RequestType> element is used to indicate, using a QName, the action that is being requested. The following QNames are predefined:
<Base> The optional <Base> element has the same type as the <SecurityTokenReference> element and references the base (primary) tokens that are used to validate the authenticity of a request. In general, this element isn't used because signatures provided on the request prove the right to make the request. <Supporting> The optional <Supporting> element has the same type as the <SecurityTokenReference> element and references the supporting tokens that are used to authorize this request. Typically, this element is used to identify tokens in a certificate authority. It is not required to specify any or all supporting tokens; it is simply a hint or aid to the recipient service. The example in Listing 9.2 shows an X.509 security token being requested based on the security token located in the <Security> header with the ID "myToken" . This token specifies a username, and a signature is placed over the request using a key derived from the password (or password equivalent), nonce, and time stamp. Listing 9.2. Requesting an X.509 Security Token Based on a Key Derived from a Password<S:Envelope xmlns:S="..." xmlns=".../secext" xmlns:wsu=".../utility> <S:Header> ... <Security> <UsernameToken wsu:Id="myToken"> <Username>NNK</Username> <Nonce>FKJh...</Nonce> <wsu:Created>2001-10-13T09:00:00Z </wsu:Created> </UsernameToken> <ds:Signature xmlns:ds="..."> ... </ds:Signature> </Security> ... </S:Header> <S:Body wsu:Id="req"> <RequestSecurityToken> <TokenType>wsse:X509v3</TokenType> <RequestType>wsse:ReqIssue</RequestType> <Base> <Reference URI="#myToken"/> </Base> </RequestSecurityToken> </S:Body> </S:Envelope> <RequestSecurityTokenResponse>The other half of <RequestSecurityToken> is <RequestSecurityTokenResponse> . The syntax for this element is shown in Listing 9.3. Listing 9.3. The <RequestSecurityTokenResponse> Element<RequestSecurityTokenResponse> <TokenType>...</TokenType> <KeyType>...</KeyType> <KeySize>...</KeySize> <wsp:AppliesTo>...</wsp:AppliesTo> <RequestedSecurityToken>...</RequestedSecurityToken> <RequestedProofToken>...</RequestedProofToken> </RequestSecurityTokenResponse> Let's look at each element in <RequestSecurityTokenResponse> in turn. <TokenType> The optional <TokenType> element specifies the type of security token returned. Either this element or the optional <AppliesTo> element should be specified. <TokenType> must be provided if a token type other than the requested type is returned. <KeyType> The optional <KeyType> element specifies the type of key used in the token. <KeySize> The optional <KeySize> element specifies the size of the key returned. <wsp:AppliesTo> The optional <wsp:AppliesTo> element specifies the scope to which this security token applies. The WS-PolicyAttachment specification deals with this scope in detail. <RequestedSecurityToken> The optional <RequestedSecurityToken> element is used to return the requested security token. Normally, this element contains the requested security token, but a security token reference may be used instead. For example, if the requested security token is used in securing the message, the security token is placed into the <Security> header, and a <SecurityTokenReference> element is placed inside the <RequestedSecurityToken> element to reference the token in the <Security> header. Although this element is optional, at least one of <RequestedSecurityToken> or <RequestedProofToken> will be returned unless an error occurs. <RequestedProofToken> The optional <RequestedProofToken> element is used to return the proof-of-possession token associated with the requested security token. Proof of possession is needed when the client does not provide the public key to use and signs (authenticates) this using the corresponding private key, thereby proving possession. Normally, this element contains the proof-of-possession token, but a security token reference may be used instead. The token (or reference) is specified as the content of this element. For example, if the proof token is used in securing the message, it is placed in the <Security> header, and a <SecurityTokenReference> element is used inside the <RequestedProofToken> element to reference the token in the <Security> header. Listing 9.4 is a sample response to a request for a security token. In this example, a pre-existing X.509v3 digital certificate, looked up in a directory and encoded into a security token, is returned. As is typical, this example does not return an explicit proof of possession because the client implicitly provided proof of possession by providing the public key to use (and authenticated it using the corresponding private key). Listing 9.4. <RequestSecurityTokenResponse> Returning a Pre-existing X.509v3 Certificate<RequestSecurityTokenResponse> <RequestedSecurityToken> <BinarySecurityToken ValueType="wsse:X509v3" EncodingType="wsse:Base64Binary"> MIIEZzCCA9CgAwIBAgIQEmtJZc0... </BinarySecurityToken> </RequestedSecurityToken> </RequestSecurityTokenResponse> ... WS-PrivacyWS-Privacy is a not-yet-published proposed standard that will use a combination of WS-Policy, WS-Security, and WS-Trust to communicate privacy policies. It is designed to be used by organizations that deploy Web services and require that incoming SOAP requests contain claims that the sender conforms to the service provider's privacy policies. WS-Security encapsulates these claims into security tokens that are verified before accepting any incoming SOAP request. WS-Privacy will be a standard that allows Web service providers and requestors to state their privacy preferences and organizational privacy practice statements. As of this writing, no public draft of WS-Privacy is available, but from the information that has been published, it will likely be similar to the W3C's Platform for Project Privacy Preferences (P3P). [2] P3P was primarily designed for the Web application world (versus the Web services world). It allows an organization to specify its privacy policy in a structured manner and post it on the Web server that is being accessed. Then a P3P-enabled browser can read this policy and compare it to the browser user's privacy preferences. Thus, a user can express her privacy preferences and be notified when she surfs to a site that has privacy practices that conflict with her stated preferences. In a similar manner, WS-Privacy will allow this type of privacy policy exchange and agreement for Web services.
As an example, an individual would state a set of "privacy preferences" that describe what the individual does or does not want to allow applications acting on his behalf to do with his personal information. A calendaring application, working on the individual's behalf , can now access a calendaring service that uses a set of "privacy practice rules" to make statements and decisions about use and disclosure of personal information. The calendar service makes the decision by combining the privacy practice rules with the privacy preferences to determine whether a proposed use or disclosure is permissible. WS-* Security Specifications for InteroperabilityThe following sections address the two WS-* security specifications for interoperability. First, we briefly review WS-Policy and then cover WS-SecureConversation. WS-PolicyWS-Policy was the subject of Chapter 8; we include a brief review of it here for its context within the WS-* family of specifications. WS-Policy is a family of three specifications. Version 1.1 of the WS-Policy documents include Web Services Policy Framework (WS-Policy), Web Services Policy Assertions Language (WS-PolicyAssertions) , and Web Services Policy Attachment (WS-PolicyAttachment) . The top level of these specifications is WS-Policy. It forms the framework by providing a general-purpose model and corresponding syntax to describe and communicate the policies of a Web service. WS-Policy defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements, preferences, and capabilities. WS-PolicyAssertions specifies a set of common message policy assertions that can be specified within a policy. WS-PolicyAttachment specifies three specific attachment mechanisms for using policy expressions with existing XML Web service technologies. Specifically, it defines how to associate policy expressions with WSDL-type definitions and UDDI entities. It also defines how to associate implementation-specific policy with all or part of a WSDL portType when exposed from a specific implementation. Overall, the WS-Policy family describes a language for expressing requirements of Web services senders, receivers, and endpoints. One type of policy requirement that will be placed on senders, receivers, and endpoints is the security of the extended conversation implemented in a Web service. Sounds like a requirement for a "secure conversation," doesn't it? As you will see, WS-SecureConversation does indeed sit on top of WS-Policy, reinforcing the statement that WS-Policy is a framework for richer Web Services Security constructs. WS-SecureConversationWS-SecureConversation, developed by IBM, Microsoft, RSA, and VeriSign, is in initial public draft form last published in December 2002. What SSL does at the transport layer in point-to-point communication, WS-SecureConversation does at the SOAP layer. It makes efficient what would otherwise be individual SOAP messages carrying authentication information in tokens that would have to be evaluated and checked against security policy. In contrast, WS-SecureConversation establishes a mutually authenticated security context in which a series of messages are exchanged. Despite being at the top of the stack and therefore initially considered one of the later specifications to be published, a draft of WS-SecureConversation [3] was published fairly early on.
WS-Security secures SOAP and thereby has a message-level security focus. But many Web service conversations span multiple messages and need an efficient way to secure those conversations. Furthermore, WS-Security is subject to certain kinds of attacks that can be thoroughly addressed only by authenticating a series of messages, not just one message at a time. WS-Security focuses on a single message authentication model in which the message itself must contain everything necessary to authenticate itself. This model can be inefficient considering that, if the exact same message comes in again and again, each time it would go through the same authentication/verification process, which is computationally expensive. WS-Security is well suited for coarse-grained messaging in which a single message at a time (or few in number) from the same requestor are received. When multiple messages are to be exchanged, establishing a security context can greatly improve efficiency. This security context, which contains a shared secret used by both parties to encrypt and/or sign, is shared among the communicating parties until the session expires . Like SSL, WS-SecureConversation uses public key (asymmetric) encryption to establish a shared secret key and from then on uses shared key (symmetric) encryption for efficiency. The same shared key is used to encrypt a series of SOAP messages. <SecurityContextToken>The structure of a WS-SecureConversation is based on the <SecurityContextToken> element. This element is a security token that describes a security context. This is the context that will apply to one or more messages to follow. The structure of <SecurityContextToken> is shown in Listing 9.5. Listing 9.5. The <SecurityContextToken> Element<wsse:SecurityContextToken wsu:Id="..."> <wsu:Identifier>...</wsu:Identifier> <wsu:Created>...</wsu:Created> <wsu:Expires>...</wsu:Expires> <wsse:Keys> <xenc:EncryptedKey Id=" ">...</xenc:EncryptedKey> <wsse:SecurityTokenReference>...</wsse:SecurityTokenReference> ... </wsse:Keys> </wsse:SecurityContextToken> The elements and attributes used in a <wsse:SecurityContextToken> element are described in the following sections. <wsu:Identifier> The required <wsu:Identifier> element identifies the security context using a URI. This security context URI must be globally unique to both the sender and recipient. <wsu:Created> The optional <wsu:Created> element indicates the creation time of the security context. It is typically specified only on the first use of the token. <wsu:Expires> The optional <wsu:Expires> element indicates the expiration time of the security context according to the requestor's clock. It is typically specified only on the first use of the token. <Keys> The optional <Keys> element holds the shared secrets of the security context. It is typically specified only on the first use of the token. If no <Keys> element is specified, the shared secret is assumed to be already known and associated with the security context identified by the URI specified in the <Identifier> element. <xenc:EncryptedKey> The optional <xenc:EncryptedKey> element holds the shared secret of the security context. <xenc:EncryptedKey/@Id> The optional <xenc:EncryptedKey/@Id> attribute specifies an "ID" for the key. Note that this does not use the wsu:Id attribute because the schema doesn't allow for attribute extensibility. <SecurityTokenReference> The optional <SecurityTokenReference> element references the shared secret of the security context. Establishing a Security ContextThere are three ways to establish a security context:
Security Context Token Created by a Security Token Service The initiator can ask a Security Token Service to create a new security context token. The newly created security context token is distributed to the parties through the protocols defined by WS-SecureConversation and WS-Trust. For this scenario, the initiating party sends a <RequestSecurityToken> request to the token service, and a <RequestSecurityTokenResponse> is returned. The response contains a <SecurityTokenReference> pointing to the new security context token and a <ProofTokenReference> pointing to the "secret" for the returned context. Security Context Token Created by One of the Communicating Parties and Propagated with a Message The initiator can create a security context token and send it to the other parties on a message using the mechanisms described here and in WS-Security. This model works when the sender is trusted to always create a new security context token. For this scenario, the initiating party creates a security context token and issues a signed unsolicited <RequestSecurityTokenResponse> to the other party. The message contains a <SecurityTokenReference> pointing to the new security context token and a <ProofTokenReference> pointing to the "secret" for the security context token. The recipient can then choose whether to accept the security context token. Security Context Token Created Through Negotiation When participants need to negotiate about the contents of the security context token, such as a shared secret, WS-SecureConversation allows the parties to exchange data to establish the security context. For this scenario, the initiating party sends a <RequestSecurityToken> request to the other party, and a <RequestSecurityTokenResponse> is returned. It is likely that the negotiation (challenge/response) semantics described in WS-Trust will be used. Ultimately (if successful), a final response contains a <SecurityTokenReference> pointing to the new security context and a <ProofTokenReference> pointing to the "secret" for the context. After the shared secret security context token is established for both parties, it is used within WS-Security to secure each message sent as part of a WS-SecureConversation. This scenario is shown in Listing 9.6. Listing 9.6. Use of a Shared Secret Security Context in WS-Security as Part of WS-SecureConversation<?xml version="1.0" encoding="utf-8"?> <S:Envelope xmlns:S="..." xmlns:ds="..." xmlns:wsse="..."> <S:Header> ... <wsse:Security> <wsse:SecurityContextToken wsu:Id="MyID" <wsu:Identifier>uuid:...</wsu:Identifier> </wsse:SecurityContextToken> <ds:Signature> ... <ds:KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="#MyID"/> </wsse:SecurityTokenReference> </ds:KeyInfo> </ds:Signature> </wsse:Security> </S:Header> <S:Body wsu:Id="MsgBody"> <tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads"> QQQ </tru:StockSymbol> </S:Body> </S:Envelope> Listing 9.6 is a standard SOAP message, so it begins with a SOAP message header followed by the SOAP body. The SOAP header contains the WS-Security <Security> header block, which contains the security-related information for the message. Inside the WS-Security block is a security token associated with the message inside a <SecurityContextToken> element. A URI within this element specifies the unique ID of the context. The digital signature uses the security context just established ”in this case, based on the secret key associated with the context. The contents of the XML Digital signature here are represented with ellipses ( ... ) but would reference the body of the message. The <ds:KeyInfo> element holds the key used for the signature. Not surprisingly, it will be the security context token included in the message and therefore will just refer to the URI that is the unique ID of the context specified earlier. The body of the message comes next and is shown here with another ellipsis. Much, if not all, of what is described here will be handled for you by the application server platforms and the development tools that support them. It is important to know what they are doing and why, but the details are hidden behind your development tools. WS-* Security Specifications for IntegrationIntegration, in the context of Web Services Security, is the federation of identities and uniform authorization policies. Federation is the integration of trust domains across organizational boundaries and is addressed by WS-Federation. Authorization is the unification of access control policies across organizational boundaries and is addressed by WS-Authorization. WS-FederationWS-Federation enables the establishment of federated trust using WS-Security, WS-Policy, WS-Trust, and WS-SecureConversation as composable building blocks. Federation in this context means that a group of organizations that will have communicating Web services agrees on a uniform set of standards and policies about identification and authentication of entities for the purpose of translating one entity's security tokens into another type of security token. For example, WS-Federation solves the problem of one organization using Kerberos and the other with which it wants to communicate using X.509. WS-Policy and WS-Trust are used to determine which tokens are consumed and how to apply for tokens from an external service. Figure 9.4 illustrates one way the WS-Trust model may be applied to simple federation scenarios. Here, security tokens (1) from the requestor's trust realm are used to acquire security tokens from the resource's trust realm (2) to access the resource/service (3). That is, a token from one Security Token Service (STS) is exchanged for another at a second STS (or possibly stamped or cross-certified by a second STS). Figure 9.4. Simple federation scenario allowing requestor in one trust domain to interact with a resource in a different trust domain using different security models. Next, Figure 9.5 shows the detailed sequence of steps used to exchange security tokens between a requestor Web service and the Web service provider resource. Figure 9.5. Eight-step process used in WS-Federation to cross different trust domains with a security token. This process is as follows :
WS-AuthorizationWS-Authorization deals with authorization decisions in the context of Web services. It describes how access policies for a Web service will be specified and managed. As of this writing, no specification has been published for WS-Authorization. Its objectives are similar to the eXtensible Access Control Markup Language (XACML) and will undoubtedly be heavily influenced by it. |
| < Day Day Up > |
EAN: 2147483647
Pages: 119