Identity Flow in SOA: One Solution

Fri, 14 May 2004 12:05:39 GMT

In a previous entry, I brought up the challenge of preserving the original caller’s identity across tiers. Sure, this can be solved in a half-a-dozen ways, but which is the right way for the given situation? When designing a real software system, it’s all about the tradeoffs.

And the tradeoff I faced is that I want to know the identity of the caller even after I cross from the presentation tier to the application service tier to the database tier. But I don’t want to incur the cost of authenticating a second or third time (at each tier). Remember, my callers’ identities are not guaranteed to be in Active Directory, so a service invocation would mean an extra trip to my own authentication service and database.

My solution is to pass the caller’s identity, out-of-band, as I cross from the presentation tier to the application service tier. Note, I said the caller’s identity, not credentials (by identity, mean all of the information that is required to construct a custom Principal). On the application service tier, I’ll use an HttpModule to pull the identity out of a SOAP header, reconstruct a principal, and attach it to the current request. Now, I can perform role-based authorization in the application service tier.

Of course, passing identity information around the network, even within the external firewall, is dicey. I’ll use IPSec to preserve the integrity of the data that moves between these two tiers.

So, I get the benefit of a trusted-subsystem authentication model, without loosing the ability to perform role-based authorization based on the original caller.

Designer's Challenge: Identity Flow in SOA

Fri, 02 Apr 2004 03:47:02 GMT

The challenge: Make the original caller’s identity flow all the way to the database in a service-oriented architecture.

Here are the assumptions:

1. You are designing an enterprise-wide system and have decided it will consist of a number of autonomous, SOAP-based services.

2. Much of the data behind these services is sensitive. Personal health history information (PHHI), for example.

3. Both internal users (with Active Directory accounts) and external users (without Active Directory accounts) will need to access the services.

4. A user’s identity determines what activities they can perform and what data they can access.

5. Detailed auditing about individual user activity is required.

The diagram below shows a common deployment model for this kind of application. This is similar to Figure 7.4 in Building Secure ASP.Net Applications.

Both internal users and external users access the system through an ASP.Net web application. This web server is located in a demilitarized zone – firewalls separate it from both the Internet and the internal network. Internal users’ credentials are stored in Active Directory. External users’ credentials are checked against a SQL Server database. Since only internal users are in Active Directory, roles for all users are stored in an authorization database. Information in this database is used to construct a GenericPrincipal for each user of the web application.

The application server is configured for Integrated Windows authentication. It authenticates the process identity of the web application. Windows authentication is used to connect to the SQL Server database, which authenticates the identity of the process running on the application server.

Here’s the issue: There is no per-user authorization on the application server or the database. Once we move from the web server to the application server, we authenticate against a single identity. So, we cannot perform any meaningful role-based authorization in the application layer. We also do not know the original caller’s identity for auditing purposes.

How do we design around this? What are the alternatives? What are the tradeoffs?

Matt Terski's Blog

Identity Flow in SOA: One Solution

Designer's Challenge: Identity Flow in SOA