Date: Thu, 28 Mar 2024 15:05:08 +0000 (UTC)
Message-ID: <407658291.6559.1711638308057@ip-10-10-7-29.ec2.internal>
Subject: Exported From Confluence
MIME-Version: 1.0
Content-Type: multipart/related;
boundary="----=_Part_6558_1683901453.1711638308055"
------=_Part_6558_1683901453.1711638308055
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Content-Location: file:///C:/exported.html
Draft requirements for a Social2SAML gateway service
Draft requirements for a Social2SAML gateway service
This page is being used to develop the requirements for a Phase =
1 Production Social-to-SAML Gateway. It could be run locally by a campus, o=
r be a shared service that would be available to InCommon members.
Scope
- Support for Google OpenID has been demonstrate
- Prioritize other Social Identity Providers that are required:=20
- Facebook
- Yahoo
- ?
Fun=
ctionality
- The GW is just a translator; it maps the values in the assertion receiv=
ed from a social identity provider to values in a SAML assertion sent to th=
e service provider. The GW does NOT add any attributes to the SAML assertio=
n that are sourced from any other sources.
- The GW will be stateless; it will not include anything resembling a Per=
son Registry; it will not remember anything about a browser user who traver=
ses the GW.
- The browser user should only have to traverse a single Discovery Servic=
e; the user should not be forced to traverse multiple DSs (e.g., the user s=
houldn'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 not initially include an invitation service. However, campu=
s-based invitation services should be able to easily use the gateway.
- It will be transparent to the SP whether gateway or native social proto=
col support is used.
Manage=
ment
- The gateway can operate in either of two modes -- we need to specify wh=
ich mode is needed first:=20
- a gateway (local or in the cloud) serving an entire campus (campus-leve=
l admins configure SPs to use the gateway, and there is some model for dele=
gated 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 Manager function that would allow t=
he admin to specify, on a per SP basis:=20
- which social providers can be used (i.e., the gateway would export endp=
oints which the SP could use to connect through to those social providers)<=
/li>
- which algorithm is used to compute eduPersonTargetedID (ePTID) and eduP=
ersonPrincipalName (ePPN) attributes (see next section)
- for the enterprise model, manage individual SPs
Attrib=
utes
- Attributes available from various providers, and draft mappings
- The Gateway will assert the following attributes (if provided by the social ide=
ntity provider):=20
- eduPersonTargetedID
- eduPersonPrincipalName
- mail
- givenName
- sn (surName)
- The mail, givenName, and sn attributes always pass through the Gateway =
as-is. eduPersonTargetedID (ePTID) and eduPersonPrincipalName (ePPN) will b=
e computed based on the choice made in the Gateway Manager.
- The gateway will, at least initially, assert the unspecified AuthnConte=
xt URI. A future version of the gateway might assert other AuthnContext URI=
s 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 te=
chnical issues, which is why this capability shouldn't be expected from the=
initial gateway deployment).
- The GW will have NO support for per-attribute or per-SP attribute filte=
ring when constructing the SAML Assertion. A future version of the gateway =
may leverage RequestedAttributes in SP metadata.
- The GW will not attempt to address the use case of associating a SAML a=
ccount and a separate social account with a single person. If this is a req=
uirement, then the application at the SP will have to provide this function=
ality. This so-called "account linking" functionality is out of scope for t=
his discussion.
- The gateway should be able to assert a persistent identifier for the us=
er that is:=20
- predictable in advance, on a per-user basis
- persistent; multiple gateway instances would assert the same value
Ope=
n Questions
- What would you anticipate using as the key identifier for social identi=
ties? email address? other?
- Is email a required attributed? In other words, is there interest in a =
social IdP that does not assert email?
- Is there a model for including "people" with social identities in group=
s defined in the campus ldap directory ?
------=_Part_6558_1683901453.1711638308055--