Subject: [scim] Storing "federated" user identifiers using SCIM

From: Matt Randall <[email-masked]>
Date: Fri, 20 Jul 2018 08:56:35 -0500

Our company has an interesting use case - I was curious if any members of
the group had encountered it when developing their own SaaS platform, if
there were perhaps an existing schema / schema attribute that I had
overlooked, or if there is some sort of existing convention for the
following use case?

For our SaaS platform, we want to enable our customers to push users to our
platform and enable those users to log in with a potential multiplicity of
identity providers (1:M relationship between a user and their individual
identities at different identity provider(s)).  This would require the
storage of both the "issuer" (SAML entity ID, OIDC Issuer) and principal
(and, in the case of SAML, potentially the NameID type.)

I'd imagine this type of data would be modeled as a multi-valued attribute
of user whose values are complex attributes, containing the 2-3
prerequisite data points mentioned above.

To date, we had always aligned SCIM as a 1:1 feed with an identity
provider, requiring the IdP's asserted principal to match the SCIM
username.  We're encountering scenarios where it would be useful for
customers to have a single feed where users use potentially different
identity providers, and where a single user might be serviced by
multiples.  Does anyone else share our use case in this community, or
perhaps encountered an existing pattern for this?

Thank you,

- Matt Randall

---

From: Phil Hunt <[email-masked]>
Date: Fri, 20 Jul 2018 09:00:48 -0700

Matt,

I think this is an interesting question. It may be that a new claim should be defined for tracking identifier relationships with IDPs when users associate more than one IDP.

It goes beyond classic federation and also includes implicit federation through things like email and telephone numbers.

For example, a telephone number used as a verification channel (e.g. sms) vs. telephone number for phone calls is different.

IMO, the phone attribute in SCIM should not be used for this purpose.

So here is the issue. While such a spec might be useful to tell people how they might do this, is it important from an inter-op perspective that people migrate to a common way of doing it?

Phil

Oracle Corporation, Identity Cloud Services Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Jul 20, 2018, at 6:56 AM, Matt Randall <[email-masked]> wrote:
> 
> Our company has an interesting use case - I was curious if any members of the group had encountered it when developing their own SaaS platform, if there were perhaps an existing schema / schema attribute that I had overlooked, or if there is some sort of existing convention for the following use case?
> 
> For our SaaS platform, we want to enable our customers to push users to our platform and enable those users to log in with a potential multiplicity of identity providers (1:M relationship between a user and their individual identities at different identity provider(s)).  This would require the storage of both the "issuer" (SAML entity ID, OIDC Issuer) and principal (and, in the case of SAML, potentially the NameID type.)
> 
> I'd imagine this type of data would be modeled as a multi-valued attribute of user whose values are complex attributes, containing the 2-3 prerequisite data points mentioned above.
> 
> To date, we had always aligned SCIM as a 1:1 feed with an identity provider, requiring the IdP's asserted principal to match the SCIM username.  We're encountering scenarios where it would be useful for customers to have a single feed where users use potentially different identity providers, and where a single user might be serviced by multiples.  Does anyone else share our use case in this community, or perhaps encountered an existing pattern for this?
> 
> Thank you,
> 
> - Matt Randall
> 
> _______________________________________________
> scim mailing list
> [email-masked]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_scim&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=4huGrUWTzM7INaDfFAyjdX5Zuv-IroMCn7fvjCf-S6k&s=R8YOT-RYy6UdMSYBx62oRmMBpzTpv_qJOLpZXoeiuSM&e=