Best Practices for web services, Part 12: Web services security, Part 2

WS-Security in real-world solutions Holt Adams, Senior Consulting IT Architect, IBM jStart Summary: Conducting business in today's world usually requires that a company use the Internet for both business-to-customer and business-to-business interactions. Information exchanged in business transactions is often mission-critical, market-valued, or confidential; thus, while traversing the Internet, it must be protected from accidental access or deliberate unauthorized control and use. Understanding the impact of how security options in a Service-Oriented Architecture (SOA) leverage web services can enable you to make the best selection of security technology to address your requirements for authentications, data integrity, and confidentiality. Continuing from the previous article on web services security, Part 2 of this article outlines WS-Security capabilities leveraged in real-world customer solutions with IBM WebSphere Application Server. Tags for this article: architecture, on_demand_business, security, soa_(serviceoriented_architecture), ws-security Tag this! Update My dW interests (Log in | What's this?) Skip to help for Update My dW interests Date: 30 Mar 2004 Level: Introductory Also available in: Japanese Activity: 19894 views Comments: 0 (View | Add comment - Sign in) Average rating (13 votes) Rate this article

Show articles and other content related to my search: saml Show descriptions | Hide descriptions

Introduction The vendors that participate in the development of the WS-Security specification in the OASIS standards body have been actively testing interoperability scenarios similar to the one outlined in Part 1 of this article (see resources). The OASIS working group's primary focus is on the usability and compliance of the specification by vendors, not on a

comprehensive interoperability suite or benchmark. The success of the scenario in Part 1 can be expected when both the Consuming Application and the Service Provider are on the same vendor's platform, for example, IBM WebSphere Application Server. Work is still needed with interoperability between different vendors' platforms, however, progress has been made via the informal OASIS testing. Upon authentication of a party in a web services transaction, a company's security policy often needs to be enforced. With a user's identity known as a result of a successful authentication, the application server such as WebSphere Application Server can perform authorization to ensure proper access control of the application's resources, for example, web services. Considering the scenario in Part 1, the identity provided in the X.509 certificates (distinguished name), can be used within the WebSphere Application Server J2EE security model for authorization, after the parties have been authenticated through the successful validation of a digital signature.

Back to top WebSphere Application Server support of WS-Security WebSphere Application Server V5.02 supports XML Digital Signature and XML Encryption as outlined by the WS-Security specification draft that was available when V5.02 shipped at the end of 2003. The WS-Security specification is in its final approval process within OASIS. WebSphere Application Server will adopt any changes to the approved specification. The WebSphere Appplication Server's WS-Security function allows the enablement of capabilities during deployment of the web services implementations through a declarative model. In order to utilize WS-Security with WebSphere Application Server, you do not actually have to enable the WebSphere Application Server's J2EE Security. The trade-off you must consider is that without WebSphere Application Server Security, you will not be able to set the security context in the thread of execution or leverage WebSphere Application Server for coarse or fine-grain authorization to web services or their operations. WebSphere Application Server is able to support the scenario outlined in Part 1. One important aspect of the scenario is that for the Service Provider supporting a large number of consumers, few administrative tasks are required. The only administrative prerequisite for using WS-Security between itself and Consuming Applications is for the Service Provider's local keystore to have the root certificate of the Certification Authority that issues the Consuming Application's certificates. For complete information on WebSphere Application Server support of WS-Security, see the links provided in the Resource section of this article. The following provides an overview of WebSphere Application Server's support of WS-Security as applicable to customer scenarios covered in this section.

WebSphere Application Server supports XML Digital Signature as follows:

Web services request messages might have the following elements signed by WebSphere Application Server: o Security Token (UsernameToken, XML based token) in the SOAP header o TimeStamp in the SOAP header o Body in the SOAP envelope Web services response messages might have the following elements signed by WebSphere Application Server: o TimeStamp in the SOAP header o Body in the SOAP envelope

WebSphere Application Server supports XML Encryption as follows:

Web services request messages might have the following elements encrypted by WebSphere Application Server: o Security Token (UsernameToken only) in the SOAP header o Body in the SOAP envelope Web services response messages might have the following elements encrypted by WebSphere Application Server: o Body in the SOAP envelope

WebSphere Application Server V5.02 and V5.1 currently support the various algorithms for WS-Security that are listed below: Digest Method

SHA-1

Signature Methods

PKCS1 (RSA-SHA1) DSA

Key Encryption Methods

RSA Version 1.5 CMS Triple DES Key Wrap

Encryption Methods

Triple DES

Back to top

Customer WS-Security scenarios Although approval for WS-Security specification from OASIS is not available at this time, customers can still utilize the capabilities in proofs of concept or pilot solutions to gain hands-on experience and to access its potential impact on their solutions' performance. Below are three real-world customer uses of WS-Security. Business-to-business using a business identity credential Two partners had business requirements to better integrate their applications to improve overall cycle times for customer and employee facing processes. The security model between the two partners relied on a shared business identity credential for the Consuming Application party and X.509 certificates for both parties. At the time, the corporate security policies of the businesses stated that all confidential information exchanged between the parties be protected using HTTPS between the boundary nodes at each enterprise. For each web services request, the body of the SOAP message contains the web services operation and associated message parts that are digitally signed using X.509 certificates. One of the signed message parts includes the Consuming Application's business identity and secret password. The Service Provider uses the credentials to perform authorization in controlling access to the back-end business functions. The Service Provider used this method, as authorization logic resides in the back-end legacy systems. This solution provides only coarse-grained authorization by the WebSphere Application Server front-end that exposes the party's business functions as web services. Each party imported the other's X.509 certificate into their keystores, so that if a request or response is not signed with a known certificate in their keystore, the message is rejected. Once the Consuming Application is authenticated and the message's integrity is validated, the request is passed to the web services implementation. Figure 1 - B2B with business identity credential

Enterprise application integration using an individual's credential A customer had several lines of businesses that required access to legacy systems. The business requirement was to provide internal applications on disparate systems access to enterprise databases on legacy systems. A secondary goal was to position the customer to provide its external business partners access to the same legacy systems. Each user that requires access to the data has existing individual credentials -- his/her user ID and password -- within the corporate LDAP registry. A user is authenticated by the Consuming Applications and their identity is passed in the web services request using the WS-Security UsernameToken security token. The security token and the body of the SOAP message are digitally signed using X.509 certificates associated with the Consuming Application. Upon the validation of the signatures, the Consuming Application is authenticated. At the Service Provider, WebSphere Application Server authentication is set up to use the identity passed in the UsernameToken as an asserted identity that the Consuming Application has authenticated. WebSphere Application Server uses the identity in the security context for the thread of execution when processing the request. This enables WebSphere Application Server to provide fine-grain authorization of the web services resources. This solution utilizes a WebSphere Application Server WS-Security TimeStamp element that is digitally signed to protect against replay attacks.

Since this solution is expected to support a large number of Consuming Applications, minimizing the administrator's tasks for the Service Provider was a requirement. To address this need, WS-Security was set up to provide the Consuming Application's X.509 certificate as a binary security token within web services requests. The business requirement is for the solution to be secure with no dependency on the network transport. The architecture of the solution includes the ability for them to leverage both XML Digital Signature and XML Encryption to address authentication, data integrity, and data confidentiality. However, depending on the overhead of XML encryption, HTTPS can provide data confidentially. The trade-off for this choice is that the security is only provided between network nodes (typically over the Internet) and is not applicable for other network transports. Figure 2 - EAI with individual's credential

Federated identity A group of business partners had a requirement to enable their employees to access applications from their separate enterprises. Their goal was to improve their processes and to allow each partner to provide their employees with a consolidated set of services that leverage business functions of other partners. As an example, the business partners typically integrate supplier information for brokers to use during their sales cycle.

Although the business partners may have customized Web pages, the brokers must leave this integrated Web environment and "jump" to specific supplier Web pages to retrieve required information. Jumping between the Web sites of a business partner and supplier creates a number of challenges including security issues, difficulty integrating content, and confusion remembering a multitude of usernames, passwords, and Web site addresses for various providers. The primary partner who has the advantage in the relationships with its partners uses Security Assertion Markup Language (SAML) for controlling access to its web resources (HTML, Servlets, JSPs). As a result, one of their requirements is to leverage SAML assertions in controlling access to their web services. The solution for these partners included a Federated Identity model where the Consuming Application authenticates its local users and makes web services requests asserting an employee's identity. The Service Provider relies on the Consuming Application to authenticate the user as in the previous customer scenario, but in this case, each partner has a separate security domain. Thus when processing a web services request, the provider needs to map the asserted identity to credentials that are valid for its security domain. This model requires a trust relationship between any two partners. Mutual authentication, using SSL and X.509 certificates, realizes the trust. One of the primary goals of the partners was to not expose user credentials of their security domain. To achieve this goal, the partners agree on a common pseudonym mapped to each of their user identities. A person's Social Security Number is a good example of a pseudonym; however, for legal concerns it is not the best choice. WS-Security can digitally sign the SAML assertions passed as an XML-based security token in the SOAP header and to sign the body of the SOAP message. This provides the ability to authenticate a Consumer Application and to ensure message integrity. Encrypting the network connection using HTTPS resulted in message confidentially for this solution. With the user identity provided in a SAML assertion as a pseudonym, the Service Provider maps the pseudonym to a local user identity that is valid within its security domain. Since the business function contains authorization logic, the user identity is passed as a HTTP header parameter within the Service Provider's environment when invoking the web services implementations. As a result, WebSphere Application Server only provides coarse-grain authorization based on the digital signature's success.

Figure 3 - Federated identity with SAML

This solution was implemented prior to WebSphere Application Server's support of WSSecurity and uses custom WS-Security components. The solution signs the entire SOAP message and provides a security context token in the response to the Consuming Application for use on follow-up requests. The security context token optimizes performance similar to how traditional Web solutions use HTTP cookies for passing security context. WebSphere Application Server V5.02 and V 5.1 support passing XML-based token's (such as SAML). However, one must provide a custom JAAS Login Module to incorporate the user's identity from the token into WebSphere Application Server's security context in order to utilize WebSphere Application Server for authorization. Users should consider WS-Security when application-to-application security is required, and not just security over the Internet between network nodes at the enterprise boundary.

Back to top Summary Since WS-Security will have an impact on the overall response time and the number of simultaneous requests that your solution can support, it is important that your decision to

use WS-Security is justified. In many cases, HTTPS with the transport KeepAlive enabled will provide you with a significantly better-performing solution than what is possible when using XML Digital Signature and XML encryption. Yet the extent to which HTTPS provides you a better solution is really dependent on the overall processing times of your business logic executed by your web services implementations. If your services are doing simple inquiries into a well-indexed database that take less than 100 milliseconds, then you will see a big difference between the two choices. If your business logic is more complex or distributed on remote systems and the processing takes a few seconds, the choices might not result in much of a difference. You should exercise caution when comparing the impact of WS-Security and a transportdependent-based alternative such as HTTPS. The results of tests that only use web services request messages that are simple string and where the service itself does nothing more than echo the message as a response, may lead you to meaningless conclusions that solutions leveraging WS-Security will always result in significantly less performance than solutions leveraging HTTPS security mechanisms. For example, sending a realistic 4K byte request message with a moderately complex XML structure verses sending a 4K byte test message with a simple string increases the SOAP engine's processing time by 30%, thus reducing the overall differences between the two security mechanisms. When your business logic executes and has to process real business information, something other than the 25 millisecond echo, and performs real work, you are able to genuinely understand the true impact that WS-Security will have on your solution. When business requirements justify message integrity between application end points for mission-critical data, market-valued data, or for confidential data, digital signature capability provided by WS-Security is the good choice and is readily available on vendors' applications servers such as Websphere Application Server. Both XML Digital Signature and XML Encryption will have an impact on your solution. If performance is your primary concern over all other requirements, then HTTPS is your best choice. A common practice today is to use XML Digital Signatures for application authentication and data integrity and to rely on HTTPS to provide confidentiality. Whether the impact of using both XML Digital Signature and XML Encryption is trivial or significant can only be determined by enabling this capability within your application environment using real business data and business logic, and then measuring the differences.