Thanks to everyone who attended our session yesterday. I'll be posting a recording of the demo shortly, but wanted to share a few questions from the audince.
"Can you apply OWSM policies at the operation level or only at the endpoint level?"
So, in contract to the existing WLS @annotation model, you can only apply policy at the endpoint level. Authorization can be done from within that policy based on the authorization, as we showed with the OES-OWSM custom assertion
"How is the SAML Assertion generated and consumed?"
The SAML is generated from within the OOTB OWSM SAML Assertion (policy assertion). It uses configuration information defined in the jps-config.xml - like the name of the issuer. The SAML is validated by the login module - but this is a different login module then the SAMLAuthenticator or SAML capabilities of native WLS.
These are not meant as dings against OWSM. As a long time WLS Security guy, I've become very pleased with the simplicity and ease of configuration that is provided by OWSM. I also really like the extensibility of the custom assertions - allows you to plug in deep inside of the web-services stack, and that is going to be handy at a TON of customers.
"What is the difference in positioning between OWSM and OSB?"
I think that the decision of when to use OWSM and when to use OSB goes well beyond the security capabilities. I think that there are some use cases around where using the SAML (partner management) capabilities of the WLS stack that is available with OSB would make sense, but this has to be weighed against the fact that OSB uses the WLS 9.2 Web Services stack.
I think that OWSM should not be confused with a full service bus. OWSM is a policy management layer for Web Services....OSB is way more than that.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.