Social-to-SAML Gateway FAQ
InCommon has launched a Social-to-SAML Gateway as a pilot project.
Frequently Asked Questions:
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 form campuses running a Shibboleth IDP would be able to access these resources; using teh 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 (replace with Paul's phrase for these creatures). Those providers typically support non-SAML protocols; the Gateway enables Shibboleth-enabled applications to accept non-SAML assertions from social identity providers without making any changes to the SAML-supporting application or its configuration. 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.
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.
What is the level-of-assurance associated with the gateway?
As discussed in the answer to the previous question, social identity providers typically do not identity-proof their users, so the level-of-assurance (LoA) associated with the gateway is generally unspecified (since the LoA of the social identity provider is generally unspecified). There are some notable exceptions, however, as noted in the following paragraphs.
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-authentication basis at their own risk.
Are there any legal Issues for a service provider if it uses the gateway?
The operator of the gateway would bear any responsibility, if any exists. It is NOT clear that there is any legal responsibility. (this doesn't really answer the question)
How is supporting the use of the gateway different from supporting standard campus-based identity providers?
The gateway will provide the application with an eduPersonPrincipalName attribute for the browser user, just as a campus would. The gateway-provided value will look a bit different (example), but it will be persistent and globally unique.
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).
What information will an application get from the gateway about the browser user?
The provided information will actually vary from one social provider to another. This page summarizes what each social identity provider asserts. Minimally, though, an application will always get an eduPersonPrincipalName value.
Does the gateway store any information about who is using it?
The gateway maintains NO state information about users. It does maintain log files so we can get some sense of which applications are relying on the gateway.
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 5 X 8; 1 business day response ?
What are the terms of use for the gateway?
no guarantees, etc
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?
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)