Exploring OAM’s SAML Identity Assertion

Introduction OAM (Oracle Access Manager) has an interesting feature that often goes unnoticed to a considerable number of people wishing to tackle the problem of identity propagation. It’s OAM’s ability to generate a secure token embedding user information as a result of successful authentication or authorization. My colleagues Rob Otto and Simon Kissane have talked […]

Identity Propagation from OAG to REST APIs protected by OWSM

Introduction This post describes the necessary configuration for propagating an end user identity from OAG (Oracle API Gateway) to REST APIs protected by OWSM (Oracle Web Services Manager). The requirements are: 1) Have a Java Subject established in the REST API implementation. 2) Prevent direct access to the REST API, i.e., only OAG should be […]

Identity Propagation from App to Data Tier

In order to have the ability to audit at all layers of your multi-tier architecture, it is important to have a Subject’s identity tied to all transactions. Many apps leverage JDBC connection pooling however, so a Subject’s identity is lost at the data layer, as everything appears to be coming from the system user configured in the connection pool. What isn’t well known is that the ability to propagate identity from an app container to the data tier is available within the Oracle JDBC libraries, both thin and OCI-based.One can configure a connection pool using a system user, and create a session with proxy user using the app container’s identity.Example snippet:

<%@ page language=”java” contentType=”text/html;charset=UTF-8″%>

<%@ page import=”javax.naming.*,java.sql.*,oracle.jdbc.pool.OracleDataSource, java.util.*,oracle.jdbc.OracleConnection,javax.sql.DataSource,

java.io.PrintWriter”%>

try {

Context ic = new InitialContext();

DataSource dataSource =

(DataSource) ic.lookup(“icam/sampledata”);

 

Properties userNameProp = new Properties();

userNameProp.put(OracleConnection.PROXY_USER_NAME, request.getUserPrincipal().getName());

OracleConnection conn = (OracleConnection)dataSource.getConnection();

conn.openProxySession(OracleConnection.PROXYTYPE_USER_NAME, userNameProp);

PreparedStatement userenvStmt =

conn.prepareStatement(

” select “

+”sys_context(‘USERENV’,’PROXY_USER’) “

+”, sys_context(‘USERENV’,’external_name’) “

+”, sys_context(‘USERENV’,’SESSION_USER’) “

+”, sys_context(‘USERENV’, ‘ENTERPRISE_IDENTITY’) “

+” from dual”

);

ResultSet userenvRset =

userenvStmt.executeQuery();

if (userenvRset.next()) {

out.println(“

Userenv proxy_user : ” +

userenvRset.getString(1) + ““);

out.println(“

Userenv external_name : ” +

userenvRset.getString(2)+ ““);

out.println(“

Userenv session_user : ” +

userenvRset.getString(3)+ ““);

out.println(“

Userenv ENTERPRISE_IDENTITY: ” +

userenvRset.getString(4)+ ““);

}

userenvStmt.close();

This code assumes that the database is also configured to use Enterprise User Security (EUS), which ensures that the identity is consistent across the app container and database.The app container, WebLogic in this case, is configured to use an LDAP authentication provider.

The diagram shows OID as the LDAP store, but this could also be OVD combined with ODSEE or AD.

One would setup a shared schema in the database to map these proxy users to a database:

CREATE USER sharedschema IDENTIFIED GLOBALLY AS ‘’;

GRANT CREATE SESSION TO sharedschema;

CREATE USER app_public IDENTIFIED BY abcd1234

DEFAULT TABLESPACE shared

TEMPORARY TABLESPACE TEMP;

GRANT CREATE SESSION TO app_public;

ALTER USER sharedschema

GRANT CONNECT THROUGH app_public

AUTHENTICATED USING DISTINGUISHED NAME;

Configuring the JDBC data source would leverage the app_public database user and any user that creates a proxy session would have visibility into the sharedschema data.

Who’s that knocking at my door (or web service)?

In the web application security world it is pretty easy to define whom the user of the application is; he or she is the person clicking on the browser and generating requests to your web application.

In the SOA / web services world, where identity propagation is one of the main concerns of those thinking about security, things are not so clear-cut. With web services we are often not concerned with who the end-user of our application is but rather who or what the client of our service is. This client is likely to be the application that is interacting with an end-user or even another web service.

In many cases our service or the authorization policy protecting our service may require the identity of both the ultimate end-user of the enterprise application using our service and the identity of the application itself.

I believe that the factors for determining whether the end-user identity, application / web service client identity, or both are required lie more with what the web service does than with other common security factors such as whether the web service is externally exposed or not.

For instance if I was making a service to publish live updates of the score of my local high school’s football games to trusted media partners, then I’d care about the identity of the applications consuming my service and probably not about the end users of my media partners applications. On the other hand, a web service for a concert ticket exchange must know about both the end user and the client of the service.

There are many ways in which these different identity propagation scenarios can be accomplished using Fusion Middleware products. Josh and I have been spending a lot of time focused on this subject and will be sharing further thoughts and specific “how-to” examples in the coming weeks.

In the mean time, we are very interested in hearing your thoughts on this subject.