In the previous recipe, we allowed any authenticated user in the WebLogic domain access to our service. In this recipe, we will further restrict access to only those users that have a particular role.
Ensure that a suitable policy has been created for the role that we want to use to restrict access to a service.
- Add an authentication policy.
Follow the steps given in the Restricting a composite to authenticated users with HTTP Basic Security recipe in this chapter to add an authentication policy to the service you want to protect.
- Add an authorization policy.
Repeat the previous step, except this time choose the policy that you created to grant access to a particular group.
You should now have an authentication and authorization policy applied to the service.
- Confirm that both the policies are attached.
Verify that the two selected policies appear 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 used, to verify that the service cannot be called without providing a valid username and password recognized by the WebLogic domain and the user belonging to the specified group:
i. Go to the Test Web Service screen and test the service endpoint without providing the credentials for it.
ii. You should get a Webservice invocation failed dialog box.
iii. Expand the Show Additional Trace Information link to see the full error.
iv. Note, that there is a Bad response: 403 Forbidden message indicating that access to the page has been denied.
Now, provide a valid username and credentials for a user that is not a member of the allowed group:
i. You should get a Webservice invocation failed dialog box.
ii. Expand the Show Additional Trace Information link to see the full error.
iii. Note, that there is a Failed Authorization message indicating that access to the page has been denied.
Close the dialog and provide the username and password of the user in the WebLogic domain that is a member of the requisite group. Then submit the request. This process should now succeed.
An authorization policy is an additional filter on requests. Not only must a client be a recognized user, as determined by the authentication policy, the principal must also belong to a particular group.
Authorization policies should always be applied along with an authentication policy. The authentication policy is required to construct the principal that will be used in the authorization policy.
In addition to the basic, role-based authorization, there is an authorization policy called oracle/whitelist_authorization_policy that also allows requests from the local network to be automatically approved, or to automatically approve requests that have a valid SAML Sender Vouches token.
Policies may also be changed at runtime using the Fusion Middleware Control console.