Subject: Re: [scim] Proposed resolution for externalID

From: Jeremy Palenchar <[email-masked]>
Date: Thu, 10 Sep 2015 14:51:57 -0700

I am resuming work on my SCIM client and have a comment relevant to this
email.

I thought it best to reply here instead of starting a new thread. Please
let me know if you would prefer I start a new thread.

I would very much like to suggest that the Service enforce uniqueness on
the [externalID] per client tenant.

Here is the scenario:

I have a user in my client system that is provisioned into multiple SCIM
Services.  I also set [externalID] = myLocalID for each User. I keep a
mapping in my client of the user to his [id] in each Service. I keep the
mapping so that every time I want to do an update I do not need to search
the Service by [externalID] to get the Service [id] before PUTing the
update using Service\User\[id].

Everything works fine as long as the mapping information remains intact in
my system. I can ADD and PUT changes all I want. My concern comes if the
local mapping store is lost or corrupted.

In this case, I may try to ADD a resource when I should be doing an Update
(Client doesn't know the user already exists).

In my perfect world, the Service would enforce uniqueness on [externalID]
and prevent me from creating a duplicate user in their Service. In this way
I could fail gracefully and call back with an Update for the existing user
instead of creating a duplicate.

Thoughts?

-Jeremy

On Wed, Oct 1, 2014 at 11:47 AM, Phil Hunt <[email-masked]> wrote:

> WG Members,
>
> Morteza and I had a good talk on the phone on today’s informal WG call (we
> did not have quorum), I think we may have a good proposal on externalId for
> your consideration. It does not address everyone’s needs but it addresses
> the concerns about externalId within the scope of our charter which is
> provisioning.
>
> Below is some modified text for the externalId attribute.
>
> It keeps the definition the same, but makes clear who gets to assign the
> value (besides an arbitrary SCIM client).
>
> Please see the text below, the changes are in UPPERCASE.
>
> Proposed text for externalId:
>
> externalId
>       A String that is an identifier for the resource as defined by
> the PROVISIONING client.  The
>       "externalId" may simplify identification of the
>       resource between PROVISIONING client and service provider by
> allowing
>       clientS to use a filter to locate the resource with AN IDENTIFIER
> FROM THE PROVISIONING DOMAIN
>       , obviating the need to store a local mapping between
>       the PROVISIONING DOMAIN'S identifier of the resource and the
> identifier used by
>       the service provider.  Each resource MAY include a SINGLE non-empty
>       "externalId" value.  The value of the "externalId" attribute is
>       always issued by the PROVISONING client and MUST NOT be specified by
> the
>       service provider.  The service provider MUST always interpret the
>       externalId as scoped to the client's tenant.  While the server
>       does not enforce uniqueness, it is assumed that the value's
>       uniqueness is controlled by the client setting the value.  See
>       Section 9 for additional considerations regarding privacy.
>
>
> If any one has any objections or amendments, please let the group know by
> the end of the week.
>
> I propose to post this change to the draft early next week.
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim
>
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 10 Sep 2015 18:09:41 -0700

Externalid is to allow a client to set an id unique in its own domain. 

It may not be true that externalid is unique at the sp. If the sp forced uniqueness on this attribute it would cause bigger problems for many clients because they would be unable or unwilling to change the value that they are placing in externalid.  which is already unique to them. 

A better approach is if the client can choose a naturally globally unique value like a guid or find a second key to establish the sub-domain of users where externalid is unique. Eg email.value ew "@example.com"

Phil

> On Sep 10, 2015, at 14:51, Jeremy Palenchar <[email-masked]> wrote:
> 
> I am resuming work on my SCIM client and have a comment relevant to this email. 
> 
> I thought it best to reply here instead of starting a new thread. Please let me know if you would prefer I start a new thread.
> 
> I would very much like to suggest that the Service enforce uniqueness on the [externalID] per client tenant.
> 
> Here is the scenario:
> 
> I have a user in my client system that is provisioned into multiple SCIM Services.  I also set [externalID] = myLocalID for each User. I keep a mapping in my client of the user to his [id] in each Service. I keep the mapping so that every time I want to do an update I do not need to search the Service by [externalID] to get the Service [id] before PUTing the update using Service\User\[id].
> 
> Everything works fine as long as the mapping information remains intact in my system. I can ADD and PUT changes all I want. My concern comes if the local mapping store is lost or corrupted.
> 
> In this case, I may try to ADD a resource when I should be doing an Update (Client doesn't know the user already exists). 
> 
> In my perfect world, the Service would enforce uniqueness on [externalID] and prevent me from creating a duplicate user in their Service. In this way I could fail gracefully and call back with an Update for the existing user instead of creating a duplicate.
> 
> 
> Thoughts?
> 
> -Jeremy
> 
> 
> 
>> Morteza and I had a good talk on the phone on today’s informal WG call (we did not have quorum), I think we may have a good proposal on externalId for your consideration. It does not address everyone’s needs but it addresses the concerns about externalId within the scope of our charter which is provisioning.
>> 
>> It keeps the definition the same, but makes clear who gets to assign the value (besides an arbitrary SCIM client).
>> 
>>>       A String that is an identifier for the resource as defined by the PROVISIONING client.  The
>>>       resource between PROVISIONING client and service provider by allowing 
>>>       clientS to use a filter to locate the resource with AN IDENTIFIER FROM THE PROVISIONING DOMAIN
>>>       the PROVISIONING DOMAIN'S identifier of the resource and the identifier used by
>>>       always issued by the PROVISONING client and MUST NOT be specified by the
>> If any one has any objections or amendments, please let the group know by the end of the week. 
>>

---

From: Jeremy Palenchar <[email-masked]>
Date: Mon, 28 Sep 2015 13:44:32 -0700

Phil,

Missed your earlier reply. Thank you for your response.

I am suggesting that the Service Provider should enforce externalID
uniqueness per tenant / login-id.

In preparing my response, I found the following text in section 6.2 of the
current specification:

 o  The externalId, defined by the client, is required to be unique
      ONLY within the resources associated with the associated Tenant.

This is precisely, the functionality I am expecting. However, I cannot
find anything in the protocol / schema section of the specification
that would require this behavior on the part of a Server.

For completeness and disambiguation of the spec I suggest we add
something in the Protocol and / or Schema sections that would require
a Server to enforce uniqueness of the External ID per Tenant.

Thank you for your consideration,

-jeremy

On Thu, Sep 10, 2015 at 6:09 PM, Phil Hunt <[email-masked]> wrote:

> It may not be true that externalid is unique at the sp. If the sp forced
> uniqueness on this attribute it would cause bigger problems for many
> clients because they would be unable or unwilling to change the value that
> they are placing in externalid.  which is already unique to them.
>
> A better approach is if the client can choose a naturally globally unique
> value like a guid or find a second key to establish the sub-domain of users
> where externalid is unique. Eg email.value ew "@example.com"
>
> Phil
>
>> Morteza and I had a good talk on the phone on today’s informal WG call
>> (we did not have quorum), I think we may have a good proposal on externalId
>> for your consideration. It does not address everyone’s needs but it
>> addresses the concerns about externalId within the scope of our charter
>> which is provisioning.
>>