Much of the material in our evolving consensus document will end up in this section |
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
- See 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.
could define policies at the SP saying who is allowed to assert which kinds of identifier; once you make it thru that layer of filtering than the app can trust it...
eg if you trust GWs X, Y, and Z, and IDPs 1, 2, and 3
The Model
-- the SP will have to include support for Discovery
-- by configuring their Discovery mechanism, the SP decides which social providers to allow and trust. if the SP wants to exclude facebook, then the GW has to be able to enforce that policy choice....
-- the SP would also configure the address for the social-to-SAML gateway that they choose to use.
-- the browser user would select their identity Provider (eg a campus, google, yahoo, facebook, etc), and click SUBMIT.
-- the user would be redirected to the gateway; the SP would send an entityID value that identifies the requested social IDP)
-- the browser user would be redirected on to the social provider, authenticate, and be returned to the gateway.
-- the gateway would construct a response to the SPs AuthnRequest, using the guidelines described below.
-- the gateway would issue a POST back to the SP, using a standard SAML flow.
NOTE -- in this model, the user does not see the gateway ever present a GUI
Case Studies