Part 2: Kerberos Authentication, RBAC and SAML identity propagation in OAG

This post is the second one of a series by Andre Correa and Paulo Pereira on OAG (Oracle API Gateway).

The first post is found at http://fusionsecurity.blogspot.com.br/2013/03/part1-kerberos-authentication-rbac-and.html. Check it out for use case background and the Kerberos authentication part.

As mentioned, one of the requirements in our exercise was to authorize the user against a ROLE X URI matrix, called “Authorization Matrix”. In this post we’re looking at the second policy (Call ‘Perform Authorization’) in the overall flow:



Basically, “Perform Authorization” had to:

a. Obtain the authenticated user (authenticated by Kerberos);

b. Lookup the groups memberships in Active Directory;

c. For the requested URI, query a Database for the authorized roles for that URI in particular;

d. Check if any of the user groups (obtained from AD) is in the list returned by the DB query;

e. Authorize the user in case the check on the previous steps passes.

Part 1: Kerberos Authentication, RBAC and SAML identity propagation in OAG

This post is the first one of a series by Andre Correa and Paulo Pereira on OAG (Oracle API Gateway).

Throughout the series, we are going to talk about Kerberos authentication, Role Based Access Control (RBAC) and SAML identity propagation in OAG 11g, formerly known as OEG (Oracle Enterprise Gateway). What follows has been implemented as part of a larger exercise involving the SOA suite, OSB, OTD (Oracle Traffic Director) and the Exalogic platform. The kind of architecture presented here can be used as general guidance, but that may not apply to your use case scenarios. We will also briefly touch on OWSM policies that were applied to OSB and SOA composite.

The use case is about enabling end users to place orders. As you might think, there are quite a few 3rd-party systems to interact with in order to have the order fulfilled and the product provisioned to the end user. SOA to the rescue.

Security Requirements

Provide a security shell around SOA and channel each and every request through OAG. The classic model of perimeter defense. As the applications used by end users are Kerberos enabled, the customer wanted to see OAG authenticating Kerberos tokens generated by Active Directory’s KDC (Key Distribution Center). After authentication, we were asked to authorize the user based on a Security Matrix (a relation of groups and URIs) kept in an Oracle database. Finally, with the user properly authenticated and authorized, we should forget Kerberos and instead propagate a SAML token to the SOA platform. This identity should then be preserved all the way to downstream 3rd-party systems.

At the end of our exercise, the policy we built in OAG is expressed as the following circuit, where we can clearly see authentication, authorization and token switch. We expand the contents of each filter/policy as we go. In this post, we focus on the Kerberos Service filter and how we enable the policy for the service we want to protect.

Deployment Architecture

All Oracle FMW components (as well as OAG) were deployed for HA on a 4-node 1/8 Exalogic rack, as per the following diagram.