You may have seen/heard/read that the Burton Group is working with customers to define an interoperable services model for identity. It’s a topic on the tip of many of our customers’ tongues. To date, we have interviewed some customers to begin the process of defining identity services, gathering their respective requirements, and thinking of potential roadmaps towards productization of these services. In Q2 and at Catalyst, you can expect to see additional developments in this area.
Multiplicity of Services – One Is Not Enough
One truth that became clear in our interviews is that organizations require multiple identity services. They include (in prioritized order) authorization, authentication/credentialing, provisioning, and attribute (which is potentially rolled into the authorization service). While authorization is by far the most desired identity service (and thus far, the most implemented—albeit as custom code), those customers who have built and implemented an authorization service say that other services (notably, an authentication/credentialing service) are required to support it. It’s also evident that identity services are not just required for users; they are required for endpoints (for example, policy decision points and policy enforcement points). Like users, these endpoints require authentication and authorization.
While at a high level the list of services is self-evident, several need further description. The authentication/credentialing service is responsible for validating the multiplicity of user credentials that are presented when accessing services. The credentialing service also must be able to transition credentials to other mediums – otherwise known as a security token service (STS). For example, the credentialing service may transition the user’s SAML credentials to a “local” credential for the authorization service. Additionally, some customers are looking for session or global logout capabilities from this service. The attribute service is more of a DSML-type service to assist applications in personalizing user sessions. The attribute service may be tightly coupled with the authorization service, or may be a standalone service that is called by the authorization service.
From discussion with our customers and other folks in the industry, it appears that a provisioning service is not a priority, even in federation use cases. Within the enterprise, organizations are “getting by” with provisioning and directory tools. For federation scenarios, organizations are using all kinds of tools (including Microsoft Excel spreadsheets) – everything except a federated provisioning service. We hope that the promise of endpoint interoperability and transactional capabilities will drive the need for provisioning services – it’s still pretty early in SPML v2 standard (for example, some schema issues remain unaddressed).
Realistic Expectations
Those customers who have built and implemented custom identity services (again, usually authorization) realize that the service can serve only a subset of applications. One example is the existence of an authorization service for web applications with finer-grained authorization requirements, but not for mainframe applications. Additionally, a WAM system may be utilized for coarser-grained web applications. This environment requires an authentication/credentialing service to transition WAM and federation credentials for the authorization service
The Standard Is Not the Service
What is the role of the various identity-based standards (for example, SPML, XACML, WS-Trust, and SAML) in identity services? The standard (while crucial) does not equal the service, because the standard generally does not provide the necessary authentication, authorization, confidentiality, and integrity features – and it’s not the right level of abstraction. By the way, the answer is not to build these security features into the identity-based standard because these features exist within other standards (including WSS). Also, adding these features to the already complicated standards would make them too burdensome to implement.
For example, there are no built-in authorization capabilities within SPML. When building SPML-based services, organizations must ensure that only authorized requestors are allowed to create users at the provisioning service point. Very course-grained authorization can be achieved via a CA certificate trust list. This approach won’t scale for an environment with many requestors and provisioning service points. We discuss this issue within our (publicly available, registration required) SPML research document.
XACML faces similar hurdles. The standard does not provide the necessary authentication/credentialing services required for PDP-PEP interaction. The OASIS XACML TC recognizes this fact, and has proposed a profile for using WSS with XACML.
In general, most identity services today travel the path of least resistance– over SSL (which provides confidentiality and integrity, but may not address the identity service’s authentication requirements). We know why this is the case - the process for securing SOAP is too hard for most people. However, SOAP remains a preferred binding for identity services, so the issue of securing SOAP messages isn’t going away any time soon.
Our Plans
We’ll continue to interact with our customers via a Burton Group identity service “working group”. As the working group gets seasoned and refined requirements emerge from it, we’ll pull in “trusted” vendors that have been considering identity services to compare customer requirements and product roadmaps. Identity services will be a substantial topic on our Catalyst Conference Day 2 agenda in late June. Who knows what will happen after that?
[posted by Mark Diodati]
Comments