unspecified
authentication context URI. A future version of the gateway might assert other AuthnContext
URIs depending on the LoA of the social IdP. For example, some social IdPs (e.g., Google) are certified LoA-1 by ICAM so it would be great if the gateway could proxy an appropriate AuthnContext
URI in this case (but there are technical issues, which is why this capability shouldn't be expected from the initial gateway deployment).Use Case: Browser User goes to an SP, and is redirected to a local Discovery Service. The DS displays some set of SAML IDPs and some set of social IDPs. The user selects an IDP, is returned to the SP, which then redirects the user to the selected IDP. For social IDPs, the user is redirected to an appropriate social-to-saml gateway, along with information indicating which social identity provider the GW should use. The GW redirects the browser user to the social identity site, the user authenticates if necessary, approves the release of some attributes, and is returned to the GW. The GW builds an appropriate SAML Assertion, and forwards the browser user to the original SP. (Note, the browser user has transparently crossed the GW, but has never seen a browser screen presented by the GW.) The SP validates the SAML Assertion, and passes control to the application.
This Use Case can be initiated with either the Invitation model (user receives an email containing a url; goes to that url; use case above initiates) or with the Self registration Model (user obtains a url, goes to that url, use case initiates). In the Invitation Model, it is the responsibility of the Application at the SP to remember which permissions or group memberships were assigned to the social user.
Over the last several months representatives of our campus have been participating in the discussions sponsored by the InCommon/MACE Social Identity Working Group. I think that this discussion has served an important role in understanding the roles that social identities can play in Higher Education. Recently, this group has developed a set of requirements for a centrally run gateway capable of mapping identities from social network providers (eg google, yahoo. facebook, etc) to SAML Assertions that could be consumed by the Shibboleth SP software. There are Research SPs on our campus that would find this to be a valuable way to broaden access to their sites. In addition, our campus is searching for ways to allow a variety of adjuncts in the community to gain short-term access to our LMS system; this gateway would allow that functionality without requiring that we issue Brown identities to all of these people.
We feel that prototyping and testing such a gateway is an important effort, and our campus is willing to participate in this effort through the incubator and service validation stages, for a period of six months. I feel that this testing will help to refine our understanding of needs and cost models. Operating this sort of gateway provides a great way for the community to learn as a group. We understand that there is some risk involved here, and that this may not become a full production service.
I would strongly encourage Netplus to initiate the first steps of creating a pilot service and conducting a proof-of-concept..