You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Operational

  1. Initially, this service will be offered as a pilot; it is not a production service. The goal is to evaluate the use of and demand for the service, and learn more about requirements. Because this is a pilot, it may be shut down on short notice. -- consequently, use at your risk  initially ....
  2. The SLA associated with the GW will provide 5 X 8 coverage (business hours, Ann Arbor).
  3. The social identity will, at least initially, have an LoA of either 1 or undefined, depending on what value FICAM has assigned to the IDP that was used.
  4. The browser user should only have to traverse a single Discovery Service; they should not be forced to traverse multiple DSs. (ie they  shouldn't have to select "social gateway" from the local DS, and then select a specific social IDP when they reach the GW)
  5. each RP needs to decide whether to support the invitation model, the self-registration model, or both.
  6. The GW will be stateless; it will not include anything resembling a Person Registry; it will not remember anything about a browser user who traverses the GW. It particular, it will not attempt to address the use case of associating a SAML account and a separate social account with a single person. If this is a requirement, then the application at the SP will have to provide this functionality. This so-called "account linking" functionality is out of scope for this discussion.

Usage

  1. A browser user receiving an invitation is NOT required to login from the IDP contained in the invite email

Mode 1 -- SP uses Embedded Discovery Service

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 tot eh 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.

GW -- Handling of input, and outputs

  1. SP can pass a token to the GW (indicating session at SP?); GW must return it
  2. GW MUST forward to the SP the original payload from IDP in an unmolested way (I believe this refers to the Assertion coming from the social IDP, in its native format)
  3. the GW should map and then forward individual attributes ....
    1. we need to define syntax, semantics for Assertions produced by GW

-------- fodder

Mode 2 -- SP Uses central Invitation Service

  1. Is anyone actually interested in this model ?
  2. Issuing the invitation (via email) and remembering which permissions it is associated with seems like an SP issue
  3. preserve any URI that's passed to an invitation service

Mode 3 -- SP relies on Central DS which Includes Social Options

  1. SP passes the GW a filter specifying acceptable IDPs (both SAML and social ? ) SP provides json feed ?
  2. User is presented with a DS, selects IDP, "normal" flow.
  • No labels