• $Id: openidfederation.txt 140 2009-09-28 09:23:38Z andreas $

1 Introduction

If I had to design an Identity Federation entirely based upon OpenID, how would I approach that?

I would need the following components:

• OpenID Extension: UserID Expansion
• Scoping
• Whitelist URLs

2 OpenID Extension: UserID Expansion

I don't think that the current user experience with entering your own URL is a very good one, so I would propose this:

The OpenID Consumer would as usual ask the user to enter his/her OpenID.

If the Consumer recognise the OpenID to contain an '@', and the format satisfy LocalUserID@realm.tld, the Consumer would expand the UserID to be:

https://openid.realm.tld/LocalUserID

Then the Consumer continues with normal OpenID operations using this OpenID.

2.1 Detailed expansion rules

$LocalUserID$ is the part before the '@', and $realm$ is the part after the '@'. The expanded OpenID becomes:

• 'https://openid.' + $realm$ + '/' + $LocalUserID$

2.2 IdP Discovery - User experience

For an end-user, SSO will work like this:

1. User goes to the Service Providers
2. User is asked for his/her OpenID
3. User types in andreas@uninett.no. In fact, his e-mail address!
4. Service Provider expands that to https://openid.uninett.no/andreas, and continues with normal OpenID operations
5. User is now sent to the correct Identity Provider, with the username already filled out, so the user does only need to fill out the password, and is then sent back to the service and is authenticated.

Then, when the end-user moves to another protected Service Provider:

1. User goes to the Service Providers
2. User is asked for his/her OpenID
3. User types in andreas@uninett.no.
4. Service Provider expands that to https://openid.uninett.no/andreas, and continues with normal OpenID operations
5. As user is already logged in at the IdP, the user would experience that right after the user clicks submit when entering the OpenID, he/she will be automatically authenticated.

2.3 Simulating Old fashioned IdP Discovery

It might be a requested feature to simulate the old-fashioned IdP Discovery where you click through a list of universities and selects yours. If this is important, it may be reasonable to require that OpenID Servers also work without providing username:

https://openid.uninett.no/

where user have to fill-in usernames at the Identity Provider instead of having it pre-filled. The white-list may be used to populate the drop-down list of Identity Providers.

3 Scoping

All attributes defined to have scoped values, MUST use the scope identical to the realm part of the UserID.

4 Whitelist URLs

A federation operator provides a secured HTTPS endpoint, where it lists all OpenID prefixes that are part of the federation. In example:

https://openid.student.mit.edu/
https://openid.uio.no/
https://openid.uninett.no/

5 Comparison with current SAML federations

OpenID Federations may exist in parallel with SAML federations, or may replace them. A parallel OpenID Federation may be useful in some situations.

• OpenID Federations may be the solution to inter-federations.
• OpenID Federations may be an easy way of providing open access to all service providers.
• Obviously OpenID Federations makes interoperability with OpenID Service Providers, something that is a feature in many federations already.

Here are some general considerations comparing SAML and OpenID Federations:

Pros:

• Better availability in software.
• Easier to setup for Service Providers.
• Easier to combine federated authentication with non-federated authentication.
• Solves the IdP Discovery Mess in a very elegant way, (using UserID Expansion).

Cons:

• Less secure, as it heavily relies on browser CA trust stores.
• Whitelisting is not acceptable according to the initial goal of OpenID, and may be considered misuse of OpenID.
• UserID Expansion does not exists - has to be specified and implemented.
• Lack of Single Logout.
• Hostnames starting on openid. may already be used in organizations for other purposes.
• No control over which Service Providers that may use the infrastructure.

6 Security Considerations

TBD

7 References

• openid OpenID Specifications

8 Authors' addresses

• Andreas Åkre Solberg, UNINETT, andreas.solberg@uninett.no