Tuesday, June 2, 2009

SAML and OSB 10gR3 - Federated Authorization

I recently spent a lot of time with a customer on this use case, and it also appeared on the Oracle Forums, so I thought it would be worth posting some of the details.

The use case is basically processing a SAML assertion in Oracle Service Bus for the purpose of not only authentication, but authorization as well.

In most of these cases, the client first makes a call to an STS (Secure Token Service) and gets a SAML assertion that contains some claims. These claims could be SAML Authorization statements or attributes of the user's profile or actions that the user can perform on the service. Regardless, they show up at the OSB as Attribute Statements in the SAML Assertion.

The question for OSB, is how to process this information and use it for authorization?

In this post, I'll describe what can be done simply using OOTB capabilities. The SAML Identity Asserter is the component inside of OSB that processes the SAML Assertion. You can configure the SAML Identity Asserter to process the group attributes. What are the group attributes? WLS and therefore OSB has the ability to get groups for the user from a SAML Assertion.

So, a SAML Assertion like this:

<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" AssertionID="de7790da1578ae713b9fbe9399a87e3d" IssueInstant="2009-05-27T23:54:44.219Z" Issuer="http://fedtest" MajorVersion="1" MinorVersion="1"><Conditions NotBefore="2009-05-27T23:54:44.219Z" NotOnOrAfter="2009-05-27T23:56:44.219Z"></Conditions><AuthenticationStatement AuthenticationInstant="2009-05-27T23:54:44.219Z" AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:unspecified"><Subject>
<NameIdentifier Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">josh</NameIdentifier>
<SubjectConfirmation><ConfirmationMethod>urn:oasis:names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod></SubjectConfirmation></Subject>
<Attribute AttributeName="Groups"AttributeNamespace="urn:bea:security:saml:groups">
<AttributeValue>group1</AttributeValue><AttributeValue>group2</AttributeValue>
</Attribute></AttributeStatement></Assertion>


Then you'll wind-up with a Subject named josh who has two WLSGroup principals group1 and group2.

At this point, you just need to figure out how to use these groups in authorization. You could use the role mapper to map the groups to roles, and then assign those roles policies granting them access to OSB Proxy services. As an alternative, you could just skip roles, and grant access to the web-services to those groups directly.

The groups themselves don't have to exist in any directory. The values above of group1 and group2 could easily replaced with priv#trade or role#foo.
In fact the user doesn't have to exist either - its a virtual user. Since the SAML Assertion is valid, OSB will just trust what is in the assertion.

This is not the only federated authorization model that you can use with OSB, but hopefully this post shows what is simply there OOTB with OSB. There are obviously more elaborate scenarios like one-time-identifiers or more elaborate claims that would require some custom work. One of the strong points of OSB is that its built on top of WLS Security, and I've used that framework to solve a ton of use-cases. I'm sure there is a way through configuration and/or custom providers that these use cases could be met. If there's interest, I'd be happy to explore the specifics here.

3 comments:

  1. Thank you for the article. I am using SAML to authorize on groups and "virtual" users.

    Do you know if there is any caching of Subject and roles in the WL server? Assume I have just sent one request, userid=x and group1 in the SAML assertion. Then I send userid=x and group2 after a minute or two. I see from WL log that it receives the group2, but the Subject is not getting a WLGroupImpl for the group2 in the Subject. If I wait 5 to ten minutes before I send a new request, the Subject will be as expected. If I changes the userid, any new group will be handled as they should. It seems that WL caches the Subject (key seems to be the WLUserPrincipalImpl), and marks it with a timeout. This may be a problem, and I cannot find any documentation about it.

    ReplyDelete
  2. There is caching of Subjects. Default is 300 seconds, which means that changes in roles/groups for a given user will not be seen in succeding messages. Value is specified using -Dweblogic.security.identityAssertionTTL="seconds"

    ReplyDelete
  3. The full details of the flag can be found here. When developing, not having this set to -1 can cause some "odd" behavior. I start with this set to -1, and then change it to somethiing more reasonable. Most applications don't require a fresh calculation of the groups on every request. If you want more dynamic behavior, use roles.

    ReplyDelete

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