Implementation Descriptions

Overview

This page lists several of the known OpenID to SAML gateway implementations, and provides information about how they operate.

IDCorral Shibboleth IdP Proxy

Background

The IDCorral Shibboleth IdP Proxy is a proof-of-concept for proxying OpenID login for Shibboleth-enabled applications. Since it is only a proof-of-concept, it was implemented with JanRain Engage as the mechanism by which a user selects his/her ID provider. JanRain Engage also aggregates OpenID/OAuth/Facebook Connect into a unified API so that the implementing service – in this case the Shibboleth IdP proxy – has a consistant set of attributes to work with.

The original writeup on this concept can be found here: http://lucasrockwell.com/other/idpproxy.html

Attributes Available from Identity Providers

*At this time, the eduPersonPrincipalName is set by the user the first time he/she logs in, and the Preferred Username is used as a guide for setting this information. The Preferred Username can not be taken at face value because it is not guaranteed to be unique.

Apache2::AuthAny

Background

The Apache module, "Apache2::AuthAny" was developed as an extensible authentication/authorization system. The module currently protects the Distribute project at https://isds-auth.cirg.washington.edu/distribute/index.php

Apache2::AuthAny creates a set of authentication URLs, one for each provider, that are separate from the location of the protected content. A demo with documentation is available at [https://authany.cirg.washington.edu/
]

Attributes Available from Identity Providers

The production version of AuthAny only supports Google authentication through OpenID with the Google email being passed (through AX). The architecture allows any authentication mechanism to be used however, so if another provider is added that passes other attributes, they could potentially be stored in the AuthAny database, and passed through to the protected application.

IdPproxy

Background

IdPproxy was developed as an proxy authentication system, to bridge the divide between SAML2 federations and Social Media. It only works one way, that is it uses Social Media to authenticate persons to SAML2 federation.  

Attributes Available from Identity Providers

The focus has all the time been on authentication, gathering identity information has always been more of a 'nice if we get some'. The reason for this is of course the level of assurance that you get for this information. IdPproxy today supports Facebook, Google, Twitter, general OpenID and Windows Live ID. It does not ask for any attributes outside what these services provide by-default. Hence, we have, so far, not tried to find out what is possible to get out of them.

IdPProxy does some transformations of information received from Social Media, like constructing a displayName from given name and family name if no full name was given. It also constructs an eduPersonPrincipalName from an identifier provided by the service and the domain name of the service.

Template

Below is the template to use for listing attributes from the external IdP.

Name of Identify Provider

Reference links

• OpenID attribute schema: http://www.axschema.org/types/