This blog post explains the steps required to secure an OSB proxy service with an OWSM security policy that requires a SAML 1.1 Sender Vouches token and also how to configure OSB such that this proxy can readily be tested from the OSB test console using am identity defined in the Credential Store Framework.
Pre-Requisites
The following are pre-requisites for following this post:
- The OSB domain mus have been configured for OWSM and EM
- An entry in the Credential Store Framework (CSF) for the weblogic username/password
This post explains how to setup the OSB domain to meet these pre-requisites
Applying the Policy
The following procedure will apply the required oracle/wss10_saml_token_service_policy Policy to the Proxy Service. In this instance the instructions are for the OSB console but the same can be readily achieved in the OEPE IDE.
- Open the Oracle Service Bus Console in your browser (typically http://localhost:7001/sbconsole
- Navigate to the Proxy Service
- Ensure that there is a edit session created in the change center
- Click the "Polcies" tab
- Click the "From OWSM Policy Store" radio button
- Click the "Add" button, this will pop-up a "Select OWSM Policy" window.
- Select radio button next to the
oracle/wss10_saml_token_service_policypolicy in the list - Click the "Submit" button which will close the "Select OWSM Policy" pop-up window
- Click the "Update" button to save the policy change.
- Activate the edit session in the change center
Figure 1. Proxy Service Policies Tab
Figure 2. Choosing the OWSM Policy
Testing as Anonymously
Attempting to test the proxy such that it generates a SAML assertion containing the "weblogic" user as follows:
| Property | Override Value |
|---|---|
subject.precedence | true |
csf-key | weblogic |
However this results in an anonymous SAML token being created.
<soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="SAML-ItxCC78g5ngixaGfX3cJzg22" IssueInstant="2014-04-22T12:58:19Z" Issuer="www.oracle.com" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Conditions NotBefore="2014-04-22T12:58:19Z" NotOnOrAfter="2014-04-22T13:03:19Z"/>
<saml:AuthenticationStatement AuthenticationInstant="2014-04-22T12:58:19Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
<saml:Subject>
<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">owsm_anonymous_fe24daa0-bc21-4434-9d8e-148833612e92</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
</wsse:Security>
</soap:Header>
Note the use of owsm_anonymous_fe24daa0-bc21-4434-9d8e-148833612e92 as the username. This is because the subject.precedence override property on the client policy was true. The same test can be attempted again but this time with the property set to false to allow the weblogic user from CSF to be used.
| Property | Override Value |
|---|---|
subject.precedence | false |
csf-key | weblogic |
As seen in the following screenshot.
Figure 1. Testing as WebLogic user
However this results in the following error:
An error occurred during web service security outbound request processing [error-code: SecurityHeaderMarshallingError, message-id: <test-message>, proxy: <alsb-test-service>, target: OSBExamplesProject/helloworld/proxy/HelloWorldSAML, operation: SayHello]
--- Error message:
[Additional Information] If you are using SAML Client Policy and you see 'access denied' error, there could be two possible reasons:
(1) You may be trying to propagate the inbound subject on outbound, but there is no inbound subject. SAML Client policy needs a valid current user to create the appropriate SAML token. Make sure you have a valid inbound subject and the value of override 'subject.precedence' is TRUE.
(2) You may be trying to use an override to specify a static subject from CSF to generate the SAML token, but you have not granted appropriate permission to the OSB project that contains this business service. You need to add permissions to the system-jazn-data.xml in your domain through Oracle Enterprise Manager - Fusion Middleware Control. Make sure you have a valid CSF entry in override 'csf-key' and the value of override 'subject.precedence' is FALSE.
oracle.wsm.security.SecurityException: access denied (oracle.wsm.security.WSIdentityPermission resource=OSBExamplesProject assert)
at oracle.wsm.security.policy.scenario.util.PermissionUtil.checkIdentityPermission(PermissionUtil.java:83)
at oracle.wsm.security.policy.scenario.processor.WssSamlTokenProcessor.getUserNameWhenSubjectIgnoredAfterCheckingPermission(WssSamlTokenProcessor.java:535)
at oracle.wsm.security.policy.scenario.processor.WssSamlTokenProcessor.retrieveUserNameAndAttributesForSamlAssertionSubject(WssSamlTokenProcessor.java:402)
at oracle.wsm.security.policy.scenario.processor.WssSamlTokenProcessor.build(WssSamlTokenProcessor.java:231)
at oracle.wsm.security.policy.scenario.processor.WssSamlTokenProcessor.build(WssSamlTokenProcessor.java:204)
at oracle.wsm.security.policy.scenario.executor.Wss10SamlTokenScenarioExecutor.sendRequest(Wss10SamlTokenScenarioExecutor.java:127)
at oracle.wsm.security.policy.scenario.executor.SecurityScenarioExecutor.execute(SecurityScenarioExecutor.java:855)
at oracle.wsm.policyengine.impl.runtime.AssertionExecutor.execute(AssertionExecutor.java:41)
at oracle.wsm.policyengine.impl.runtime.WSPolicyRuntimeExecutor.executeSimpleAssertion(WSPolicyRuntimeExecutor.java:425)
at oracle.wsm.policyengine.impl.runtime.WSPolicyRuntimeExecutor.executeAndAssertion(WSPolicyRuntimeExecutor.java:344)
at oracle.wsm.policyengine.impl.runtime.WSPolicyRuntimeExecutor.execute(WSPolicyRuntimeExecutor.java:291)
at oracle.wsm.policyengine.impl.PolicyExecutionEngine.execute(PolicyExecutionEngine.java:102)
This error occurs because we have asked the proxy to switch the identity to the user specified in the CSF but the proxy does not have the security permission that allows it to perform this identity switch.
Enabling Identity Switching
In order to be able to use the CSF to specify the user to test as the proxy needs to be able to perform an identity switch. In order for this to occur the proxy, or more accurately the OSB project, must have permission to perform identity switching. This is accomplished by creating a system policy permission that enables identity switching through the Enterprise Manager console (it can also be scripted in WLST if required). The Oracle OSB documentation here is the starting point for the documentation around enabling identity switching.
In order to allow identity switching you must grant the OSB Project containing the OSB project the oracle.wsm.security.WSIdentityPermission permission. The following procedure will enable the permission.
- Open the Enterprise Manager console in your browser, typically http://localhost:7001/em
- Expand the "WebLogic Domain" tree node and right-click the domain name to bring up the context window
- Select "Security/System Polcies" from the context menu
- Search for all "codebase" policies
- Select the first policy and click the "Create-Like" button
- In the "Codebase" field enter:
file:${common.components.home}/modules/oracle.wsm.agent.common_11.1.1/wsm-agent-core.jar - In the Permissions list delete any existing permissions
- Add a permission by clicking on the "Add" button. Enter the following details into the "Edit Permission" overlay:
- Permission Class:
oracle.wsm.security.WSIdentityPermission - Resource Name:
resource=<OSB Project Name> - Permission Actions:
assert
- Permission Class:
- Click the "OK" button in "Create System Grant" screen to save the policy permission.
Figure 1. Opening up the System Policies
Figure 2. Searching the existing System Policies (Create Like)
Figure 3. Create System Grant Policy
Figure 4. Create new Permission
Testing as WebLogic User
Now that the OSB project has the correct permissions it should be possible to use CSF to specify the user "weblogic" and get the proxy to generate the correct SAML assertion.
| Property | Override Value |
|---|---|
subject.precedence | false |
csf-key | weblogic |
As seen in the following screenshot.
Figure 1. Testing as WebLogic user
Now when the SOAP header is observed through the test console the SAML assertion contains "weblogic" as the username:
<soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<wsse:Security soap:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<saml:Assertion MajorVersion="1" MinorVersion="1" AssertionID="SAML-BkdkFqlRMZ0TgRjyBkYMow22" IssueInstant="2014-04-23T09:56:23Z" Issuer="www.oracle.com" xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
<saml:Conditions NotBefore="2014-04-23T09:56:23Z" NotOnOrAfter="2014-04-23T10:01:23Z"/>
<saml:AuthenticationStatement AuthenticationInstant="2014-04-23T09:56:23Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password">
<saml:Subject>
<saml:NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">weblogic</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
</wsse:Security>
</soap:Header>
Success! The OSB proxy can now be tested using a user stored in CSF as the identity asserted in the SAML token.
The example in this blog post uses a policy that does not enforce message integrity or message protection and therefore whilst suitable for testing purposes should not be used for a proper implementation. It is highly recommended that once successful testing has been achieved that a policy that enforces at least message integrity is employed as otherwise the SAML token can be easily spoofed.
