Federated Identity with OpenID

For most sizable corporations, there is a desire to be able to federate identity for users within the corporation to third-parties. For example, your company might provide travel services to employees through a third-party portal, allow employees to view paychecks on a third-party web site, etc. To allow this to be done safely and securely, the two businesses must work together to come up with a way in order to authenticate the corporate user. All too often, though, the third-party has absolutely no hand in the authentication step and merely trusts that a URL from the company, that somehow identifies the user, is legitimate.

Some of the inter-domain federation mechanisms are really, really insecure. I’ve seen some that are so bad that all one needs to do is grab the URL and use it to access an employee’s confidential information.

OpenID can be used to address this issue securely and without using proprietary mechanisms. Rather than authenticating the user and redirecting the user to a third-party with some kind of trust “credentials” inside the URL, the company can just redirect the user to the third-party and provide the user’s OpenID identifier. For example, when redirecting the user to the corporate travel site, perhaps this might be the URL used:

http://travelsite.example.com/?openid=http%3A%2F%2Fopenid.packetizer.com%2Fpaulej

The receiving travel site will receive the OpenID identifier http://openid.packetizer.com/paulej and can then go through the normal OpenID procedures to authenticate the user with the corporation’s OpenID server. This is far better than passing “credentials” around via URLs. Equally important, the method is very simple and secure. Further, it removes the need to create and manage a host of proprietary mechanisms between various “trusted” third-parties.