With the use of Oracle Web Service Manager (OWSM) we can easily configure Oracle Service Bus (OSB) services with different message security polices. This configuration can be done from Eclipse (OEPE), OSB SBConsole or the Enterprise Manager. One of the most common WS-Security mechanismes and therefor also OWSM policies is the UsernameToken where a username and password are send along with the message.
In this blog we will:
- part I: how to enable authentication of users against the list of all known users
- part II: how to enable authorisation of only a specific subset of users to access a service
First we configure a proxy service in OEPE with the OWSM UsernameToken policy oracle/wss_username_token_service_policy:
And make sure we process the WS-Security header:
After deployment we call the service with a request that is missing the WS-Security to test the result.
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<GreetingRequestMessage>
<in>I say hello ...</in>
<GreetingRequestMessage>
</soapenv:Body>
</soapenv:Envelope>
As expected the result is an error because the OWSM policy requires a WS-Security segment in the SOAP-header which contains a username and password:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server</faultcode>
<faultstring>BEA-386200: General web service security error</faultstring>
<detail>
<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-386200</con:errorCode>
<con:reason>General web service security error</con:reason>
<con:location>
<con:path>request-pipeline</con:path>
</con:location>
</con:fault>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
So to make sure we can send a UsernameToken we add 2 users to the Weblogic security realm called userA and userB.
The request to the proxy service containing the WS-Security UsernameToken for userA
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken wsu:Id="UsernameToken-4" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:Username>userA</wsse:Username>
<wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">welcomeA1</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soapenv:Header>
<soapenv:Body>
<GreetingRequestMessage>
<in>I say hello ...</in>
</GreetingRequestMessage>
</soapenv:Body>
</soapenv:Envelope>
This results in a successfull response from the proxy service:
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<GreetingResponseMessage>
<out>HelloWorld</out>
</GreetingResponseMessage>
</soapenv:Body>
</soapenv:Envelope>
So part 1 is complete, we succesfully implemented a proxy service that requires a WS-Security UsernameToken and authenticates these users against the Weblogic security realm. But in our case we have a tight security requirement and need to make sure the user is not only authenticated, but also authorized to access this specific service.
The result from part 1 means this is not the case, both userA and userB would be able to access this service. So let’s start part 2 where we will limit the access to the proxy service to only userB. For this we have to login to the sbconsole, since the OEPE does not allow you to make Message (or Transport) Access Control settings.
- Login the sbconsole
- Select Project Explorer
- Select the the proxy service
- Go to the Security Tab
- Click on Message Access Control option (either for the whole service or just a single operation).
- Click on Add Condition
- Select User from predicate list
- Type userB at the User Argument Name
- Click on Add and Finish
- Click on Save and Activate to finish the OSB session
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server</faultcode>
<faultstring>BEA-386102: Message-level authorization denied</faultstring>
<detail>
<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-386102</con:errorCode>
<con:reason>Message-level authorization denied</con:reason>
<con:location>
<con:path>request-pipeline</con:path>
</con:location>
</con:fault>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
Part 2 is completed and we finished with a proxy service that has both Authentication and Authorization enabled.
Remarks:
- You can also use groups and roles (rather than users) to authorize access to services.
- If you implement and configure an external LDAP (like Oracle Internet Directory) in Weblogic you can control ACL with groups central in your company LDAP instead of in each Weblogic security realm.
- The SOAP fault for Message Level Authorization denied (BEA-386102) contains a faultcode value of ”Server” which is not correct if you look at the w3c definition. This should be the value ”Client” because: “….. the message could lack the proper authentication or payment information. It is generally an indication that the message should not be resent without change”
Update 2011-08-10:
Added 3rd remark regarding the SOAP Fault code
Update 2012-01-13:
Using the OWSM username token policies you get some additional information on runtime in you $inbound variable. See this blogpost for more details.
References:
- OASIS: Web Service Security UsernameToken Profile 1.0
- ORACLE: Message-Level Access Control Policies for Proxy Services
- ORACLE: Securing Oracle Service Bus with Oracle Web Services Manager
- W3C: SOAP Fault Codes
