Tuesday, May 19, 2009

SOA Security - Follow-up Question

I got an email from a response to a post that I did after last year's OOW.


The question is basically - "How do I propagate the identity from inside an EJB to a Web Service using SAML, specifically how do I get the JAX-WS client to 'know' how to activate the identity propagation?"

I thought this would be a good opportunity to "kick-off" this Oracle Fusion Middleware Security blog. Just over the last year, I've happened to be working on projects that go beyond the Oracle Access Management space, so I thought I'd spin this up for some thoughts on a broader set of topics. I've been working on projects with OSB, ADF Security, WCF integration using SAML and even plain old WLS Security. I hope to post some of those "nuggets" here.

As for the answer to the question:

You can really use either a client side policy or just have the policy attached to the endpoint, and have the stub retrieve it at runtime. In theory, just having the server side policy is better because it can change without making any changes on the client. This all depends on the definition on "any". The code won't have to change, but the configuration of the WLS Security Providers may.

Once the JAAS Subejct is established via authentication/authorization to the EJB container, the services of the WLS Security Framework, including Credential Mapping, have access to it. Which credentials are generated are based on the WS-Policy of the target service.

So, assuming that the end-point is configured to use SAML (pick one of the policies from the list of supported SAML policies), the client will use the SAML Credential Mapper to generate the SAML assertion for the subject. Also, in most cases, you'll also need to set up a PKI Credential Mapper to pick the certificate used to bind the SAML Assertion into the SOAP Message by signing the request. If you're using the Holder of Key subject confirmation method, then you'll need to also use a PKI cred mapper to retrieve the end-user's certificate to be included in the SAML Assertion itself. The signing of the assertion itself is handled from the management inside of provider - this is additional protection, and not required in many intranet scenarios.

In the spirit of full disclosure, I did use a client side policy for the OOW demo, but subsequently have implemented SAML without with only server side policy. The trick there is no pass the WSDL to the proxy so that it explicitly calls the service to get the policy.


  1. Hi, I am working on a similar problem, unfortunately I didn't found any detailed step-by-step documentation from Oracle.

    I have configured already the client side (JAX-WS client from EJB), but I have some problem on the server side (WS implemented by Stateless EJB annotated with SAML 2 holder-of-key policy.)

    On the client site I have two Credential Mapping Provider (SAML and PKI) and two Credential Mapping (Key Pair and certificate) configured and the request produced well (I monitor it with wireshark). But the server side returns with error (Caused by: javax.xml.rpc.JAXRPCException: weblogic.xml.crypto.wss.WSSecurityException: Could not validate encryption against any of the supported token types).

    What should I configure on the server side? Is a single SAML 2.0 Identity Assertion Provider is enough? Should I configure an additional PKI mapping or anything else? Do you know some more detailed documentation about a similar Use Case?


  2. This is most likely an issue with the SAML CredMapper configuration...on the sender's side.

  3. This comment has been removed by a blog administrator.


Note: Only a member of this blog may post a comment.