Mastering Web Services Security phần 8

Interoperability of Web Services Security Technologies 303 Client (Initiator) Object P1 Figure 10.3 Intermediate Object P2 Delegation scenario. SOAP Header Initiator Security Claims Identity/attribute tokens Delegation Constraints Identities that may act as delegates Transport Layer Transport identity (certificate) Target Object Figure 10.3 also shows the credential tokens that may be passed from intermediate P2 to the target object as part of the SOAP header. In this example, the SOAP header transmits the delegation constraints, which identify the intermediates that are permitted to act as delegates, and the initiator security claims, which contain the identity and other attributes of the initiating client. Although the standard WS-Security elements do not yet address constrained dele-gation, we can use a separate non-standard (but legal) WS-Security element that con-tains the identities of delegates. These identities define the intermediates that the client trusts to act as delegates on the client’s behalf. Initiator security claims may be trans-mitted as usual in a standard WS-Security element (containing SAML or other tokens) as described in Chapter 4. To ensure that the delegation constraints and initiator claims are bound to the SOAP message body, the initiating client should provide a digital signature based on both WS-Security elements as well as the SOAP message body. The intermediate transmits its identity to the target object by the underlying secure transport layer, using, for example, an X.509 certificate via SSL. The described implementation would work as follows for our delegation scenario: When the accounting system (target object) receives the SOAP message, it (1) verifies the identity of the purchasing system (intermediate P2) by SSL mutual authentication, (2) checks whether the purchasing system identity is in the delegation constraints list, and (3) verifies the digital signature on the WS-Security elements and message body. If these checks succeed, then the accounting system retrieves the initiating client from the initiator security claims and uses the initiating client’s attributes to authorize the client’s request. It is also straightforward for this same approach to support the simplest type of del-egation, namely impersonation. In this case, the initiating client makes the same request on the intermediate, but this time allows any target to impersonate the client by passing a wild card value for the delegation constraints. Without any constraints, there is nothing that prevents the intermediate from abusing the client credentials by making 304 Chapter 10 unauthorized requests on behalf of the client. If the request is low risk, for example, a request for a catalog, and the client doesn’t care about its privacy, then impersonation may not be a problem. However, how does the client know that the intermediate can be trusted not to use its credentials to do harm to the client? Delegation constraints can elim-inate this threat, at the price of a more complex implementation and security policy. The current working draft of the SAML binding of WS-Security also has an approach for impersonation. In this approach, the requesting intermediate vouches for the verification of the client subject. The target must trust the intermediate to vouch for the identity of the client. In this case, the client has not delegated rights to the interme-diate and has no control over who are trustworthy delegates. Consequently, this method will be applicable in cases where the only trust required is between the target receiver and the intermediate. Note that this working draft is ongoing, and the support for delegation may change before the standard is completed. The SAML specification describes authentication, attribute, and authorization authorities, which could be designed to handle the requisite delegation functionality. However, these authorities are outside the scope of the present SAMLspecification and no details have been worked out, especially for the type of Web Services delegation problem that we have described in this section. A possible alternative to delegation is for the client to send a signed SOAP request that contains portions encrypted with the public key of the target. By encrypting the data, the “tunneled” request will not be readable by any intermediates. This approach can be an effective way for a client to transmit requests through potentially untrust-worthy intermediates. However, the approach will only work if there is no require-ment for intermediates to access the encrypted data in the request. Additional countermeasures may need to be in place to prevent untrustworthy intermediates from launching replay attacks by resending the client request, further complicating the approach. Transmitting encrypted data between a client and the ultimate recipient also requires that the client obtain the public keys of the recipients, and vice versa. This brings up the complexities of PKI. Although PKI technology has been around for some time, it is not trivial to implement, so it is usually used in situations where extensive security is required. The client could get the public key of the targets by first retrieving the service name from the UUDI and then, using PKI, retrieving the public key from a certificate author-ity, using the service name. This is a somewhat ad hoc solution in that the service name must match the one the CAuses for that service, and the client also has to know the cor-rect CAto ask for the key and trust that CA. Delegation in Web Services is another of the reasons for our contention that Web Ser-vices will first be used and perfected within a single enterprise, on an intranet, and then used between a small number of partner companies, on an extranet. In these cases, there is a controlled environment, and issues relating to key management and trust can be worked out. Once people have experience with intranet and extranet Web Services security, we can move to Internet Web Services security. This does not mean that we cannot use Web Services security in the Internet today in constrained cases, but you should be aware that delegation across the Internet will be a risky proposition for some time to come. We will now move on to describing how you would use an EASI framework as the security authority in your Web Services solution. Interoperability of Web Services Security Technologies 305 Using a Security Framework We introduced the concept of an Enterprise Application Security Integration (EASI) security framework in the first chapter. We will look at a security framework as a means of solving the range of security interoperability problems associated with Web Services described in this chapter and as an early model of a SAMLauthority. So what, exactly, is an EASI framework? It’s a flexible framework that integrates security tech-nologies and products from multiple vendors across the perimeter, middle, and back-office tiers—both within a single enterprise and across multiple enterprise domains. In our definition, a security framework is a middleware system that intercepts incom-ing messages before they reach the application and performs one or more security functions. As a result of these activities, the incoming request is either allowed to con-tinue or it is denied. The activities that a security framework performs are those of authentication, attribute retrieval and mapping, authorization, and auditing. Aframe-work should be able to carry out these activities between heterogeneous applications and security technologies, and it should know how to use the Web Services protocols that we have been discussing, that is, XML, SAML, WS-Security, digital signatures, XML Encryption, and PKI. Our overview in Chapter 1 portrayed an end-to-end solu-tion for securing a message traversing a complete Web Services process from the client through the perimeter, through the mid-tier, and finally to the back-office tier. In this section, we will show how the framework uses the Web Services technologies that we have described in the earlier chapters. Figure 10.4 will help you visualize the client and target security interactions that we describe. In this example, we assume a separate EASI framework for the client and the target and a variety of specialized security services that the framework uses. There are different variations of the EASI framework architecture, for example, both the client and the target could use the same framework if they were part of the same enterprise. However, the basic concepts of an EASI Framework remain the same regardless of its variation. That is, it reduces the need for custom-coded security, it offers a consistent security interface among disparate security products, and it facilitates the nondisrup-tive evolution of security services. Client Use of EASI Atypical scenario for a Web Services activity using an EASI framework starts with the client authenticating itself with the EASI system, as shown in Figure 10.4. An EASI sys-tem is the complete implementation of an EASI framework that includes the adminis-tration and internal security between the different parts of the framework system. The EASI system may be controlled or run by a trusted third party. Alternately, the client could control the EASI system if the target Web Service trusts the client’s EASI system to generate authentication assertions for users. In either case, the client would make a SOAPcall, passing the authentication evidence to the EASI system, either as encrypted data in the WS-Security header or using point-to-point protection and mutual authen-tication, for example, SSL. Since a minimum amount of security functionality is usually required to be in the client application, we recommend that the EASI client-side framework carry out all the client security work. Thus, the client would pass the SOAP message to the framework, 306 Chapter 10 where the signing, encryption, and authentication would be carried out. Note that this does not mean that the message has to be sent to remote parts of the framework. Effi-cient implementations of the framework permit processing of the message to be collo-cated with the client’s host. Although you could do the security in the application, we strongly advise against putting the security at the application level, as we have stated repeatedly throughout this book. In addition, client-side applications are usually required to be simple to implement. Therefore, the more security that you want on the client side given this restriction, the more necessary a security framework becomes. In this example, the SOAP message that is passed to the EASI framework is the message that will eventually be sent to the target. The EASI framework will use the authentication evidence to authenticate the user. The framework takes the incoming SOAP message and extracts the authentication data, then, using policy information set by the administrator, the framework chooses an authentication service to perform the actual authentication. By using an EAI approach for the framework, the authenti-cation service could be switched to a different authentication service without per-turbing the system. The framework then creates a standard credential, for example, a SAMLauthentica-tion assertion, and inserts the assertion into the proper WS-Security header. The frame-work signs and encrypts the parts of the message as dictated by the security policy or by the instructions received from the client. It then returns the secured SOAP message to the client for transport to the service. Client SOAP Target WS-Security SAML SOAP SOAP Authentication Evidence WS-Security SAML WS-Security SAML EASI Framework EASI Framework Authentication Authority Signature Authentication Service Attribute Authority Encryption Attribute Service Authorization Authority Signature Verification Authorization Service Attribute Authority Decryption Attribute Service Figure 10.4 Security architectures using EASI frameworks. Interoperability of Web Services Security Technologies 307 There are a number of steps in the previous scenario for which standards have not been developed. For example, there are no standards for a request to a third-party authority that it sign or encrypt certain parts of a SOAPmessage as SAMLhas done for its assertions. Similarly, there are no standards to request that a third-party service authenticate itself using the evidence in the SOAP security header and insert proof of the authentication in the header. There is also the problem of attribute mapping, which we discussed earlier. Although there are emerging approaches to providing general authentication ser-vices, such as Microsoft Passport and Liberty Alliance, the technology in this area is very immature. The lack of mature standards or products for the distributed authenti-cation authorities point to the use of a framework that is local to the client. As some of the specification work is completed and third-party services become available, the framework can offload some of the tasks to a third party. However, the local client security service will still be needed to do some of the initial security work, such as pro-tecting the message, vectoring the request to the appropriate third parties, coordinat-ing the security data from the third parties, and auditing the activities. Target Use of EASI As shown in Figure 10.4, once the target has verified the message and mapped the appropriate attributes, the target calls on the framework to authorize the action that the client requests to perform on the resource. The targets or providers of Web Services have security interoperability problems similar to those described for the client side. There is the request/response problem when using third-party authorities and establishing trust. The provider side of a Web Services system may also require specialized security services. Its security require-ments are usually stricter and more complex than the client’s, since it has the require-ment to protect its resources, and its implementation is more complex, whereas the usual desire is to make the client lightweight. The target-side interoperability problems lie with verifying the incoming message. To verify the message, the target must be able to interpret any authentication data that it receives from the client. (Recall our discussion of this problem in the Shibboleth con-text in Chapter 5.) Next there is the problem of attributes. Has the client done the cor-rect mapping, and does the target trust the attributes sent from the client or does it want to pull the attributes from some repository? If the target wants to pull the attrib-utes, from where does it get the attributes? The interoperable attribute problem has a lot of the same characteristics as the authentication problem. However, it is more com-plex because of the semantics associated with an attribute. Apassword is either correct or incorrect, but the same attribute does not necessarily imply the same privileges to the client and the target. Securing the Example We will use an EASI framework to extend our Web Services examples that we intro-duced in Chapters 8, “Securing .NET Web Services,” and 9, “Securing Java Web Ser-vices.” Figure 10.5 depicts the architecture of a solution based on an EASI framework. ... - tailieumienphi.vn