Scott,

Time permitting, please look at these bullet points and offer comments. Thanks, --Keith

_______________________________
Implementing Social to SAML Gateways (excerpted from https://spaces.at.internet2.edu/display/socialid/Handling+Both+Social+and+SAML+Identities )

Permalink to this page: https://spaces.at.internet2.edu/display/socialid/Skeletal+Narrative+on+Soc2SAML+Guidelines

----------
Gateways as Necessary Evils--For a Time

• The majority of current identity federation deployments connect SAML IdPs with SAML Relying Parties (RPs, SPs)

• A growing number of R&E organizations wish to make some of their services accessible to users who prefer to use Social Identity Providers (Twitter, Yahoo, Google, Windows Live, Facebook). Some of these users will in fact not have an R&E organizational SAML identity.

• R&E application owners do not want to modify each SAML-protected SP to handle social identities

• As a result, many have been attracted to the idea of a Social-to-SAML gateway that permits a user to authenticate with their social IdP of choice and access a SAML relying party application or service

• The Social-to-SAML gateway is often designed to take the role of SAML IdP in interactions with RPs. This is driven by the application owner constraint that the solution not involve major modiifications of existing RPs and SPs

• So a key function of the Gateway is to map social IdP asserted authentication events and identity attributes to a corresponding SAML assertion for consumption by the RP.

----------
How to Build an Eventually Dispensable Gateway Service

• The goal is eventually to outgrow the need for gateways by providing native multi-protocol SPs that support both SAML and selected Social IdPs.

• This goal will be easier to achieve if the gateway functions are essentially invisible to the end user. That is, the step in which a user selects an IdP should behave the same way whether or not a Social-to-SAML gateway is involved.

• Unique EntityIDs should be defined for each SocialIdP-Gateway pair. This allows SPs to decide on trust points based on information in SAML2 metadata files if the relevant identity federation supports this.

----------
Future Proofing SAML Assertions Containing Social IdP-Provided Information

• Mapping social IdP assertions to SAML assertions is a core gateway function

• There will be any number of gateways in use in the near term

• The more consistent the Social-to-SAML mappings are across gateways, the easier it will be to transition away from gateways to native multi-protocol SPs.

• Consistency is desirable in several areas:

• Person Identifiers
• A given person's identifier from a given social IdP should be the same, regardless of which gateway it passed through
• Since different Social IdPs may use different attributes to carry the user identifier, the gateway should use different attribute names to carry a given Social IdP's user identifier.
• The user identifier in question should be placed in the SAML subject element by the gateway

• Organization Identifiers--or Why EntityID was Guaranteed to be Misused

• Other attribute names and values

• Also see Section "Conventions on Attributes"

----------
Gateways Must Honor SP Policies on Acceptability of Various Social Providers

• If an SP does not accept a certain Social IdP (e.g., they opt not to accept Facebook-based authentications), the gateway must honor that policy by not offering the prohibited IdP in the IdP selection list available to the end user.