IdPproxy

This is a much wanted situation since it gets rid of the need for each user to maintain different users at each service. But it also creates problems since people outside the community has a harder time getting in. For the federation to work each university participating must adher to strict rules about identity management and therefor must not willy-nilly add new members to itʼs community. Each managed user also comes with a price tag, hence an organization does not want to handle more users than necessary.

To get around these problems we wanted to find a way to let people, with less frequent contacts with the universities or complete newcomers, use account they already have with public services on the Internet like Twitter, Facebook, Google and Windows Live ID.

The upshot of this would be that the an university would not have to create and manage accounts for those users. In some cases access management still would have to be done but over all it would still mean less work for the universities identity management.

We saw three major use-cases:

• Presumtive students
• Persons working outside the university involved in very short term projects with people within the university.
• Persons at workplaces supporting student trainees.

Worth noting is that the Level of assurance (LOA) on the binding between a person and the identity, that this service provides, is less than what is normally provided by IdPs within the university federations. The reason for this is of course that all the information returned by the public service is ultimately provided by the user herself. This has to be taken into account when giving these users access to services within the university.

If special access has to be provided to a person authenticated by this service, information about which public service and handle the user will use has to be provided out-of-band.

The Swedish Alliance for Middleware Infrastructure (SWAMI), decided to create such a service.
Basically what the service does is to act as an SAML2 Identity Provider (IdP) within the SAML2 federation. When the user is redirected to the IdP she can chose one of the public services for the log in. Whatever information the public service returns about the user is repackaged as a SAML2 assertion and returned to the Service Provider (SP).

The public services we wanted to support uses a number of different more or less standard protocols (OpenID, OAuth and Windows Live ID) for doing the login and which protocol/protocol version they use changes over time. Hence this service has to support a changing set of protocols and protocol versions. Still doing this in a central place off-loads a lot of work from the universities.

Design criterias

• The IdPproxy server must look like a fully compliant SAML2 IdP to any SP it communicates with.
• We have limited ourself to only support a set of Social networking services (SNS), namely those that are in most usage in the communities we want to bridge to. So we support: Facebook, Google, Microsoft LiveID, Twitter plus general OpenID.
• We do not really care about the identity information returned. It is nice to get some information but due to the trustworthiness of the information, we do not expect to use it more than for display purposes. Another reason is that since the user controls what information that is released from the SNS we can not make any promises on what to deliver to the federated service.
• We do care about the identifier returned, and would like it to be something the user actually know. This is not always the case.
• The IdPproxy service acts more like a WAYF, that is it will not use an authentication performed on behalf of one federation based service as a valid authentication for another federation based service.
• The IdPproxy will remember the SNS you last used when trying to access a federated service. So it will suggest that you use the same the next time you come around from the same service provider.
• The state of the connection between a web client and the IdPproxy is maintained using cookies.
• eduPersonTargetedId and eduPersonPrincipalName are added by the IdPproxy to the information received from the SNS before sending it on to the federated service.
• Which identity information that are passed on from the SNS to the service provider is controlled by configuring the IdPproxy.
• Which SNS that was used for the authentication is communicated to the Service Provider by being returned in the Authentication Response. It is assigned as a value to AuthenticatingAuthority in the AuthnContext.

The IdPproxy is implemented in Python and based on the pySaml2 software package.
It uses the Mako template system.

Running a IdPproxy server

The server is written as a stand-alone service, without dependencies on special frameworks.
For all the SNSes that are in question here except for the general OpenID server the IdPproxy must be registered at the SNS. Links to where you do that can be found toward the end of this document.

From the SPs point of view

From the users point of view

Usable links

• General information
• Registration

General information

Registration

Microsoft Live ID:
General information
Registration

Twitter:
General information and registration

OpenID:
General information

Download

The software can be downloaded from Launchpad