Oracle Fusion Middleware Security: Weblogic WS-Trust Client and OWSM interoperability

First, I’d like to take the opportunity to wish you all our readers a great 2012, with plenty of health, joy, care for each other and peace! We really appreciate your interest in our posts and hope to be truly contributing to your daily work. With that said…

Did you guys know Weblogic implements a WS-Trust client? Did you also know that WS-Trust client can interoperate with web services protected by OWSM policies requiring message protection (signing and encryption) ? Those were very helpful to me in satisfying some important requirements for a customer in a recent proof of concept exercise.

This is a long post. It describes a bunch of things that are more or less available across several official books, but also adds some details that are not easily found, especially if you’re interested in troubleshooting.

The customer adopts OSTS (Oracle Secure Token Service) and wanted an alternative to OWSM (Oracle Web Services Manager) client. OSTS is part of Oracle IAM Suite 11.1.1.5, delivered as an OAM (Oracle Access Manager) add-on. For an introduction to OSTS, check this post.

OSTS leverages OWSM policies to protect its WS-Trust endpoints. OWSM 11.1.1.5 also delivers WS-Trust client policies. When your web services clients can leverage the OWSM WS-Trust client policies, great, it just works. In situations where they can’t, alternate solutions need to be thought. This particular customer had a considerable amount of clients running in Weblogic server 10.3.3, where WS-Trust support is not available in the OWSM runtime. We could have looked at web services frameworks like Apache’s AXIS2 or CXF, but Weblogic’s WS-Trust client was just there, waiting to rescue. As you can see if you follow this post, it saved us quite some coding.

I must say that the approach describe here is by no means a recommended architecture for everyone. Every customer scenario is different and should be thought in light of current and future requirements. I must also say that OWSM is the strategic direction and, as such, should always be the preferred approach.

This is basically what I’ve helped the customer to achieve:

Here are the interaction details:

1) The client makes an RST (Request Secure Token) using Weblogic’s WS-Trust client to the OSTS requesting for a SAML token to be sent to the ws provider. The client identifies itself to the OSTS with username token credentials in the WSS header, but requests a token on behalf of someone else. In this example, on behalf of the client application executing user.

2) OSTS’ OWSM agent validates the WSS part of the request. It needs to decrypt the message and validate the digital signature added by Weblogic’s WS-Trust client. This is where most of interoperability problems arise. The policy attached to OSTS endpoint is oracle/wss11_username_token_with_message_protection_service_policy

3) After doing some extra validation on the RST and the requestor credentials, the OSTS issues the SAML token (RSTR – Request Secure Token Response).

4) The client calls the ws provider passing the issued SAML token along. SAML confirmation method in this case is Sender-Vouches, which means the ws client signs the SAML token. The policy attached to ws provider is oracle/wss11_saml_token_with_message_protection_service_policy.

5) The ws provider sends the response.

Implementation Details

1) Web Service Proxy

Web service JAX-WS proxy is generated for the web service provider as usual. This is done by Weblogic’s clientgen tool via an ANT build script, as shown below:

<project name="ws-client" default="build">

 <property name="wls.hostname" value="localhost"/>

Notice that you need weblogic.jar and wseeclient.jar in the CLASSPATH to run clientgen. These files are located under $MW_HOME/wlserver_10.3/server/lib folder.

You don’t generate proxies for the OSTS endpoint. This is implicitly taken care by WLS WS-Trust client.

2) Client Code

My client is a simple servlet, that actually hides some serious heavy-lifting performed by Weblogic’s WS-Trust client. The code is commented so it explains itself. Look at how simple it is.

You get an instance of the proxy port as you would normally do and add a couple of properties to the BindingProvider object in order to make the WS-Trust client invoke OSTS (lines 35-45).

1: package trunk.interop.ws;

  

import java.io.IOException;

import java.io.PrintWriter;

import javax.servlet.*;

import javax.servlet.http.*;

import javax.xml.ws.BindingProvider;

import java.util.Map;

import weblogic.wsee.message.WlMessageContext;

import weblogic.wsee.jaxrpc.WLStub;

import weblogic.wsee.security.WSEESecurityConstants;

import javax.xml.soap.SOAPConstants;

import ws.client.Greeting;

import ws.client.GreetingService;

 

public class TrustClientServlet extends HttpServlet {

 

 private static final String CONTENT_TYPE = "text/html; charset=windows-1252";

 private static final String TRUST_VERSION = "http://docs.oasis-open.org/ws-sx/ws-trust/200512";

 private static final String STS_URL = "http://dogwood.us.oracle.com:14100/sts/wss11user";

 private static final String STS_POLICY = "StsWss11UntPolicy.xml";

 public void init(ServletConfig config) throws ServletException {

   super.init(config);

 } 

 public void doGet(HttpServletRequest request, HttpServletResponse response) 

   throws ServletException, IOException {

 

  response.setContentType(CONTENT_TYPE);

  PrintWriter out = response.getWriter();

  out.println("<html>");

  out.println("<head><title>TrustClientServlet</title></head>");

  out.println("<body>");

  GreetingService service = new GreetingService();

  Greeting port = service.getGreetingPort();

  Map<String, Object> requestContext = ((BindingProvider) port).getRequestContext();

  // Oracle STS endpoint URL

  requestContext.put(WLStub.WST_STS_ENDPOINT_ON_SAML, STS_URL);

  // WS-Policy to talk to Oracle STS

  requestContext.put(WlMessageContext.WST_BOOT_STRAP_POLICY, this.getClass().getResourceAsStream(STS_POLICY));

  // WS-Trust version

  requestContext.put(WSEESecurityConstants.TRUST_VERSION, TRUST_VERSION);

  // SOAP version

  requestContext.put(WSEESecurityConstants.TRUST_SOAP_VERSION, SOAPConstants.URI_NS_SOAP_1_2_ENVELOPE);

  // username for whom a token will be requested

  requestContext.put(WSEESecurityConstants.ON_BEHALF_OF_USER, request.getRemoteUser());

  out.println(port.sayHello(request.getRemoteUser()));

  out.println("</body></html>");

  out.close();

 }

}

3) OWSM Policy in the OSTS endpoint

Line 20 defined the OSTS endpoint. If you append ?WSDL to it and paste it in a browser URL, you can see the WS-Policy generated by the OWSM policy (wss11_username_token_with_message_protection_service_policy) that protects it. It can give you very good insights in case you run into interoperability issues.

In my experience, the interoperability problems are mostly due to mismatch between security bindings, encryption method mechanisms and encryption algorithms.

Here are some typical error messages. I now know how to make them happen anytime. :-)

a) Due to security binding mismatch:

Caused by: 
oracle.wsm.security.policy.scenario.policycompliance.PolicyComplianceException: 
WSM-00059 : Signature method algorithms are mismatched. Expected : http://www.w3.org/2000/09/xmldsig#hmac-sha1, 
Actual : http://www.w3.org/2000/09/xmldsig#rsa-sha1.

In this case, make sure both policies use the same security binding. For instance, OWSM’s wss11_username_token_with_message_protection_service_policy is Symmetric. The security binding is NOT configurable in the OWSM policy.

<sp:SymmetricBinding xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">

  <wsp:Policy>
  ...
</sp:SymmetricBinding>

b) Due to encryption reference mechanism mismatch:

[2011-09-21T16:04:27.900-07:00] [ms1] [ERROR] [WSM-00034]

[oracle.wsm.resources.security] [tid: [ACTIVE].ExecuteThread: '0' for queue: 
'weblogic.kernel.Default (self-tuning)'] [userId: <anonymous>] [ecid: 
5f5492695bd28c21:-83db949:1328e2f9215:-8000-000000000000002c,0] 
[WSM_POLICY_NAME: 
oracle/wss11_saml_token_with_message_protection_service_policy] [APP: 
InteropWebServices] Error in Encryption reference mechanism compliance : 
Expected : thumbprint , Actual : ski. Ensure that a compatible policy is 
attached at the client side.

This is configurable in the OWSM policy, by changing the orasp:enc-key-ref-mech property value.

<orasp:wss11-username-with-certificates orawsp:name="WS-Security 1.1 username

with certificates" orawsp:Silent="false" orawsp:Enforced="true" 
orawsp:category="security/authentication, security/msg-protection">
 
 <orasp:username-token orasp:password-type="plaintext" 
orasp:add-nonce="false" orasp:add-created="false"/>
  
<orasp:x509-token orasp:enc-key-ref-mech="ski"/>
  
<orasp:msg-security orasp:confirm-signature="true" 
orasp:sign-then-encrypt="true" orasp:include-timestamp="true" 
orasp:encrypt-signature="false" orasp:algorithm-suite="Basic256">

c) Due to encryption algorithms mismatch:

Caused by:

oracle.wsm.security.policy.scenario.policycompliance.PolicyComplianceException: 
WSM-00030 : The encryption method key wrap algorithms do not match : Expected 
: http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p, 
Actual : http://www.w3.org/2001/04/xmlenc#rsa-1_5.

This is also configurable in the OWSM policy. In the policy snippet above, you can play with the property value of orasp:algorithm-suite and try the Algorithm Suite values as specified in the WS-SecurityPolicy specification. Make sure it matches the one in the client-side policy.

Note: In OSTS, the OWSM policies are available at $MW_HOME/Oracle_IAM1/oam/server/policy/sts-policies.jar.

4) Client-side WS-Policy for OSTS endpoint

Weblogic web service client APIs are smart enough to infer the necessary client configuration from the advertised WS-Policy in the web service WSDL. That said, we’re NOT supposed to attach any client-side policies to talk to our web service provider endpoint. However, this does NOT apply when talking to an STS using the WS-Trust client.

Notice that my client code adds StsWss11UntPolicy.xml to the BindingProvider on line 39. The xml file actually defines the WS-Policy that interoperates with OSTS endpoint protected by OWSM (once I worked through the problems showed above). Here it is:

<?xml version="1.0"?>

<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"

     xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">

 <sp:SymmetricBinding>

 <wsp:Policy>

 <sp:ProtectionToken>

 <wsp:Policy>

 <sp:X509Token 

     sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never">

 <wsp:Policy>

 <sp:RequireKeyIdentifierReference/>

 <sp:WssX509V3Token11/>

 </wsp:Policy>

 </sp:X509Token>

 </wsp:Policy> 

 </sp:ProtectionToken>

 <sp:AlgorithmSuite>

 <wsp:Policy>

 <sp:Basic256Rsa15/>

 </wsp:Policy>

 </sp:AlgorithmSuite>

 <sp:Layout>

 <wsp:Policy>

 <sp:Lax/>

 </wsp:Policy>

 </sp:Layout>

 <sp:IncludeTimestamp/>

 <sp:OnlySignEntireHeadersAndBody/>

 </wsp:Policy>

 </sp:SymmetricBinding>

 <sp:SignedEncryptedSupportingTokens>

 <wsp:Policy>

 <sp:UsernameToken

 sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">

 <wsp:Policy>

 <sp:WssUsernameToken10/>

 </wsp:Policy>

 </sp:UsernameToken>

 </wsp:Policy>

 </sp:SignedEncryptedSupportingTokens>

 <sp:Wss11>

 <wsp:Policy>

 <sp:MustSupportRefKeyIdentifier/>

 <sp:MustSupportRefIssuerSerial/>

 <sp:MustSupportRefThumbprint/>

 <sp:MustSupportRefEncryptedKey/>

 <sp:RequireSignatureConfirmation/>

 </wsp:Policy>

 </sp:Wss11>

 <sp:SignedParts>

 <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"/>

 <sp:Header Namespace="http://www.w3.org/2005/08/addressing"/>

 <sp:Body/>

 </sp:SignedParts>

 <sp:EncryptedParts>

 <sp:Body/>

 </sp:EncryptedParts>

</wsp:Policy>

5) Required Configuration in Weblogic server

I’ve been always curious on how to define credential mappings in Weblogic to be used in the context of web services. Time has come. It turns out the system properties in the Troubleshooting section (next) came up very handy to let me know the mappings to be defined.

A credential mapping essentially maps a principal to a credential to be used when talking to external systems. This is very prevalent when the external systems are based on a JCA adapter. But it applies to web services as well. For example, given authenticated user “andre” (known as the initiator) wants to call web service http://server:7003/webservices/GreetingPort from within a web service client running in Weblogic server, a credential mapping would tell which credentials the user would have to communicate with the web service.

A web service client running in Weblogic is “aware” of the security services provided by the server. In this case, given the WSS requirements stated by our 2 web services (OSTS and ws provider), two types of credential mappings are required in Weblogic:

A) 1 Default Credential Mapping:

Maps an initiator to a username/password pair. Required to add a username token to the outgoing SOAP request when calling the OSTS endpoint. A Default Credential Mapper is OOTB available in Weblogic. We DON’T need a mapping to talk to web service provider endpoint because that one requires a SAML token, which is going to be retrieved from OSTS.

Here’s the credential mapping (Security Realms –> myrealm –> Credential Mappings –> Default > New):

Protocol + Remote Host + Remote Port + Path makes up the web service URL being called. You don’t need to specify any value for Method. Notice that Path value must start with a /.

Local User is the initiator, on whose behalf the username under Remote User field is going to be retrieved. Obviously, the Remote User needs to be properly authorized in the remote system (OSTS).

B) 4 PKI Credential Mappings:

A PKI Credential Mapping maps an initiator to either a private key or a certificate. Required to perform digital signature and message encryption when calling the OSTS endpoint and web service provider endpoint. Remember, both endpoints require message protection. A PKI Credential Mapper is NOT OOTB available in Weblogic. To add one, got to Security Realms –> myrealm –> Providers –> Credential Mapping –> New (pick PKICredentialMapper). Make sure to fill in the form in the Provider Specific tab.

The keystore file Name is relative to the location where you start the Admin server. In my case, I’ve simply put clientkeystore.jks in $MW_HOME/user_projects/domains/<my-domain-name> folder.

Once you add it, restart the Admin Server so you can add the mappings (Security Realm –> myrealm –> Credential Mappings –> PKI –> New). Here are my 4 mappings:

Notice there are 2 mappings for each endpoint. One to retrieve the private key used for signing and one to retrieve the certificate used for encryption. When defining these mappings, you have the opportunity to inform the alias names in the keystore (clientkeystore.jks) holding the private key and the certificate.

6) Troubleshooting

When running into trouble, these 4 system properties will come to your rescue in the client side. Add them to EXTRA_JAVA_PROPERTIES in setDomainEnv.sh:

weblogic.xml.crypto.dsig.verbose=true
weblogic.xml.crypto.encrypt.verbose=true
weblogic.xml.crypto.keyinfo.verbose=true
weblogic.xml.crypto.wss.verbose=true

You should be able to detect, for example, why you’re not able to get a X509 token.

####<Oct 10, 2011 2:55:58 PM PDT> <Debug> <SecurityCredMap> 
<dogwood.us.oracle.com> <ms1> <[ACTIVE] ExecuteThread: '3' for 
queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> 
<> <aaa1e3e54fdb4a71:63733030:132ef6e25bc:-8000-000000000000008f> 
<1318283758414> <BEA-000000> <getCredentials: requestor=Subject: 
1
 Principal = 
weblogic.security.principal.WLSKernelIdentity("<WLS Kernel>")
, 
resource=type=<remote>, protocol=http, remoteHost=localhost, 
remotePort=9003, path=/webservices/GreetingPort, initiator=Subject: 
1
 Principal = 
weblogic.security.principal.WLSUserImpl("andre")
, 
credType=weblogic.pki.TrustedCertificate>
####<Oct 10, 2011 2:55:58 PM PDT> <Info> <> 
<dogwood.us.oracle.com> <ms1> <[ACTIVE] ExecuteThread: '3' for 
queue: 'weblogic.kernel.Default (self-tuning)'> 
<andre> <> 
<aaa1e3e54fdb4a71:63733030:132ef6e25bc:-8000-000000000000008f> 
<1318283758417> <BEA-000000> <Did not get token for token type http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 
and purpose encrypt from token 
handlerweblogic.xml.crypto.wss11.internal.bst.BSTHandler@9527ee>

Thanks to those properties, the log message above tells it was not possible to get a X509 token for user andre to encrypt the message. Then adding a PKI Credential Mapping with the server certificate solves the problem.

And to troubleshoot OWSM, configure TRACE:32 logging level for oracle.wsm in $MW_HOME/user_projects/domains/<domain-name>/config/fmwconfig/servers/<server-name>/logging.xml:

<logger name='oracle.wsm' level='TRACE:32' useParentHandlers='false'>

 <handler name='owsm-message-handler'/>

</logger>

Log messages are sent, by default, to $MW_HOME/user_projects/domains/<domain-name>/servers/<server-name>/logs/owsm/msglogging/diagnostic.log.

Happy 2012!!

Oracle Fusion Middleware Security

Monday, January 9, 2012

Weblogic WS-Trust Client and OWSM interoperability

Implementation Details

1) Web Service Proxy

3) OWSM Policy in the OSTS endpoint

No comments:

Post a Comment

Follow Us on Twitter

Search Fusion Security

Labels

Blog Archive

Contributors

Visitor Map

Followers

Disclaimer

Oracle Fusion Middleware Security

Monday, January 9, 2012

Weblogic WS-Trust Client and OWSM interoperability

Implementation Details

1) Web Service Proxy

3) OWSM Policy in the OSTS endpoint

No comments:

Post a Comment

Subscribe To

Follow Us on Twitter

Search Fusion Security

Labels

Blog Archive

Contributors

Visitor Map

Followers

Disclaimer