Mastering Web Services Security phần 8 ppt

Figure 10.3 Delegation scenario. 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 Intermediate Object P2 SOAP Header Initiator Security Claims Identity/attribute tokens Delegation Constraints Identities that may act as delegates Transport Layer Transport identity (certificate) Target Object Client (Initiator) Object P1 Interoperability of Web Services Security Technologies 303 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 SAML specification 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 CA uses for that service, and the client also has to know the cor- rect CA to 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. 304 Chapter 10 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 SAML authority. 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. A frame- 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 A typical 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 SOAP call, 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, Interoperability of Web Services Security Technologies 305 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 SAML authentica- 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. Figure 10.4 Security architectures using EASI frameworks. Client EASI Framework Target SOAP SOAP WS-Security SAML Authentication Evidence Authentication Authority Authentication Service Attribute Service Signature Attribute Authority WS-Security SAML SOAP WS-Security SAML Encryption EASI Framework Authorization Authority Authorization Service Attribute Service Signature Verification Attribute Authority Decryption 306 Chapter 10 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 SOAP message as SAML has 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. A password 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. Interoperability of Web Services Security Technologies 307 The framework connects applications, presentation components, business compo- nents, and/or legacy components to third-party security services, which supply authentication, authorization, and other security services. Going back to our examples in Chapters 8 and 9, the framework could connect .NET or Java applications with each other or with various security services. There could be a variety of security services in the implementation: an authentication service from Microsoft, an authorization service from RSA, an attribute service from Verisign, or many others. In the EASI paradigm, this mix and match lets you choose the best security product for the service required, so any mixture of security services may be used. The framework, in addition to con- necting the security products to the applications, maps Web Services security mecha- nisms to the traditional security solutions. The application connects with the EASI framework by means of an adapter that calls the framework APIs. In our sample implementation of an EASI framework, we have supplied simple APIs (the Security API layer in Figure 10.5) for authentication, attribute retrieval, and authorization. These APIs hide the particular mechanism for transmitting the security information, for example, SAML assertions, from the devel- oper. As a result, the developer does not have to know the intricacies of SAML. Framework Authentication The examples that we discussed in previous chapters assumed that client authentica- tion was handled by existing browser to Web server security mechanisms. Alterna- tively, there are many situations where the EASI framework could be used for Web Services authentication. For example, a Web Services client may call into your Web Ser- vices system, passing the security evidence for authentication in a WS-Security token. Figure 10.5 The EASI framework architecture. Authentication Products Authorization Products Cryptography Products Accountability Products Security Administration Products Authentication Core Security Services Custom Security APIs Security APIs Enterprise Application Security integration Framework Presentation Components Authorization Cryptography Accountability Security Administration Framework Security Facilities Proxy Services Security Association Profile Manager Vendor Security APIs Standard Security APIs Business Logic Components Back-office Data Stores 308 Chapter 10 We extend our examples from the previous chapters, assuming that the initiating client will authenticate at ePortal by passing a SAML authentication assertion via WS- Security to the EASI adapter for the Web Service. In this case, the adapter calls the verify API on the framework, passing it the SAML assertion in the form of an abstract token. There are two ways to handle authentication in the Web Services example when the client sends a security-enabled SOAP message. The first is to have the application layer parse out the relevant security information and pass just the security evidence to the framework. There is some merit to this approach, because the application layer has to parse the SOAP message to determine what information the body contains. For example, the SOAP body may contain the methods that should be called on the Web Service. However, in many cases it is not that straightforward. One complicating factor is that portions of the body may be encrypted. In this case, the application layer would have to understand how to handle XML encryption, which is no easy task. Some of the data may be integrity checked, that is, signed. In this case, the application will need to handle PKI and digital signatures. In addition, the authentication evidence may be in one of a number of different forms, for example, Kerberos or X.509 certificates. This approach forces the application to implement security logic, which is the very thing we want to avoid. Since one of the basic concepts of an EASI framework is to relieve the application of becoming aware of the complexities of security, it would be better to pass the SOAP message to the framework and have the framework handle all the aspects of security. The framework could then extract the relevant security evidence, verify any signa- tures, verify the validity of the issuer of any assertions, and perform the authentication. However, passing the whole SOAP message to the framework could be prohibitively expensive. You will need to determine the right trade-off between efficiency and com- plexity of your Web Service applications. Decryption and verification of the body of the SOAP message would normally be handled during an authorization call to the framework, since that is when you will need to use the information in the body. We’ll cover this in the framework authoriza- tion section later in this chapter. Note that the examples in the following subsections use sample APIs from a hypo- thetical framework implementation. Specific vendor implementations of an EASI framework will have different APIs for accessing the framework’s functionality. How- ever, the functionality required of an EASI framework is similar regardless of the syn- tax that it may use. The authentication API of the EASI framework could look something like the following: AuthenticationResponse authenticate( String mechanism, String security_name, String authentication_data ) throws AdapterException; If authentication is based on the data in a SOAP message, the Web Services applica- tion would send the SOAP message in the authentication_data parameter, and the Interoperability of Web Services Security Technologies 309 authentication mechanism would be SOAP. A SAML authentication assertion is returned in AuthenticationResponse. The documentation of the particular framework will describe the APIs that are supplied for passing the security data. Using this gen- eral API permits the EASI system to handle more than just SOAP, so that other authen- tication mechanisms may be accommodated. Framework Attribute Handling Going back to our example, if the user has been authenticated and the SAML assertion has passed verification, we next want to get the attributes for the user. The Web Ser- vices application will then call the get_attributes API on the EASI framework: AttributeResponse get_attributes( Token token ) throws AdapterException; where the token that is passed to the framework is the SAML authentication assertion and the AttributeResponse is a SAML attribute assertion. The framework parses the SAML authentication assertion, and using the information in the assertion, such as the subject name, calls the appropriate attribute service, which retrieves the attributes for subject. Alternately, when the framework receives the get_attributes call, it may map the SAML attribute request into a call to the persistent store that contains the user attributes. The authentication assertion would be supplied to the target application either as a result of the authentication call or as part of the SOAP message. When the framework receives the attributes by either method just described, it constructs a SAML attribute assertion and passes this back to the Web Services application. The application then uses the attribute assertion to make an authorization call on the framework. Framework Authorization The Web Services application could use the attributes, passed to it by the framework, to enforce the authorization function defined on the .NET or Java platform, which is supplied by the application server. Alternately, the Web Services application could call the authorization API on the EASI framework, as follows: AuthorizationResponse get_authorization( Token token, ScopedName resource, ScopedName action, NameValueMap instance_attributes ) throws AdapterException; The token parameter is the SAML attribute assertion. ScopedName is a structure con- taining the domain and the name itself. The resource identifies the data for which 310 Chapter 10 access is requested. The action is to access a specific method on the resource. This could be the GetProductPrice or SetProductPrice in our example. The framework will route the authorization call to the security service that has been set by policy and return the sta- tus of the authorization call in the AuthorizationResponse. In this example, the AuthorizationResponse is a reference to an object that implements the following interface: interface AuthorizationResponse { public static final int ALLOWED; public static final int DENIED; public boolean access_allowed(); public int get_reason(); } Using the status of the authorization call, the Web Services application can then per- mit or deny access. We mentioned earlier that, in the situation where the SOAP message contained encrypted portions of the body, it would be preferable for the framework to handle the decryption. This would be accomplished by passing the SOAP XML document to the framework in a helper function. There must be a trust relationship between the calling application and the framework, since we are decrypting potentially sensitive data. The decryption could be accomplished by an API as simple as: Token decrypt( Token token) throws AdapterException; The Token would be the SOAP message and the return Token would be the decrypted SOAP message. The XML Encryption specification from the W3C details how to encrypt and decrypt XML messages. This specification is referenced in WS-Security as the way to encrypt and decrypt SOAP messages. Consequently, when the SOAP document is sent to the framework, the framework will decrypt the portions of the body and replace the encrypted data with the decrypted XML text, following the XML Encryp- tion specification. Example Using JWSDP Now that we have explained our example using an EASI framework, we will show you how you would use the framework with an extended version of our JWSDP example introduced in Chapter 9. Figure 10.6 depicts the architecture of this example. Here we see a JWSDP client at ePortal.com calling on a JWSDP servlet in eBusiness.com. Interoperability of Web Services Security Technologies 311 Figure 10.6 The EASI framework architecture using JWSDP. StoreFront Client We present the code from the previous chapter where our StoreFrontClient calls from ePortal using JAXM, now extended to use an EASI framework. 1. package com.StoreFront; 2. import javax.xml.soap.*; 3. import java.util.*; 4. import java.net.*; 5. public class StoreFrontClient { 6. public static void main(String [] args) { 7. try { 8. SOAPConnectionFactory scf = 9. SOAPConnectionFactory.newInstance(); 10. SOAPConnection con = scf.createConnection(); // Call the security framework. // Get a reference to the framework using the approach // described by the framework. Then call the authenticate // method. SOAP ePortal.com JWSDP Java Application AN AR AZ eBusiness.com JWSDP Java Service (Servlet) EASI Security Framework 312 Chapter 10 [...]... solutions are not readily available 317 3 18 Chapter 10 Web Services Support for EASI So far we have discussed how EASI can support Web Services security However, we should also examine the reverse relationship: Can Web Services support EASI? That is, how could Web Services be used to connect an application securely to the EASI framework? If we wished to use the full Web Services paradigm to connect with the... would administer security in a Web Services environment and make your administration efficient and scalable 323 CHAPTER 11 Administrative Considerations for Web Services Security Up to this point, you’ve learned all about developing secure Web Services: from SOAP security, to security of the implementation platforms, to specific mechanisms for creating secure applications that utilize Web Services The... What about Web Services? There are two parts to security administration of Web Services: (1) administering the policies that govern protection mechanisms of enterprise Web Services, and (2) administering the advanced data protection features of the SOAP architecture Depending on what capabilities of SOAP you use, one or both of these areas may be important to you You might end up using Web Services as... by entering your system through the Internet The goal of Web Services is to allow anyone to discover your services through UDDI and connect to you based on the information in the downloaded WSDL file that is supplied through the UDDI On the other hand, the goal of Web Services security is to control who may access resources at a site Before Web Services are ready to be used ubiquitously on the Internet,... interoperability when using Web Services We looked at where you might need to address interoperability both from the viewpoint of crossing the boundaries between security tiers and from the viewpoint of the standard security technologies of authentication, privilege attributes, and authorization Interoperability of Web Services Security Technologies We identified the need for a universally accepted security context... Web Services interoperability possible Two other concepts are also necessary to enable interoperability: end-to-end security rather than point-to-point security and the use of standardization in solving the interoperability problem The two most useful standards that we discussed are WS -Security, which supports end-toend security, and SAML, which standardizes a credential format We also identified security. .. that it performs all the security functionality We hope that the lessons of Web Services security that you learn throughout this book will 315 316 Chapter 10 prepare you to carry out this task Remember that the ultimate responsibility for the security of your company and its data rests with you You also need to know what is going on beneath the covers to judge how you can use the security middleware in... reduce the number of integrated connections between applications and security services (compared to custom point-to-point connections between applications and security services) ■ ■ Supply solutions for the set of problems that we discussed by having a means to transparently use third-party products ■ ■ Permit easy substitution of security services without perturbing your running system ■ ■ Supply internal... not have to be concerned with this level of security detail The returned string, the security SOAP header element, would be inserted into the header after line 18 Note that this example only supplies the authentication proof, the SAML assertion, in the header element A more extensive framework would also handle signing the Interoperability of Web Services Security Technologies header, cryptographically... into your architecture Finally, we suggested that Web Services would first be used in intranets and extranets rather than on the Internet because the solutions to the secure interoperability problems are more manageable when it’s possible to coordinate between the various users of Web Services We pointed out that the solutions to securely using Web Services over the Internet have not yet been fully . 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. Technologies 317 Web Services Support for EASI So far we have discussed how EASI can support Web Services security. However, we should also examine the reverse relationship: Can Web Services support. 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