Re: [OpenID] [Openid-specs-ab] Profile for using SCIM with OpenID Connect

[Phil Hunt]

A question I received was about the apparent multiple ways to access a SCIM resource through the profile. In part this is because SCIM offers multiple ways in REST.  But also using the “/Me” path follows the pattern similar to Connect for the UserInfo endpoint. “/Me” is just the SCIM equivalent.

It is also important to remember that while Connect “sub” and SCIM “id” may be similar in format, it will often be true that the values are unique and distinct. One identifier refers to the authentication context, while the other identifier refers to the SCIM profile context.

So for backwards compatibility reasons, the thinking is not to force the two identifiers to be the same and to define “scim_id” to allow the client to use “sub” with OIDC protocol and “scim_id” with SCIM protocol.

Phil

@independentid

www.independentid.com

phil...@oracle.com

On Jun 21, 2016, at 9:32 AM, Phil Hunt <phil...@oracle.com> wrote:

Thanks Erik, found it (for some reason Facebook never notified me).

Using the “/Me” follows the pattern used by Connect for the UserInfo endpoint. “/Me” is just the SCIM equivalent.

However, in the broader use, we had some discussion that clients may want to know the actual id and location for the authenticated user for other reasons.  That said, we might argue that the client must actually do a scim get to the “/Me” endpoint to actually obtain the authenticated user’s id and resource location. 

Phil

@independentid

www.independentid.com

phil...@oracle.com

On Jun 21, 2016, at 9:19 AM, Erik Wahlström <er...@wahlstromstekniska.se> wrote:

Hi Phil,

Did you get my 2 minute review? I sent it over facebook (that´s right :)) to make sure that the review was my me acting as an individual, not from my company.

/ Erik

On Tue, Jun 21, 2016 at 6:13 PM, Phil Hunt <phil...@oracle.com> wrote:

Any comments or feedback? I know a number indicated they plan to read the draft.

Phil

@independentid

www.independentid.com

phil...@oracle.com

On Jun 15, 2016, at 1:10 PM, Phil Hunt <phil...@oracle.com> wrote:

Please find attached, a draft proposal from Chuck Mortimore and myself on using SCIM as an alternate endpoint for profile services in the context of Connect.

This specification defines:

a. Discovery metadata (scim_endpoint) indicating availability of a SCIM Protocol base endpoint

b. Dynamic registration metadata (scim_profile) used to indicate a client intends to use SCIM in addition to or instead of UserInfo

c. An additional ID Token claim (scim_id and scim_location) which specifies the SCIM resource endpoint and identifier associated with the authenticated subject.

By doing this, clients can avoid having to do an external authorization and another round of exchanges to access User profile information with full CRUD features.

Clients can also access SCIM’s more sophisticated query system to ask questions if the authenticated user has particular conditions (e.g. querying a sub-attribute such as “country” in the “addresses” attribute).  

As an example use case: A cloud provider wants to build a user-profile self-service portal. OIDC does the authentication of the user and allows the web service to access the CRUD features of SCIM for the updates.

Phil

@independentid

www.independentid.com

phil...@oracle.com

<Draft: OpenID Connect Profile for SCIM Services.html>

<openid-connect-scim-profile-1_0.txt>

_______________________________________________
Openid-specs-ab mailing list
Openid-...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab

_______________________________________________
Openid-specs-ab mailing list
Openid-...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab

[Nat Sakimura]

I plan to read but it has to wait till next week.

_______________________________________________
general mailing list
gen...@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general

--

Nat Sakimura

Chairman of the Board, OpenID Foundation

Trustee, Kantara Initiative

[Peter Williams]

A long long long time ago, we learned not to use the x509 era authentication context (subject) name when binding to access control. To support name lifecycle  management (eg divorcee changes name) and separation of authorities  one binds more stable identifiers (issuer plus subj uniq Id, for example, when chaining cert style authn evidence).

Provisioning records would fall into the same category.

I saw this same mistake made several times, since, and later fixed, more than once.

Id expect this group to get it right being so full of experts in graphs (that have long distinguished binding by tenant/user guid(s) vs tenant/user name, even in the old (but theoretically rigorous) oasis secure directory resolver stuff -that used to underpin the early openid model.

Sent from my iPhone

[Phil Hunt (IDM)]

Do you mean that clients should not assume there is a permanent relationship between the identifiers: Scim_id and sub? That might be a reasonable assumption. 

I can also see multiple subs mapping to the same scim profile as being reasonable (eg the user may authenticate using multiple OPs). 

I can see an argument for not including scim_id and scim_resource in the id token. This would force scim clients to do a GET /me in order to obtain them and for scim to resolve the mapping. However the client may still infer the same relationship. 

Phil