Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Concordia meeting notes for sessions AOL and Boeing (20070626)
The Concordia Project workshop in San Francisco (preceding the Burton Group Catalyst Conference) reviewed use cases from organizations deploying services that would encourage interoperability between multiple identity protocols on the Internet.
The presentation by George Fletcher of AOL included:
- A goal for AOL is enabling their customers to access AOL and third party (not-AOL-operated) services on the Internet, with a desire to avoid customer confusion at the signin process for each of these services. In particular, situations where there are multiple options for signin; e.g., AOL screenname vs ICQ vs OpenID vs self-asserted Information Card. Some of their customers might not always recognize the technology underlying the service: a user with a Livejournal account might not be aware they have an OpenID.
- In one use case, a possibility to have seamless single signon (and potentially also signout) across different organizations with independent identity systems. In this use case, a user who has logged into an enterprise should be able to then access a distinct distant service without needing to log in to that service, if the user has established a link between their enterprise login and the distant service. This of course depends on the user recognizing and allowing linkage: how much does the user wish to enable one organization to know about that user's access or behavior at another organization.
- In another, a proposal for an "identity agent" concept, to hide the protocol interoperability issues across a set of services which do not have a common authentication protocol. An identity agent could maintain, perhaps within an operating system-provided keystore, the credentials for users to access different services, and could enable auto-signon (without user interaction). This agent could also support "undo" (removing credentials for a service), as well as blocking prompting for sites where the user does not wish to log in.
Discussions on this use case focused on an implementation difficultly for identity agent in deployment environments where there is no locally trusted operating system service to store a user's credentials, in particular for shared computers (in the spectrum from home computers with accounts shared amongst family members, to publically available walk-up kiosks).
The presentation by Mike Beach of Boeing included
- The drivers for federation at Boeing have included usability: from the user perspective, user efficiency as no need for additional logins and logoffs, and simplicity as no additional accounts or passwords; and from the administrative perspective; efficiency through reduced account management. Account management for accounts created for users in partner organizations (e.g., airlines) have been delegated to those partner organizations.
- A use case of outbound federation to service providers (e.g., 401(k), travel, pension), for both current employees and retirees, and these two user communities may be using different authentication protocols.
- A use case of internal domain integration within the perimeter, in which there are multiple domains federated. In the Boeing case, internal web SSO integrates with WS-Federation via ADFS.
- A use case of standards-enabled endpoints (deep federation), for enabling web SSO for Boeing employees to COTS and Boeing-developed applications. While there are currently multiple choices for protocols (e.g., SAML or WS-Federation), there could be a single, standard, federation interface for both vendors and Boeing in-house developers at which to implement to support SSO.
- A use case of nested federation for Boeing customers (e.g., airlines) to delegate authority to access Boeing services to third party providers (e.g., MROs).