Building MITRE ID
Convener: Justin Richer
Session: Tuesdays Session 1 Space H
Conference: IIW 10 May 17-19, 2009 this is the complete Complete Set of Notes
Notes-taker(s): Justin Richer
Tags:
openID, enterprise, corporate identity, recycling, pseudonymity
Notes:
MITRE is deploying as an experimental prototype an OpenID server for corporate usage. This service will be available both to internal systems that can’t or won’t be a part of the official SSO yet still want to externalize authentication as well as external systems that are not under MITRE control. Only MITRE employees will ever be provisioned identities on this service, and usage of it will be tied very tightly to existing MITRE credentialing systems. We’re building it as a Java servlet and hope to release our OpenID server implementation as a reference implementation for other organizations to use. Perhaps as a kind of “Apache server for OpenID”. One of the great benefits of OpenID is that the developer of an RP need not register with the administrator of the OP in order to use the authentication system. This is especially important for rapid prototyping of new systems internally as well as external systems with which the company has no prior engagement.
What MITRE is doing is surprisingly unique, but we’re not sure why that’s so. Today companies issue employees an email address and a telephone number as a matter of course, and these are definite tools for engaging with the outside world. We want to explore the idea of also issuing all employees distributed identities such as OpenIDs that they can use at their discretion with outside systems and services. The policies for use of such systems should probably reflect the policies surrounding usage of corporate email accounts in the outside world.
Sun had previously done OpenID@work, which was a very similar program. However, in Sun’s case, the system was opt-in and employees could choose their own identifiers. MITRE is building this in a way that employees are simply issued OpenID credentials that they can access immediately. The government of Estonia issues its citizens OpenIDs that are strongly tied to a national identity card system, and many government applications in that country use it. Google is using OpenID internally for some things by nature of using the Google App Engine internally.
There are open questions on where to tie to existing identity systems in the enterprise. Sun tied to existing systems at credential issue time only, while MITRE is tying in both the credentialing and authentication steps. There are real issues surrounding recycling of identifiers and the usability of opaque identifiers, though webfinger starts to address these.
The US Government is working with the ICAM initiative to determine trust profiles for different protocols and implementations. OpenID has LOA1 profile already in place, and MITRE is interested in pursuing higher levels of certification for MITRE’s instatiation. OpenID is susceptible to the same DNS poisoning attacks that most internet-facing systems are, even if these other systems (like SAML) don’t want to admit it. In addition to tying certain attributes (a unique identifier and an email address) to a user, the LOA profiles can give rise to the idea of “how real is this person”.
Whitelisting of OPs and RPs is an important capability of a system like this, and distributed whitelisting and the OIX model can help this to scale. MITRE is planning on allowing all RPs but whitelisting the RPs of trusted partners in its implementation. MITRE is also looking at what it would take to accept the OpenID credentials of other companies in its external-facing systems.
The notion of “Trust on First Use” (or TOFU) was brought up as a very usable pattern that is supported by the OpenID trust flow. In this method, users decide to trust an endpoint on its first usage and simply verify continuously after that first use. Chris Palmer has given a talk recently about how to fix HTTPS that goes into detail on this topic.
