Commentary by Mark Wahl, CISA
Organizing principles for identity systems:
Do you know your OpenID URI?
(2007/2/20)
Recent announcements about the support for OpenID from various Internet properties have mentioned the millions of users who now "have" OpenIDs. Since the user is directly involved in the ceremony of OpenID-based authentication, by typing in their OpenID URI and visiting their identity provider, this would suggest that a user who really "has" an OpenID should meet one or more of the following criteria:
- the user can type their OpenID URI
- the user can recognize their OpenID identity provider (OP)
- the user can differentiate between their identity provider and a phishing site masquerading as their identity provider
- the user can change their identity provider while keeping the same OpenID URI
Coté of RedMonk asks on Jyte for predictions on whether At least one of the current "enterprise" identity vendors will support OpenID by the end of 2007. To me this would seem highly likely as IdM vendors often will target technology early adopters by announcing, often during a IdM conference, support for one or more emerging protocols. These protocols are added to the bag of buzzwords for which the product already has some manner of support, be it SAML, SPML, RADIUS, Kerberos, NIS+ etc. However, there doesn't yet seem to be consensus of
What issues in enterprise identity exist that are better addressed by the OpenID protocols than existing techniques?
and then
What should evolve in OpenID to make it more suitable for the enterprise to address these issues?
For one example, in any large enterprise, "your URI" will be Yet Another Identifier. Internal bloggers may know the URIs for their blogs, but this style may not be widely applicable as (1) a user's cute blog name isn't likely to be tracked in the HR department databases and (2) not everyone has a intranet URI for themselves. A HTTP URI based on a identity provider run by the IT department that manages the rest of the IdM infrastructure may not be particularly memorable as:
- the server hostnames may follow some IT-defined server naming scheme.
A user's mail server or printer server DNS names might be auto-configured by the IT department and distributed to the user's laptops and desktops through DHCP and other mechanisms; what about the user's OpenID URI?
- there may be multiple servers for high availability and load balancing.
A user would want the "best" server to be used for their identity provider, based on availability, load, network latency and capacity to the user's desktop and the relying party.
- the organization may have a private DNS namespace for servers within the organization.
The URI that works for authentication to internal servers might not work for authentication to federation partners.
Perhaps within the enterprise there will be a modified step in user-RP interaction ceremony, in which the user provides their identifier (in whatever format the enterprise has chosen: username, user@subdomain, \\subdomain\user, employee id, etc) to the relying party. The relying party searches an enterprise directory for an entry with an attribute containing this identifier, and from that entry obtains the URIs of the user and their identity provider servers. The user doesn't need to know their URIs. (This situation reminds me of the state of early web-LDAP gateways in the mid-1990s, that would prompt the user to enter "their distinguished name". This very quickly was replaced by the user instead searching for their entry, and then authenticating to it, without needing to enter or even see their DN.)
What I'd like to see next is how enterprise SSO and OpenID implementations can be integrated.