This recipe will show how to restrict access to a service, to clients that are able to authenticate themselves as a valid user in the WebLogic domain.
- Open the Configure SOA WS Policies dialog.
In the composite, right-click on the service you wish to protect and choose the Configure WS Policies... option.
This will bring up the Configure WS Policies dialog:
- Add an HTTP authentication policy.
Click on the plus (
) icon next to Security to bring up the Select Server Security Policies dialog. Choose oracle/wss_http_token_service_policy and click on OK.
- Confirm that the policy is attached.
Verify that the selected policy appears in the Security section of the dialog box and select OK.
- Deploy and test the composite.
The composite can now be deployed and the test screen can be used to verify that the service cannot be called without providing a valid username and password recognized by the WebLogic domain. Go to the Test Web Service screen and test the service endpoint without providing the credentials. You should get a Webservice invocation failed dialog box. Expand the Show Additional Trace Information link to see the full error. Note that there is a Bad response: 403 Forbidden message indicating that access to the page has been denied:
Close the dialog and expand the Security section of the Test Web Service page. Select the HTTP basic Auth radio button and provide the Username and Password of the user in the WebLogic domain. Then submit the request.
We began by attaching a policy to a service in a composite. This tells the WSM agent that it must apply a particular policy to this endpoint. All requests to this endpoint will be validated against this policy.
In this case, our policy is to perform HTTP Basic authentication. This policy does two things:
- It authenticates the incoming request
- It denies access to the service unless the request can be authenticated
We can think of the policies as acting as filters. In this case, the policy filters out all the requests to the service that are not authenticated via HTTP Basic authentication.
Note, that the policy oracle/wss_http_token_service_policy that we used has a particular name structure:
- oracle/ identifies it as a built-in, Oracle-provided, policy.
- wss identifies it as associated with web service security.
- http tells us that the policy is based on HTTP transport properties.
- token means that there is some kind of credential being passed.
- service tells us that the policy is restricted to service endpoints and cannot be used with references. There are usually corresponding client policies that request WSM to inject credentials into a request made through a reference.
Note, that this naming convention is exactly that, a convention, and we could create our own policy called antonys_special that does exactly the same thing. Following the convention is a good idea as it makes it easier to identify the policies that are appropriate for our particular requirements.
All restrictions of access have some form of authentication policy. There are more ways of authenticating than just HTTP Basic authentication for example, but they all have the same filtering effect.
This table outlines some other out of the box authentication policies that are available in SOA Suite. I have omitted the oracle/ prefix and _policy suffix for the policy names in the interest of brevity. The Service Policy Name column is used to identify the policy that protects the resources in SOA Suite. The Client Policy Name column is used to identify the corresponding policy that injects credentials into requests to references:
|
Service Policy Name |
Client Policy Name |
Notes |
|---|---|---|
|
|
HTTP Basic authentication | |
|
|
Username/password in WS-Security headers | |
|
|
SAML tokens are passed in the SOAP message | |
|
|
SAML 2.0 tokens are passed in the SOAP message | |
|
|
Kerberos authentication using Service Principal Names (SPN) |
Note
The SAML authentication policies mentioned previously are only secure if used across an SSL connection. To enforce the delivery of a message across an SSL connection, WSM provides a number of *_over_ssl_* policies such as oracle/wss_http_token_over_ssl_service_policy. These policies only allow messages through if they have used, or will use, the SSL protocol. If a message is received from a non-SSL connection, then it will be rejected without even an attempt at authentication.
Other policies have a *_with_message_protection_* description that uses WS-Security to encrypt parts of the message, providing a mechanism for secure passage of messages through untrusted intermediaries.