Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Digital ID World panel on interoperability partners, and developer difficulties (20070924)
A panel on (Microsoft-centric) "Identity Interoperability: A Discussion of Partners" at the DIDW conference (DIDW2007) highlighted one of the failings of the identity management technology industry as a whole: the developer interfaces.
Historically, an ISV/third party application developer that wished to do something other than maintain its own embedded username/password database, something that would ease the process of deploying their application in large enterprises, would be told to "just get the data from LDAP". The LDAP API was comparatively simple, SDKs were available on multiple platforms, and an application could get by with just an ldap_open() and a ldap_search() or ldap_bind() call (although there were numerous subtles and gotchas). With a little bit of work, the ISV could build their product that would be functionally independent of whether the enterprise had a Sun directory server, a Microsoft directory server, or something else.
Today, there is a proliferation of models (Liberty, Shibboleth, OpenID, InfoCard) with distinct protocols, that provide advanced functionality for authentication and attribute/claims transfer, and these models are intended to support applications that might be deployed as an Internet service.
Until recently, an application developer that wished to develop an application that was aware of these services would need to first come up to speed on the language of federation technologies, even if federation in its traditional sense would not be of interest to the developer.
Some open questions:
How much does an application developer need to know about the low-level aspects, such as key exchange, digital signatures, certificate paths, underlying the emerging identity protocols OpenID/SAML/WS-*? Are there interfaces sufficient that an application developer can be unaware of these aspects of a protocol and still build a successful, interoperable and auditable identity-aware application?
What interfaces will be available in the popular development languages that are identity-protocol-agnostic? Hardcoding OpenID, or SAML, or WS-* interchanges in an application seems to be as problematic as hardcoding LDAP calls.
The panel discussed the use of security token service (STS) components for claims transformation. It is not yet known what the difficulty will be of implementing and deploying a STS to support a particular application.
-
As RL "Bob" Morgan has reminded us, claims transformers are gateways, and
No message was ever improved by a gateway.
-- Einar Stefferud