SOA Security - Follow-up Question

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

http://oracleaccessmanagement.blogspot.com/2008/09/soa-security-adt-or-crocodile-filled.html

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.