This page is being used to develop the requirements for a shared Social-to-SAML Gateway that would be available to InCommon members.
Management
- The gateway can operate in either of two modes -- we need to specify which mode is needed first:# 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)
- a gateway serving a single SP (SP admins at your campus configure their apps to use the gateway directly)# The gateway would include a Gateway Administer functionality that would allow the admin to specify, on a per SP basis:
- 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)
- which algorithm is used to compute eduPersonTargetedID (ePTID) and eduPersonPrincipalName (ePPN) attributes (see https://spaces.at.internet2.edu/display/socialid/Google+OpenID+Gateway+Attributes
) - 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).
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)
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.
The GW is just a translator; it maps the values in the received assertion from a social identity provider to values in a SAML Assertion sent by the GW. The GW does NOT add any attributes to the SAML Assertion that are are sourced from any other sources.
The GW will have NO support for per-attribute or per-SP attribute filtering when constructing the SAML Assertion.
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.
The GW will not initially include an invitation service.
It would be transparent to SP whether gateway or native social protocol support is used
The current version of the Google OpenID Gateway asserts the following attributes:
eduPersonTargetedID
eduPersonPrincipalName
mail
givenName
sn (surName)
The mail, givenName, and sn attributes always pass through the Gateway as-is.
What would you anticipate using as the key identifier for social identities? email address? other?
properties of the persistent identifier
predictability
persistance, multiple GWs asserting same value