Friday, October 7, 2011

Virtual Users in OIF, Weblogic and OWSM

One of the main strengths of SAML is the ability to communicate identity information across security domains that do not necessarily share the same user base. In other words, the authenticated user in one security domain does not necessarily exist in the target security domain providing the service.

Such concept is supported in all major Oracle products that consume SAML tokens: OIF, Weblogic Server and OWSM. The sole purpose of this post is to show how to configure it in these products. Setting up SAML services as a whole involves more than what’s showed here and I recommend the official product documentation for detailed steps.

I hope this can be helpful to someone out there.

OIF (Oracle Identity Federation)


OIF enables federated single sign on for users behind a web browser.

It calls the aforementioned concept “Transient Federation” and enables it via a checkbox (that should be unchecked) in Enterprise Manager OIF’s Console. Notice it also supports the concept of a "Mapped Federation", where the incoming identity is mapped to some generic user in the local identity store. But here I am talking about the case where there's no mapping. The user in the SAML assertion is simply trusted.

In order to enable a Transient Federation in OIF, simply make sure “Map Assertion to User Account” checkbox is unchecked in the Service Provider Common tab.

oif

Weblogic Server


Weblogic server provides SAML services that can be leveraged by Web SSO as well web services.
Weblogic calls the concept Virtual Users and implements it in its SAML2IdentityAsserter along with the SAMLAuthenticator.

First, you need to enable your server as a SAML Service Provider. Notice this is done at the server level. Go to Environment –> servers –> <Pick server from list> to get into the screen below:

SAMLServiceProvider

Then add a SAML2IdentityAsserter to the authentication providers list and add an Identity Provider (who does not need to be another Weblogic server) Partner to SAML2IdentityAsserter. Notice that you can add either a Web SSO partner provider or a Web service partner provider. In the case of Web SSO, Weblogic Console will ask you for the partner metadata file.

wls_IdpPartner



In SAML2IdentityAsserter’s Management tab, click the Identity Provider partner link just created and check the “Virtual User” check box:

wls

You also need to add a SAMLAuthenticator provider after the SAML2IdentityAsserter and set its control flag to SUFFICIENT. Also make sure to set the control flag of subsequent authentication providers to SUFFICIENT.

wls_providers

End result is that the SAMLAuthenticator will instantiate a Java Subject populated with a user principal (weblogic.security.principal.WLSUserImpl) from the SAML Subject asserted by SAML2IdentityProvider.

OWSM (Oracle Web Services Manager)


OWSM protects SOAP web services via agents connected to web services providers as well as web services clients. The agent behavior is determined by the policies that get attached to the provider and the client. A client policy typically adds a token to the outgoing SOAP message while the server policy processes it, usually by authenticating and/or authorizing the user (in the case of a security policy).

First of all, a SAML-based security policy needs to be attached to the web service provider. The policy will at some point try to authenticate the subject in the incoming SAML assertion.

OWSM delegates authentication to OPSS (Oracle Platform Security Services). When asserting the SAML Subject to the container, OWSM leverages the SAML Login Module, defined in jps-config.xml and configured via EM (Enterprise Manager).

In other to enable virtual users in this scenario, set the property oracle.security.jps.assert.saml.identity to true for the SAML (or SAML2) Login Module. In EM, click the Weblogic Domain drop-down menu, pick Security –> Security Provider Configuration, click the login module row and then the Edit button. Scroll down to the bottom of the page and the add the property mentioned above to the list of Custom Properties.

opss_samlloginmodule

In order to propagate the change, restart the Admin server as well as the managed server running the web service.

Once this is done, whether or nor the SAML Subject exists in the identity store used by OPSS is irrelevant. It is going to be asserted and a Java Subject containing a user principal is going to be instantiated in the container.

8 comments:

  1. Hi Andre,

    Looking for "virtual users" in Weblogic I found this old post of your blog: http://fusionsecurity.blogspot.com/2009/06/saml-and-osb-10gr3-federated.html

    I have posted a comment on this but as it is a little bit "old stuff", I am going to reformulate my question on this other.

    I have a WLS instance running as a Service Provider. Everything works ok, but I would like to get the SAML2 attributes from the assertion as private credentials of the Subject. I am able to get this values as a set of principals, see http://biemond.blogspot.com/2011/09/virtual-users-with-saml-in-weblogic.html

    Have you faced a similar issue?

    Thanks in advance,

    Luis

    ReplyDelete
  2. Hey Luis,

    I guess Edwin Biemond in the aforementioned post shows how you can get the AttributeStatements from the SAML token. In your mapper, you would encapsulate what you get in a Collection object. Your application would then need to know who the encapsulated Object is. Method mapAttributeInfo0 in http://download.oracle.com/docs/cd/E17904_01/web.1111/e13711/saml.htm#CHDFHBHA shows how to do it.

    Andre.

    ReplyDelete
  3. The encapsulated object should NOT be a Principal, in which case they would be available to your app as principals.

    ReplyDelete
  4. Hi Andre,

    Thank you very much for your answer!

    At the moment I have successfully implemented the "returning a collection of principals" approach: implementing the CustomSAML2IdentityAsserterAttributeMapperImpl, adding it to the WEBLOGIC CLASSPATH, and setting the "Name Mapper Class Name:" value in my SAML 2.0 Identity Assertion provider.

    Now I am trying the second one,"returning a collection of objects". For this I have implemented my "CustomPrincipal": http://download.oracle.com/docs/cd/E12839_01/web.1111/e13718/pv.htm#insertedID3

    It seems that it works, but the problem comes when I try to get this principals in my application:

    Subject subject = Security.getCurrentSubject();
    Set customPrincipals = subject1.getPrincipals(CustomPrincipal.class);

    When I iterate this collection I only get WLSUserImpl instances.

    Maybe I am missing something?

    Thanks in advance,

    Luis

    ReplyDelete
  5. Hi Andre,

    Thank you very much for your answer!

    At the moment I have successfully implemented the "returning a collection of principals" approach: implementing the CustomSAML2IdentityAsserterAttributeMapperImpl, adding it to the WEBLOGIC CLASSPATH, and setting the "Name Mapper Class Name:" value in my SAML 2.0 Identity Assertion provider.

    Now I am trying the second one,"returning a collection of objects". For this I have implemented my "CustomPrincipal": http://download.oracle.com/docs/cd/E12839_01/web.1111/e13718/pv.htm#insertedID3

    It seems that it works, but the problem comes when I try to get this principals in my application:

    Subject subject = Security.getCurrentSubject();
    Set customPrincipals = subject1.getPrincipals(CustomPrincipal.class);

    When I iterate this collection I only get WLSUserImpl instances.

    Maybe I am missing something?

    Thanks in advance,

    Luis

    ReplyDelete
  6. Very interesting.
    For me especially the case of OWSM. I was wandering if in addition to having virtual Subject set can we get some attributes from SAML assertion and use them as virtual Roles and them do authorization based on them to a web service?

    Regards
    Aleksander Jachowicz

    ReplyDelete
  7. Hello Aleksander,

    unfortunately that's not supported today in OWSM.

    But you can use OWSM to authorize web services based on application roles or enterprise groups that are retrieve from the local identity store based on propagated subject id. In this case, the user must exist in the local identity store.

    Thanks,

    Andre.

    ReplyDelete
  8. Luis,
    let me know if you were able to make progress.
    I will get back to you once time permits.
    Andre.

    ReplyDelete

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