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.

Identity Propagation in a flow involving OAM, OSB and web services

A Sales Consultant asked for my opinion in a scenario where a customer wants to propagate end user credentials all the way from OAM (Oracle Access Manager) to web services responsible for executing business logic.

In the customer flow, after being authenticated by OAM, the end user is redirected to a portal UI. The UI makes calls to OSB (Oracle Service Bus) which in turn invokes web services deployed on WebLogic Server. One of use case driving requirements is that the end user identity should be available for underlying web service implementation so that it can be recorded in database tables for auditing purposes. Therefore, the main question here is how to get the user identity from OAM token and make it available for web service implementation code.

OAM is a web-based SSO solution. Very roughly put, it works by means of an HTTP cookie called ObSSOCookie which is recognized by OAM's Policy Enforcement Points, known as Web Gates. A Web Gate intercepts all HTTP requests for a protected resource and evaluates whether an ObSSOCookie is present and valid, in which case the user is considered authenticated.

OSB is an SOA integration component within Oracle's SOA portfolio. It provides routing, transformation and mediation capabilities for interactions between heterogeneous services.

Ok, to the solution.

Let's first talk about what happens when an anonymous user accesses the protected portal UI page. Anonymous users don't hold an authenticated ObSSOCookie (note that anonymous users might hold an ObSSOCookie, but for the default OblixAnonymous user), therefore are challenged by OAM's Web Gate according to the configured authentication scheme.

Let's assume in this case a form-based scheme requiring username and password is set. When challenged, the user types in her username and password. Assuming those are correct, an ObSSOCookie identifying the end user is generated and added to the HTTP response. The end user is granted access and directed to the protected resource (portal UI page). Once the user lands on the portal UI page, a call is made to a web service running on a remote WebLogic Server via OSB.

At this point we need to make an important decision: how to retrieve the end user identity and move it forward. Remember that so far it only exists within the ObSSOCookie that is present in the HTTP request. There are two ways to accomplish it: Within the portal UI, i) the ObSSOCookie can be added to an Oracle proprietary SOAP header or ii) the end user identity can be obtained from portal application container's Java Subject and added to a standard SAML message within the SOAP header. In any case, an OAM identity asserter must be configured in WebLogic Server running the portal application. OWSM (Oracle Web Services Manager) also plays a vital role from now on. An OAM identity asserter basically asserts the end user identity present in ObSSOCookie against the configured Identity Store in WebLogic Server. If assertion succeeds, the user principals are added to the container's Java Subject.

OWSM is a key component in Oracle's SOA solution. It provides centralized definition and distributed enforcement of security and management policies for SOA and JavaEE applications. OWSM runtime modus operandi is very simple: simply put, agents installed at specific endpoints intercept and evaluate SOAP calls according to rules specified by attached policies. Policies come in two flavors: client-side and server-side. Client-side policies usually add data to the SOAP message while server-side policies retrieve that data and process them, many times delegating decisions to other third-party mechanisms.

Back to our flow, I recommend approach ii) as the means of propagating the end user identity. For two reasons: a) we're avoiding adding proprietary data to the SOAP message. If one decides for i), on the server side she needs to provide for understanding that proprietary data. Even considering that OWSM natively supports it, the implementation would stay tied to necessarily understanding ObSSOCookie. If your organization standardizes on SAML (Security Assertions Markup Language), for example, that might be a problem. b) OAM is unlikely to be available in a development environment, therefore relying on ObSSOCookie would simply not work. Once the ObSSOCookie is asserted, a Java Subject becomes available within WebLogic Server.

By attaching a SAML-based OWSM client-side policy to the calling endpoint, the OWSM agent will pick the principal from the Java Subject, generate a SAML message and add it to the SOAP header.

There are several options on how the SAML message can be generated: as clear-text, with message-level security (WSS) or sent through an SSL channel. I will cover the details of message-level and transport-level security in OWSM in a subsequent article.

At this point we're making a SOAP call and we've added a SAML token to the SOA header. Next element in our flow is OSB. The key point here is that we don't need to process that token in OSB. All that's required is having OSB configured in pass-through mode and the request will get intact to the invoked web service. On the web service, we attach a SAML-based OWSM server-side policy that is capable of understanding the token generated by the client-side policy. The policy extracts the token and submits it for processing, which in this case means asserting the end user identity against the identity store configured for the WebLogic Server hosting the web service. If the user is successfully asserted, a Java Subject is created and made available to running applications. One can use JAAS APIs to get the authenticated user name and stick it into any DML statements that are executed against a database.

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.

Bearer Confirmation Method (Huh! What is it good for…)

For starters, allow me to introduce myself. My name is Brian Eidelman and I am a new member of the Fusion Middleware Architecture Group (a.k.a the A-Team) and a new contributor to this blog. Since the memo has gone out that in addition to security we will be discussing dogs now, I'd like to introduce my faithful companion Coco.

Now without further ado, my post:

The WSS SAML Token Profile Specification defines several “confirmation methods” by which the contents of the SAML assertion can be linked to the SOAP message content itself. In other words the method of proving that the assertion really goes with the message that it is being sent in.

The “bearer” confirmation method is sort of peculiar in that it defines no process at all for proving the link between the contents of the assertion and the message content. Rather, the link is to be implicitly trusted.

At this point you may be saying to yourself, if there is no means of verifying that the SAML assertion goes with the message, then what good is it?

Well, the trust can be implicit for any number of reasons. It could just be that trusting developers created the service. More likely however, the link between the SAML assertion and the message can be implicitly trusted by the service because the integrity of the link has been delegated to some other external factor; usually to the network level.

In some cases we could be talking about an internal network setup so that all requests to the service are guaranteed to come from a tamper proof trusted client (if you aren’t buying into this, just humor me). In other cases we could be talking about SSL with 2-way authentication. The point is that the service can trust that only a proper trusted client can successfully get a message to it in the first place.

Now at this point you might be thinking to yourself, fine but then how is SAML with bearer confirmation different than just including a username token with no password in the message header.

Well, SAML with bearer confirmation offers a few additional advantages over the plain old username token. Foremost, the assertion can contain not just a username (subject) but also a bundle of attributes that can further serve to identify the user, define a users’ roles, or be otherwise consumed by the service. In addition, the assertion does capture the notion of what entity is “issueing” the assertion (asserting the user identity). Lastly, some SOA stacks may not be able to handle a username token with no password.

So after all that, what is the bearer confirmation good for? Given that it allows us to utilize assertions without the hassles and costs that come with the signing and key references that are a part of the other confirmation methods, bearer is the perfect confirmation method for basic identity propagation to or between internal services. A similar use case where bearer may fit the bill is identity propagation from trusted intermediary that maybe be doing the real authentication to the service over a securely established network connection.