One of the panels at the recent EIC 2008 on End-to-End Security for SOA applications there was a discussion about whether this target could really be achieved. One comment was that built-in federation awareness in every single web services won’t work with thousands of web services you might have today or in future. The handling of trusts would be too complex, was the argument.

Yes, if you handle every trust separately. No, if there is sort of a trust broker for at least most of the web services which provides a standard trust with no specific configuration per web service. In that case even that concept might work - and federation-enabling web services could be done by the application these services run on.

But it can be done easier, in the context of Web Service Security applications or other approaches. My position is that a web service has to run in the context of the user’s identity. Usually the context will be derived, e.g. a role, a group or something else. A layer like the Web Service Security should be able to work with such a context, which might be provided within a SAML token. But, in general, it might be any type of claim - Kim Cameron’s concept of claim-based security fits in pretty well here.

In fact, the issue can be solved very easy: Take the information in a claim or assertion, transform it to a parameter and invoke the web service based with this parameter. Then the web service can return exactly the information which is relevant (or allowed to see) to the identity the parameter has been derived from. The application infrastructure has just to work as a special type of STS (Security Token Service) which transforms security tokens into parameters for web services.

With this approach, it is as well possible to completely implement the idea of claims into SOA security. The accounting of web services works as well, because the platform from which web services are invoked knows about the identity (or something derived from), because it knows the claim or assertion. And the web service itself can be fully identity- and federation-ignorant.

In fact, there is no reason not to implement a real end-to-end security, either with Federation and an efficient trust handling or with a claims-/assertion-/parameter-based approach like described.

These days I have written a report on the relationship between IAM (Identity and Access Management) and SOA (Service oriented Architecture/Applications). One major aspect of this relationship is around end-to-end-security, e.g. securing the interaction of a user with an application (and the application which implements a business process) up to the backend systems like databases.

That is inevitable because using a service in the context of an user identity or an user role is the only way for consistent, externalized security instead of coded security where some return of a service is filtered by the application depending on the user’s role. Coded security is contradictory to compliance, obviously. It’s expensive in terms of coding and auditing. Thus, it doesn’t make sense.

On the other the most common approaches for web service security are constructed the same way as web access management solutions: Building a layer in front of the services which uses policies to decide how services are used. That includes some part of authorization and sometimes authentication. The problem is: Using such an approach means that there is definitely no end-to-end-security. From my point of view, there is no alternative to federation to transport claims down to the service level. That is the only approach for real end-to-end-security and thus for applications which are architected to fulfill the increasing compliance requirements.

One of the emerging topics in the broader IAM space integrates GRC and Identity Management: Identity Risk Management, including aspects like Identity Risk Metrics. Identity Risk Metrics are used to measure specific aspects of Identity Management. These metrics can be mapped to risks and thus serve as a means to detect and, in the next step, reduce risks. Such metrics can be defined in many areas.

May be the most interesting are Application Risk Metrics – in the context of digital identities. Elements of this category are things like

• Usage of central identity stores (instead of application specific identity stores)
• Sensitive attributes in decentralized identity stores
• Sensitivity of the application and its data
• Supported authentication mechanisms and their strength
• Number of user accounts
• Encrypted storage of passwords
• and many others…

The analysis of these Metrics automatically leads to a clear view on the level of centralization of Identity Management and, combined with the risk view, to a clear rating of risks which exist due to decentralized user management on the application level and the lack of an application security infrastructure.

Measuring these Metrics can clearly lead in more management support for building application security infrastructures and changing the way security is implemented in applications. It is not very difficult to do this sort of analysis. It doesn’t need a specific Risk Management software, it is just about identifying the applications (which is the hardest part) and counting – and may be some analysis in Excel. And it is about mapping the result to defined risks and to provide an answer on the question of “how to reduce  the risk”. The answer is quite obvious – it is the approach of application security infrastructures.

And that is just one example of what you can do with Identity Risk Metrics.