Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Concordia meeting notes for sessions GM and GSA (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 speakers from GM included
- a use case of user who logged into a Microsoft platform should be able to leverage that login into other environments
- a use case user authentication by a trusted device (such as a user logging in from home with an information card)
- a consistent user experience for presence and instant messaging
- automating access across portals that use dissimilar authentication and authorization protocols
- discovering a user's home realm in multiple domain forests
- sharing identity attributes through common claims formats across SAML and WS-* for attributes, pseudonyms and authorization
- session timeout and single logout across environments
The room discussion focused on the current inconsistency in the protocols and implementations on whether and how idle session timeout and single logout can be implemented.
The presentation by speakers from the US GSA on the eAuthentication project included:
- A primary goal is to re-use authentication credentials issued by one organization (not necessarily a government entity) at other organizations (initially federal government agencies), in a identity provider - relying party model.
- Relying party organizations specify the credential requirements level of their application, based upon the level of risk to which the relying party application has been assessed.
- Identity providers are assessed to one of four levels: low confidence password (1), PIN (2), certificate (3), smartcard (4).
- The Managed Validation and Translation Service (MVTS) component can translate from a PKI-based authentication credential (which in their model has a relatively high level of authentication strength) to a SAML assertion, which suitable for use by relying parties operating at a lower level of relying party application risk.
- The eAuthentication project currently supports 21 agencies, 51 relying party applications with 5 SAML-based and 3 PKI-based identity providers.
Some of the challenges they found were:
- Deployments were more difficult due to implementations which maintained a separation between the 'session layer' and 'application layer' functionality: the federation application often could not control what was sent or obtain what was received in TLS negotiation.
- Federation product implementations often made assumptions about the contents of identity provider and relying party user databases, that either (1) a user has accounts on both the identity provider and relying party, and can authenticate to both the identity provider and relying party, and use that to establish a link between those accounts, or (2) the user does not have an account in the relying party, and an account needs to be created there. By contrast, in their environment there is often a need for account activation and account linking in which there are federated users about whom there records in a relying party database, but those records are not 'accounts' (e.g., they do not have authentication credentials).
- As the federation grows and the deployment matures, there are scaling concerns for secure metadata distribution and federation trust anchors.