Social-to-SAML Gateway FAQ
Contents:
What is this gateway? Why might I be interested in it?
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.
Are there any legal Issues for a Service Provider if it uses the gateway ?
The operator of the GW would bear any responsibility, if any exists. It is NOT clear that there is any legal responsibility.
how is supporting the use of the gateway different from supporting standard campus-issued Shibboleth identities ?
The gateway will provide the application with an EPPN value for the browser user, just as a standard Shibboleth IDP would. The gateway-provided value will look a bit different (example), but will be persistent and unique.
how can I use the gateway with my application ?
Instructions for using the gateway are available (HERE). Basicially, though, 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 Home Organization provides. Minimally, though, an application will always get an EPPN 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 GW ?
no guarantees, etc
will the pilot end ? If yes, what then ?
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 to provide feedback ....
several kinds: a) issues/bugs with GW, b) suggestions for additional features, c) thoughts on your use of the GW (input to the assessment)