In this task you will use Web Service Security, sometimes referred to with
the acronyms "WS-Security" or simply "WSSE", to secure
the communications between the Investigate Web Service and a client web
service TestClient.jws. (TestClient.jws is located in the folder WebServiceTutorialWeb/WSSETestClient/.)
The two web services communicate through SOAP messages, as shown in the
following diagram.
The communication will be secured by enhancing the SOAP messages with username/password
tokens and encryption, as shown in the following diagram. TestClient's requests
for a credit report will include a username and password, allowing the Investigate
web service can authenticate TestClient. The credit report returned by Investigate
will be encrypted before it is sent out over the wire, ensuring that the
credit report is confidential.
These security enhancements are specified in a web service security policy file, or "WSSE file". WSSE files are XML files that specify the security behavior of your web service or web service control.
Note: that WSSE security is not the only option for securing a web service. SSL and Basic Authentication are other important options; for an example, see Java Control Tutorial Step 7: Transport Security.
The tasks in this step are:
To Associate a WSSE Policy with the Investigate Web Service
In this task you will apply a web service security policy file (WSSE file) to the Investigate web service. This policy file specifies how incoming and outgoing SOAP message should be treated.
Before you begin this task, on the Application tab, double-click
the file WebServiceTutorialWeb/investigateJWS/Investigate.wsse
to view the file.
WSSE files contain two main elements. (1) The <wsSecurityIn> element specifies the kinds of security requirements that must be met by incoming SOAP messages. (2) The <wsSecurityOut> element specifies the sorts of security enhancements that should be added to outgoing SOAP messages.
The <wsSecurityIn> specifies that incoming SOAP messages must be accompanied by a valid username and password pair. If a SOAP message is sent to Investigate.jws without a valid username/password pair, then the SOAP message will be rejected by the web service and go unprocessed. The reason for setting up this security requirement is that it is important to know who is asking for credit reports: the Investigate web service doesn't want to be sending out credit reports to anonymous users. Note that this security strategy requires a registration mechanism to be fully implemented. This registration mechanism is outside the scope of this tutorial. But it would go something like this: candidate users would be required to provide some information about themselves: an email, a phonenumber, etc., and, upon verification of this information, the user would be given a username/password with which to login to the Investigate web service. For testing purposes we will use a test user already known to the WebLogic Security framework.
The <wsSecurityOut> element specifies that outgoing SOAP messages are to be encrypted before they are sent out over the wire. This will ensure that the credit report will remain confidential and can only be read by the intended recipient.
The <keyStore> element points to a Java KeyStore file (JKS file). This file contains the message recipient's public key with which the SOAP messages are encrypted. When data is encrypted in this way, only the matching private key, known only to the message recipient, can successfully decrypt the message, ensuring confidentiality of communication.
The follow diagram shows how Investigate.wsse controls the SOAP traffic
coming into and out of Investigate.jws.
To Associate a WSSE Policy with the Investigate Web Service Control
In this task you will place a security policy on InvestigateControl.jcx,
not on TestClient.jws. The reason you place a policy on the control file is
because you are primarily interested in changing the way that TestClient.jws
communicates with the particular web service Investigate.jws, but you are not
interested in changing the way TestClient.jws communicates with any and all
web services. This is a typical pattern in WSSE: to secure the communication
between a client web service and its target web service, you place security
policies on the target web service and on the target web service control
file used by the client web service, but you leave the client web service
without a policy of its own.
Before you complete this task double-click the file WebServiceTutorialWeb/WSSETestClient/InvestigateControl.wsse
to view the file.
Notice that InvesigateControl.wsse has a security policy to complement Investigate.wsse.
Incoming SOAP messages must be encrypted; and outgoing SOAP messages are enhanced
with a username and password before they are send out over the wire. The following
diagram shows how InvestigateControl.wsse controls the SOAP traffic coming into
and out of the control file InvestigateControl.jcx.
Note: Use one of the following (9 digit) taxID's to test your web service throughout the tutorial:
Testing for Failed Communication
<wsSecurityOut> <userNameToken> <userName>weblogic</userName> <password type="TEXT">wrong_password</password> </userNameToken> </wsSecurityOut>
Related Topics