Page History

...

1. The gateway can operate in either of two modes -- we need to specify which mode is needed first:
   1. a gateway (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)
   2. a gateway serving a single SP (SP admins at your campus configure their apps to use the gateway directly)
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 could use to connect through to those social providers)
   2. which algorithm is used to compute eduPersonTargetedID (ePTID) and eduPersonPrincipalName (ePPN) attributes (see https://spaces.at.internet2.edu/display/socialid/Google+OpenID+Gateway+Attributes )
   3. for the enterprise model, manage individual SPs

Attributes

...

1. The Gateway will assert the following attributes (if provided by the social identity provider):
   1. eduPersonTargetedID
   2. eduPersonPrincipalName
   3. mail
   4. givenName
   5. sn (surName)
2. The mail, givenName, and sn attributes always pass through the Gateway as-is. eduPersonTargetedID (ePTID) and eduPersonPrincipalName (ePPN) will be computed based on the choice made in the Gateway Admin appManager.
3. The gateway will, at least initially, assert the unspecified authentication context AuthnContext 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).
4. The GW will have NO support for per-attribute or per-SP attribute filtering when constructing the SAML Assertion. A future version of the gateway may leverage RequestedAttributes in SP metadata.
5. The GW 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.
6. The gateway should be able to assert a persistent identifier for the user that is:
   1. predictable in advance, on a per-user basis
   2. persistent; multiple gateway instances would assert the same value

...