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.

The OAG Policy we created looks like this:

Policy Filters Description

1. Process Service Principal Name (script)

This is a script that obtains the authenticated user. Since it is authenticated via Kerberos, the authenticated user id comes in the format of a SPN, <SERVICE>/<USER_ID>@<DOMAIN_NAME>. However, all subsequent steps rely only on the <USER_ID> part of it. Hence, we wrote a script to parse OAG’s attribute “authentication.subject.id”, where it automatically writes an authenticated user id to.

Here’s our script.

2. Retrieve User Groups from AD

Here we obtain the authenticated user’s AD groups. To do so, we used the “Retrieve Attributes from Directory Server” filter, who obtains current user’s memberOf attribute from Active Directory.



User data are put in OAG’s attribute “attribute.lookup.list”, a HashMap type of data structure. Within the HashMap, OAG keys the user groups values using the retrieved LDAP attribute name, memberOf.

3. Process Group DN

This is just another Scripting Language Filter to parse the result from the previous filter and obtain just the group name out of the retrieved DN (Distinguished Names).

4. Retrieve Authorized Groups for URI

Here we connect to the Database, and run a SQL query to obtain the authorized groups for the requested URI. We used the “Retrieve Attributes from Database” filter to achieve this.



The SQL query to retrieve the authorized roles uses OAG’s attribute “http.request.path” which is automatically created and populated  by OAG with the requested path.

The results of the query are stored in an attribute named after the column names of the SQL query statement, in this case, role_group. OAG adds the prefix “user.” to all attributes populated by the query, resulting in “user.role_group”, used in the next filter in the chain.

5. Set Authorization Result (script)

At this point we have two sets of data, the user’s groups from AD and the authorized roles for this particular URI. We just need to check if one of the user’s groups are in the authorized roles set.

OAG has a filter specifically created for Authorization, called Attributes. We couldn’t make it work for the type of comparison we had to make. We also tried the “Compare Attributes” filter, but it is unable to check whether at least one element of a collection is contained in another collection.

Therefore, we wrote another script to loop through one of the sets and do the checking, again another Scripting Language Filter. Note that if the check passes, we set a custom attribute, “user.is.authorized” to true. This attribute is inspected in the next step to decide if user is granted access to the resource.

Obs: We could have simply returned false here and ended the circuit in case the user is not authorized.

6. Compare Attribute

The last step is just a boolean evaluation, using the “Compare Attribute” filter. This is a simple filter where we have a few options to compare an attribute to a given value.



The result of our authorization policy is a boolean value. If true, we move onto the next step, which is adding a SAML token to the outgoing SOAP message, discussed in the next post of this series. See you there.