Importance of Identity
I’m currently working on a security document, and it brought to mind a topic that I’ve wondered about in the past. Why is all of the work around Web Services security user centric? Services are supposed to represent system-to-system interactions. As a result, won’t most policies be based on system identifiers rather than user identifiers?
When outlining an SOA security solution, I think an important first step is to determine what “identity” is in the context of service security. Identity will certainly include user identity, but should also include system identity. There may be other contextual information that needs to be carried along, such as originating TCP/IP address, or branch office location. Not all information may be used for access control purposes, but may be necessary for auditing or support purposes. Identity identification (doesn’t that sound great) can be quite a challenging task, and may only grow more difficult when trying to map it to a credential format, such X.509, Kerberos, SAML, or something else.
The problem gets even more complicated when dealing with composite services. If policies are based on system identity, what system identity do you use on service requests? I think there will likely be scenarios where you want the original identity of the call chain passed through, as well as scenarios where policies are based upon the most recent consumer in the call chain.
If this wasn’t enough, you also have to consider how to represent identity on processes that are kicked off by system events. I’ve previously blogged a bit about events, but in a nutshell, I believe there is a fundamental difference between events and service requests. Events are purely information. Service requests represent an explicit request to have action taken. Events do not. Events can trigger action, and often do, but in and of themselves, they’re just information. This now poses a problem for identity. If a user performs some action that results in a business event, and some subscriber on that event performs some action as a result, what identity should be carried on that action? While the implementation may result in events and implied action, to the business side, the actions the end user took that kicked off the event may represent an explicit request for that action. In other scenarios, it might not. It is safe to say that identity should be carried on both service requests and events allowing the flexibility to choose appropriately in particular scenarios.
All of this should make it painfully clear why Security Architecture (which includes Identity Management in my book) is extremely important.
4 Responses to “Importance of Identity”
Leave a Reply
Liberty Alliance Web Services Framework supports multiple identities being passed within a single SOAP call:
1) that of the sender
2) that of the recipient
3) that of the resource ‘owner'(typically a user), and
4) that of the identity on whose behalf the message is being sent (typically a user, sometimes the same as the resource owner)
such calls can be user-centric if they are consistent with the policies of the users involved
paul
Update: Neil Macehiter of Macehiter Ward-Dutton posted a response to this on his blog with some great recommendations.
I agree this is a complex and important subject, the surface of which is only being scratched right now. I have working in a government context for the past 18 months – we have come to conclude that we need to explicity define policy-based security architecture for:
* Indviduals
* IT Components
* Roles
* Communities/Domians (Including Trust Models)
* Channels
* Processes (including moment-in- time-variant policy)
* Content (structured and unstructure documents & dialogues)
* Business Events
[…] for a title for this entry because as I suspected, I had a previous post that had the title of “Importance of Identity.” That post merely talked about the need to get identity on your service messages and some of the […]