Versions Compared

Old Version 1

changes.mady.by.user Steven Carmody (brown.edu)

Saved on

compared with

New Version 2

changes.mady.by.user Steven Carmody (brown.edu)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. The gateway can operate in either of two modes -- we need to specify which mode is needed first: #
    1. a gateway serving (local or in the cloud) serving an entire campus (campus-level admins configure SPs to use the gateway, and there is some model for delegated administration)
    1. a gateway serving a single SP (SP admins at your campus configure their apps to use the gateway directly)
    # The
  2.  The gateway would include a Gateway Administer functionality that would allow the admin to specify, on a per SP basis:
    1. which social providers can be used on a per-SP basis (ie the gateway would export endpoints which the SP coud use to connect through to those social providers)
    1. which algorithm is used to compute eduPersonTargetedID (ePTID) and eduPersonPrincipalName (ePPN) attributes (see https://spaces.at.internet2.edu/display/socialid/Google+OpenID+Gateway+Attributes
    Image Removed
    1. )
    1. for the enterprise model, manage individual SPs

The gateway will, at least initially, assert the 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).

...