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.