Ben Northrop


Decisions and software development


SOA and Authorization: What's so hard about it anyway?


(5 comments)
July 30th 2009


There’s plenty of talk about security and SOA (or should I just say services now?), but the vast majority seems to cover only the issues of authentication and identity management, and neglects the equally important problem of authorization (*1). Although I can't claim to be a security expert, in a series of posts, I’d like to share some of my thoughts and experiences on implementing authorization in the world of service-oriented architectures.

In this first post, I’d like to take a quick trip through some of the basic terms and definitions of authorization, laying the conceptual groundwork for the later posts. Ok, let’s get started!

Access Control Policies

In general terms, an authorization or access control policy defines whether a given subject can perform an action on a particular object. For example, a policy could determine whether "Hines Ward" (subject) can delete a charge (action) from "Mike Tomlin's" account (object). (*2) This decision, to grant or deny access to a specific object or resource, is commonly based on one or more the following four factors:

  1. Role-based (RBAC): Most often, access to a particular operation is granted by virtue of a specific role that a subject is affiliated with. For example, the ability to remove a charge could be granted to any user with an "Account Admin" role.
  2. Attribute-based (ABAC): Access control may also be based on some inherent attribute of the user or object. For example, Account Admins from the Northeast region (user attribute) may remove charges from customers from the Pittsburgh district (object attribute). In this way, access control policies define a relationship from subject to object that must exist in order to perform the action.
  3. Consumer-based: In an SOA world, service endpoints may be open to the network, and so it may be necessary to manage access to an operation based on the consumer of that service. For example, ensure that only the Customer Service may invoke operation "getAccountInfo(customerId)" on the Accounting Service.
  4. Time-based: It is sometimes necessary to restrict access to a particular resource based on the time of day or calendar date - for instance, "only allow changes to accounts during normal business hours, 8am - 5pm".

Access vs. Filtering

Beyond the subject-action-object form of access policy defined above, there's another type of authorization that's just as crucial in enterprise applications: response filtering. Although both types are based on the authorization factors defined above (role, attribute, consumer, time), filtering policies determine not whether a user be restricted to a specific operation on an object, but rather that the data that is retrieved from an operation be narrowed to only those records or fields that the subject is authorized to view . For example, when user "Hines Ward" of the "Pittsburgh" region calls operation "fetchAccounts()", the system can allow access, but return only those account records for customers in the "Pittsburgh" region, and not account records for customers in other regions.

In my experience, these two types of authorization ("access" and "filtering") are often mistakenly conflated, and so are assumed to be satisfied by the same authorization framework. Unfortunately, this isn't usually possible - a framework or solution that protects access to a resource (e.g. URL, endpoint, etc.) is fundamentally different than one that filters result sets or message bodies. It's important, therefore, to identify the type of authorization requirements that exist to guide downstream design.

Architectural Components of Authorization

Having trudged through some of the conceptual territory of authorization, we can now dig into some of the tangible, implementation details. In any authorization solution, most of the following architectural entities exists in some form or another, though they may not be clearly abstracted:

A "Simple", non-SOA Example

Already, authorization seems a little harrowing - and we haven't even gotten to SOA yet! Before we do, as a final step toward laying the authorization groundwork, let's map some of the concepts and architectural elements defined above to territory that's most likely familiar - a simple, stand-alone web application.

simple_authorization3

As the diagram above illustrates, authorization in this "simplest" case can still be rather complex. Policy definitions and decision points are scattered throughout the different layers of the architecture - an interceptor responsible for protecting resources (i.e. URLs) based on roles, the UI for showing/hiding information based on permissions, the business logic for executing complex, attribute-based authorization decisions (e.g. customer can only view their own account), and the data access layer (or database) for filtering data sets to only those records the user is authorized to view. The database stores user, role, permission, and attribute data, queried by the different PDPs.

What's Different in SOA?

As I've written about before, SOA puts a new twist on old problems, and it's the same for authorization. What was a delicate but well-traversed and tractable issue before, is an extremely complex and risk-ridden problem when you stir in the ingredients of a SOA-based enterprise architecture - loosely-coupled services, registries, process engines, stand-alone user interfaces, ldap directories, etc. Although I'll cover these pitfalls in future posts, here are a few monkey-wrenches SOA throws into the authorization machine:

And this is just the tip of the iceberg! In my humble opinion, most of these issues boil down to the same central vs. local diametric decision - i.e. what authorization components should be centrally shared by all services (e.g. User store/service, etc.) and which should be locally (read: redundantly) defined, within each service. Obviously, there are major trade-offs on both sides - performance, maintainability, scalability, and reliability to name just a few.

To sum up, I hope I was able to lay some of the building blocks of authorization. In later posts, I'd like to touch on different approaches, patterns, products, and standards for authorization in SOA. I'd love to hear what you think so far, so please feel free to drop me a comment!

Endnotes

1. For those people who get these mixed up (I used to be one!), authentication tackles the problem of verifying that the user is who he says he is, and identity management with the multi-faceted problem of how users are given identities and how these identities are propagated. Authorization, on the other hand, assumes these first two issues are solved, and deals with ensuring that a user may do only what he has permission to do.

2. Yup, I'm a Steeler fan:)

3. The dividing line between "business logic" and "authorization policy" is often fuzzy - and it's not always clear whether a requirement should be implemented within the confines of the authorization framework, or whether it can be happily embedded within normal business logic code. In an email comment from Rick, he suggested that a good litmus test is the requirements around manageability - e.g. who is responsible for managing access rights, does the logic need to be configurable at run time, etc. I think this is a great point.

I believe that software development is fundamentally about making decisions, and so this is what I write about (mostly). I've been building software for about 20 years now, as a developer, tech lead, and architect. I have two degrees from Carnegie Mellon University, most recently one in philosophy (thesis here). I live in Pittsburgh, PA with my wife, 3 energetic boys, and dog. Subscribe here or write me at ben dot northrop at gmail dot com.

Got a Comment?


Sign up to hear about the next post!

If you liked this article and want to hear about the next one, enter your email below. I don't spam - you'll only receive an email when there's a new post (which is about once a month, tops). It's all low-key, straight from me.

Comments (5)

Nitesh
March 20, 2010
Hey Ben!
This is an excellent post. Hope you find time soon for the follow up post!
Srinivasan P.
March 28, 2010
Excellent post. Waiting in hope you’ll post the Part2 soon…
Erik
May 09, 2010
Very informative and interesting!
Any plans for a follow up on this?
Ben
June 11, 2010
Thanks guys! Part 2 and 3 are in the works now.
November 03, 2010
Wow – great post. Your questions echo a lot of the same challenges I’ve been struggling with conceptually in SOA. Where the hell does user authorization code live in an SOA system? The allure of using an ESB entity to play traffic cop in service-to-service requests is powerful, but this of course leads to terrible problems in its own right. Glad to see I’m not the only one struggling with these questions.