Why would you want to use a Web service? They are flexible and supported on a number of platforms and can be implemented by using a number of languages. This chapter from BEA WebLogic Workshop 8.1 (by Albert J. Saganich, Jr., et al., Sams, 2004, ISBN: 0-672-32622-1) covers Web services concepts, SOA, SOAP, WSDL, and security.
Working with Web Services - Web Service Security (Page 8 of 9 )
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.
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.
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.
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.
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.
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.
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:
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.
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:
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:
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:
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>
This chapter is from BEA WebLogic Workshop 8.1, by Albert J. Saganich, Jr., et al. (Sams, 2004, ISBN: 0-672-32622-1). Check it out at your favorite bookstore today.