Security Data Conflicts in Large Scale SOAs

Most large scale SOAs will use some type of role-based or attribute-based security mechanisms to control access to the data and services. In most organizations, this will involve integrating multiple siloes of security domains containing user profiles, policies, access control lists, etc. Each system can in fact be viewed as a siloed security domain since most systems have their security models and infrastructures designed and developed independently of other systems. When you look at it, this is really just another integration scenario. Just as with other integration scenarios, you will run into conflicts with the data. Here, you're dealing with security data--such as attributes about the users (or principals) and attributes about the resources. For an organization that's using attribute-based access control, here are some examples of some of the types of conflicts that might be encountered:

1. The names of the attributes that describe the principals may not match across the different security domains. You'll probably have security policies that say something like "grant access to this resource if attribute ABC of the user equals XYZ". With multiple security domains, there's no guarantee that that attribute about a user will always be called ABC. If that's the case, how does the service deciding whether or not to grant access evalute the policy and make a decision?
2. The attributes that describe a principal may not exist in all domains. In other words, some domains may use more attributes to describe their principals and hence reference these attributes in their policies while in other domains principals aren't even described with such attributes. Using the example from #1, how can you evaluate the policy if the user doesnt' even have an attribute ABC?
3. The semantics of the attributes vary across different domains. This one's actually pretty common. There are a lot of access control rules out there that say "grant access to this resource if the user is an admin". But the concept of admin can vary greatly from one domain to another. For example you can have system admins and HR admins. Does that mean you should grant some system admin access to some HR service that deals with personnel files?

Some of these issues get into the areas of federated identity management and some of the standards out there such as SAML, WS-Federation, WS-Trust can help. Also there are products out there by companies such as Vordel and Layer 7 based on some of these standards that helps you to mediate some of the conflicts. If you have to deal with some of the issues I've described here, it's worthwhile to take a look at what they have to offer. But at the end of the day it will still require some coordinated effort to sync up all the participating parties so that there is some commonality in the security language used to describe the principals, resources, and access control rules.

soa, security, web services security, SAML, ws-trust, ws-federation