Web Service Security

In general, Web service security is provided in three different ways:

• Transport-level security ” Transport-level security over HTTPs and based on SSL can be used to secure communications at the HTTP level. Transport-level security has a number of advantages; the chief one is that HTTPs is a mature, well-supported protocol. The chief disadvantage of HTTPs is that it doesn't secure the message itself; rather, it secures the connection.

• Role-based security ” Role-based security enables you to apply security at the method level based on well-defined roles. It translates to EJB-based method security. Advantages of role-based security are its tight binding to methods and roles and its support for the Run As command, which makes it possible for a method to be run in the context of a given user. The disadvantages of role-based security are similar to those of transport-level security ” mainly that the message itself isn't secure. Instead, the executing method instance is run under a specific role or user .

• Message-based security ” Message-based security supports authentication and authorization of messages based on encrypted signed XML tokens. The main advantage of message-based security is its capability to secure a message at both the request and response levels. The major disadvantage of message-based security is its immaturity, as it has yet to reach final specification status.

The remainder of this section concentrates on message-based security, as role-based and transport-level security are well known.

WebLogic Workshop Web services are secured based on an implementation of the Organization for the Advancement of Structured Information Standards (OASIS) Web Services Security Standard that was voted into committee specification status in October 2003. It supports three specific standards:

• Username profile tokens ” The username and password associated with a Web service request and used for authentication and authorization.

• X509 profile tokens ” An X509 certificate defining the security credentials of a Web service request and used for authentication and authorization.

• SOAP message security ” Enhancements to the SOAP protocol in support of message integrity and authentication that provide a method for associating security tokens with message content.

Together these standards define support for communicating, encrypting, signing, and otherwise managing credentials and transfer of credentials between Web service clients and providers wanting to engage in secure Web services.

OASIS WEB SERVICES SECURITY SPECIFICATION PAGES

You can find details of the standard at http://www.oasis- open .org by searching for Web Services Security.

WebLogic Web services are based on these standards and provide an implementation of WSSE or Web Services Security Policy files. WSSE files define security for requests and responses from an external client to a Web service and from one Web service to another.

Web services obtain their security via WSSE files. To create a WSSE file, select a folder within a project, right-click, and choose New, Other File Types, Web Services, WS-Security Policy File. Listing 9.3 shows the result of creating a new Web services policy file.

Listing 9.3. The Default WSSE File

 <?xml version="1.0" ?> <wsSecurityPolicy xsi:schemaLocation="WSSecurity-policy.xsd"     xmlns="http://www.bea.com/2003/03/wsse/config"     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> </wsSecurityPolicy> 

Web Services Security Policy incoming and outgoing information is defined via <wsSecurityIn> and <wsSecurityOut> elements, respectively. As shown in Figure 9.8, incoming requests are those serviced by the Web service, and outgoing requests are typically responses from a Web service to a request.

Figure 9.8. Workshop Web services message-based security model.

The <wsSecurityIn> Element

Username/password combinations are a common security mechanism for incoming requests and are specified with <wsSecurityIn> elements by using the following code:

 <token tokenType="username"/> 

The <token tokenType="username"> element specifies that all incoming requests have an associated username/password combination that's validated against the WebLogic Server security provider at request time.

One of the core issues with username authentication is that the username/password combination is typically passed in cleartext. Cleartext elements can be captured by using man-in-the-middle security attacks, which slip between a client and a provider of services, sniff for these combinations, and then spoof the provider with any captured usernames.

The Web Services Security specification provides for encryption of usernames via the <encryptionRequired> element. Encryption by itself is not enough, as tampering could occur in the request. Digital signatures are a mechanism that can be used with encryption to sign a request so that it's clear it has been tampered with. The <signatureKey> element can be used to require digital signatures. Listing 9.4 shows a typical <wsSecurityIn> element specifying that incoming requests use username/password combinations that must be encrypted and digitally signed.

PUBLIC KEY/PRIVATE KEY ENCRYPTION

Web services security is based on public key/private key encryption, which specifies how messages are translated between cleartext and ciphertext . A key combination is used in which the public portion is supplied to the world at large and the private key is held safe. Typically, a keystore is used to hold some number of public keys (provided in X508 certificates) and a site's private key. WebLogic Server keystores are stored in .pks files within a domain. See Chapter 14, "Securing Access in WebLogic Workshop: Working with SSL and Role-based Security," and the WebLogic Server documentation for more information on public keys/private keys and keystores.

Listing 9.4. The <wsSecurityIn> Element

 <!-- Incoming SOAP message must be accompanied by a valid username and password. --> <wsSecurityIn>     <token tokenType="username"/>     <encryptionRequired>         <decryptionKey>             <alias>client1</alias>             <password>password</password>          </decryptionKey>     </encryptionRequired>       <signatureRequired>true</signatureRequired> </wsSecurityIn> 

To fully understand Listing 9.4, you must be clear on which keys are used to perform which operations. When a request requiring encryption is made, the client must be able to encrypt the request and the Web service must be able to decrypt it. Incoming requests are encrypted by using the provider's ”that is, the recipient's ”public key; requests are then decrypted by using the <decryptionKey> element, which specifies the username and password in a keystore of the provider's private key. Requests are marked as requiring a digital signature by using the <signatureRequired> element. Digital signatures are generated based on the requester's (the client's) private key and validated by the Web service recipient using the client's public key.

Keystores are specified by using the <keyStore> element, as shown in the following code:

 <keyStore>     <keyStoreLocation>path_to_keystore</keyStoreLocation>     <keyStorePassword>myKeystorePassword</keyStorePassword> </keyStore> 

Keystores are stored in a domain along with all the other domain-specific files and have .jks extensions. Workshop's sample domain comes with a default keystore containing a number of public key/private key samples. It can be specified as shown in the following code:

 <keyStore>     <keyStoreLocation>samples_mycompany.jks</keyStoreLocation>     <keyStorePassword>password</keyStorePassword> </keyStore> 

The <wsSecurityOut> Element

The <wsSecurityOut> element is used for responses to requests or for requests to outside Web services. Username/password combinations for outgoing requests are supported by using the <userNameToken> element to tell the recipient who is making the request. The following code specifies that the user weblogic with the password weblogic should be sent along with the request:

 <userNameToken>     <userName>weblogic</userName>     <password type="TEXT">weblogic</password> </userNameToken> 

Outgoing requests are encrypted and signed. The <wsSecurityOut> element also supports encryption and digital signatures; however, the roles are reversed for keys. When a <wsSecurityOut> element is processed , it's encrypted with the recipient's public key and signed with the client's private key. Encryption and signing are specified with the <encryption> and <signatureKey> elements, as shown in Listing 9.5.

Listing 9.5. The <wsSecurityOut> Element

 <!-- Outgoing SOAP message must be accompanied by a valid username and password. --> <wsSecurityOut>     <userNameToken>        <userName>weblogic</userName>        <password type="TEXT">weblogic</password>     </userNameToken>     <encryption>         <encryptionKey>             <alias>client1</alias>         </encryptionKey>     </encryption>     <signatureKey>         <alias>mycompany</alias>             <password>password</password>     </signatureKey> </wsSecurityOut> 

Associating Security with Web Services

Until now, all you have done is define a security policy; you haven't associated it with any Web service. A WSSE policy is associated with Web services via the ws-security-service and ws-security-callback annotations, which associate the policy with methods and callbacks, respectively. Listing 9.6 shows an example of specifying a Web Service Security Policy.

Listing 9.6. Specifying a WSSE File Within a Web Service

 /**  * @jws:ws-security-service file="creditServicesSecurity.wsse"  * @jws:ws-security-callback file="creditServicesSecurity.wsse"  */ public class creditServices implements com.bea.jws.WebService 

After a policy file has been applied to a Web service, it's then used for all method calls within that service, both incoming and outgoing.

ENCRYPTING WSSE POLICY FILES

Under normal circumstances, when an application is compiled, the WSSE policy files can contain cleartext passwords in the generated compiled .class files, which can be viewed by sophisticated users with access to a deployed application. WebLogic Workshop provides the generateSecretKey and encryptWssePolicy utilities, located in the weblogic81/common/bin folder, for encrypting policy files. generateSecretKey can be used to generate a key for encrypting your policy files. The resulting encrypted policy can then be placed in the APP-INF/classes directory and used transparently . The Securing WS-Security Passwords topic of the Web service help files explains the details of encrypting and using encrypted policy files.