InCommon has launched a Social-to-SAML Gateway as a pilot project.
Frequently Asked Questions:
Goals of the Gateway Project
What is this gateway? Why might I be interested in it?
Using the gateway broadens the set of people who can access a SAML-protected resource. Normally, only community members from campuses running a Shibboleth IDP would be able to access these resources; using the gateway opens that up to include anyone who can authenticate at one of the social identity providers. Applications that are already Shibboleth-enabled can accept SAML Assertions from the Social-to-SAML Gateway. These Assertions would represent people who authenticated at one of the social identity providers.
Those providers typically support non-SAML protocols. The Gateway accepts Assertions provided using those protocols and then constructs a SAML Assertion containing those attributes and values. Shibboleth-enabled applications will accept those SAML Assertions in the same way that they accept Assertions from Shibboleth IDPs.
Accepting users who authenticate through a social identity provider relieves campuses of the burden of maintaining a potentially large set of user accounts for 'loosely associated' affiliates at the institution.
What are the Goals of the Project ?
This project is testing the need for allowing identities from outside the InCommon Federation to access Federation-based services, expanding the value of the Federated Identity experience, learning about the issues created by using a variety of social Identity Providers, and understanding the policy differences between an Assertion from a campus IDP and from a social identity provider. There is considerable discussion about how to operate a trust fabric containing different types of Identity providers; this project is a first step to learn about the issues that will arise in that kind of environment. There is interest in exploring ways that the functionality of the current lightweight implementation could be extended to provide "identity augmentation" functionality.
Why is this called a pilot?
This is an experiment. It is not a production service offered by InCommon. It is a pilot being offered by the Univ of Texas System, in partnership with InCommon. It starts 10/1; during Feb 2013 we will assess the usage, and determine the next steps. It may be shut down (summer 2013); it may evolve to become a real service; it may evolve to become a package that campuses can install locally.
Currently, the SLA terms for the gateway are strictly "normal business hours, central time zone";. Normally issues and problems will be addressed within one business day.
What are the terms of use for the gateway?
There are no guarantees, of any sort. Period.
Will the pilot end? If so, when?
Yes, it will definitely end; it will not be a perpetual, open-ended pilot. The assessment in early 2013 will determine the next steps.
How do I provide feedback?
(functionality, policies, futures); point to a form that people can use.
There are several ways to do this: a) issues/bugs with GW, b) suggestions for additional features, c) thoughts on your use of the GW (input to the assessment)
Things to Consider
Is the gateway approach suitable for every application?
Probably not. Many campus-based applications rely on campuses to do some checking to ensure that the digital identity of "Jane Doe" is, in fact, issued to the real Jane Doe. With social identities, usually there is no such checking. Applications that rely on this checking (e.g., applications supporting courses that issue grades) probably should not use this Gateway. However, there are lots of campus-based applications that do not require this type of identity vetting (e.g., applications supporting collaborative work). It is STRONGLY recommended that each service evaluate whether using the Gateway creates an unacceptable risk for that service. As noted, however, many services will conclude that they are not facing any additional risk.
Are there any legal Issues for a service provider if it uses the gateway?
The operator of the GW assumes no responsibility for anything. Both the browser user and an SP site using the gateway are on notice that they have no expectation of privacy, and no legal rights. Each SP using the Gateway must determine its own responsibilities.
How is supporting the use of the gateway different from supporting standard campus-based identity providers?
The gateway will always assert an eduPersonPrincipalName attribute for the browser user, just as a campus IDP would.The GW synthesizes a unique identifier that is unique to the user and each SP that they access. The gateway-provided value will look a bit different (example), but it will be persistent and globally unique. SPs should trust this value at their own risk.
What is the level of assurance associated with the gateway?
The Gateway does not assert any LOA value (unspecified); it just passes through the attributes that the social identity provider has provided. Nothing can be said about the trustworthiness of the values -- they are not covered by any federation policy.
A handful of social identity providers are certified by OIX to be US ICAM LOA 1 Certified Identity Providers. (Like InCommon, OIX is an ICAM-approved Trust Framework Provider.) For example, Google and PayPal are certified LoA-1 identity providers supported by the gateway.
In particular, Google is known to assert the ICAM LOA 1 policy URI by default, in response to all authentication requests. However, the gateway is not currently configured to capture this URI and echo it in the SAML response asserted downstream (since that would require just-in-time validation of the claimed LoA). Thus service providers make determinations regarding LoA on a per-transaction basis at their own risk.
Does the gateway store any information about who is using it?
The Phase 1 implementation is lightweight. The gateway maintains NO state information about the browser users who rely on it. It does maintain log files so we can get some sense of which applications are relying on the gateway.
Using the Gateway
How can I use the gateway with my application?
Instructions for using the gateway are available in the wiki (HERE). Basicially, the application owner will need to decide which social providers they are willing to accept as authentication sources. In addition, the site hosting the application will likely need a Discovery Service so that browser users can identify their Home Organization (more detail available here).
Which Social Identity Providers does the Gateway Support ?
A list of them is available here.
Does the Gateway provide a unique Identifier for each person ?
GW does send EPPN that is the same for each SP. the GW synthesizes a unique identifier; unique to the user and each SP; trust at your own risk (transientID)
Does the Gateway provide other attributes and values ?
The provided attribute values will actually vary from one social provider to another. This page (need a link) summarizes what each social identity provider asserts. Minimally, though, an application will always get an eduPersonPrincipalName value.
How do I know if the person name asserted by a social IdP (if any) is correct?
To our knowledge, there is no social IdP that makes claims about the veracity of person names. Even a certified LoA-1 IdP (social or otherwise) makes no such claims.
That said, some social IdPs (such as PayPal) and many InCommon IdPs have identity-proofed some fraction of their users at some level of assurance (LoA). We do not, however, have any mechanism in widespread use today that permits IdPs to make such claims. Therefore a relying party must make its own determination regarding this aspect of LoA, on either a per-IdP or per-user or per-transaction basis, in whatever manner best satisfies its assurance requirements.
Could I run a version of the gateway locally, at my campus ?
yes. Here's how to obtain a copy. Some campuses have already expressed interest in enhancements including
- invitations
- storing state about browser users in an ldap directory local to the gateway
- augmenting identity by storing and managing additional attributes on those user objects (eg permissions)