[Issue 79] Remove the uniqueness requirement from externalId

[Hasini Gunasinghe]

Hi Erik & all,

Issue 79 mentions "In the 202 session at IIW14 we discussed removing the uniqueness requirement on externalid." 

Can you please elaborate more on this as to why the uniqueness should be removed from externalId?

IMO, there should be a service consumer friendly id that it can use to uniquely identify a particular resource and currently that requirement is accomplished by externalId.

As Issue 35 also suggests, if CRUD operations are allowed to be made on externalId, client side resource mapping will be much easier.

Appreciate more clarification about the background details on why this issue is reported, in order to decide how to fix it for 1.1.

Thanks,

Hasini.

[Erik Wahlström]

Hi, 

I missed that part of the 202 meeting so I'm not really sure about the background of removing the uniqueness. Maybe someone else can elaborate on the background scenario that was there. What I think was the problem is when you merge two systems, or use different service providers you could potentially run into problems with the current language. Removing it in the spec would make it up to the scim consumer.

/ Erik

[Morteza Ansari (moransar)]

externalId is a namespace the client manages and as such any uniqueness requirement for it should be enforced by the client and not by the endpoint. The reason externalId was added to the schema was for clients that want to use this field as a reference to map a given object in cloud into their on-prem object. Given this attribute has no meaning to the server endpoint and is not used by it, putting restrictions on it seems out of place and too restrictive. The idea was to make recommendation to the client, but not go as far as forcing them to make it unique or non-reassignable, etc.

 

 

Cheers,

Morteza

[Hasini Gunasinghe]

Thanks Morteza for the clarification on this...

Yes, in that perspective - it is unnecessarily restrictive to make the externalID unique.

But if we look at the issue 35 http://code.google.com/p/scim/issues/detail?id=35 - (which has been labeled for Milestone 2.0), it has a valid requirement of being able to perform CRUD operations with externalID. 

If we depend only on id attribute which is generated by service provider, client side has to maintain mappings between id and the relevant service provider wrt a particular resource, when performing CRUD operations on that resource.

If we remove the uniqueness requirement from externalID in 1.1 release, I wonder whether it wont be possible to cater the requirement mentioned in issue 35 above?

Thanks,

Hasini.

[Hasini Gunasinghe]

Hi,

As discussed in the TC on 30th May, it was decided to remove the uniqueness requirement on externalId and leave it for the consumer to decide whether it is maintained unique or not from consumer's perspective.

Regarding the issue 35 which opposes this change: since we still do not have even the design to address the requirement raised in it, it was decided to move with the aforementioned change for 1.1 release and revisit issue 35 in the future.

Following is the proposed change in the text of scim-core-schema to fix the issue 79. Texts that are changed/removed are marked with underlines.:

Old:

Unique identifier for the Resource as defined by the Service Consumer. The externalId may simplify identification of the Resource between Service Consumer and Service provider by allowing the Consumer to refer to the Resource with its own identifier, obviating the need to store a local mapping between the local identifier of the Resource and the identifier used by the Service Provider. Each Resource MAY include a non-empty externalId value. The value of the externalId attribute is always issued be the Service Consumer and can never be specified by the Service Provider. This identifier MUST be unique across the Service Consumer's entire set of Resources. It MUST be a stable, non-reassignable identifier that does not change when the same Resource is returned in subsequent requests. The Service Provider MUST always interpret the externalId as scoped to the Service Consumer's tenant.

New:

An identifier for the Resource as defined by the Service Consumer. The externalId may simplify identification of the Resource between Service Consumer and Service provider by allowing the Consumer to refer to the Resource with its own identifier, obviating the need to store a local mapping between the local identifier of the Resource and the identifier used by the Service Provider. Each Resource MAY include a non-empty externalId value. The value of the externalId attribute is always issued be the Service Consumer and can never be specified by the Service Provider. The Service Provider MUST always interpret the externalId as scoped to the Service Consumer's tenant.

On a side note; I doubt whether this sentence in the externalId description is really applicable as of its current usage:

"The externalId may simplify identification of the Resource between Service Consumer and Service provider by allowing the Consumer to refer to the Resource with its own identifier, obviating the need to store a local mapping between the local identifier of the Resource and the identifier used by the Service Provider."

- because at the moment, it is anyway required to store a local mapping between the local identifier of the resource and the identifier used by service provider.

Thoughts are welcome.

Thanks,

Hasini.

[Kelly Grizzle]

+1 for the new text.

 

> at the moment, it is anyway required to store a local mapping between the local identifier of the resource and the identifier used by service provider.

 

I don’t follow here.  I think the idea is that a consumer can store their local identifier on the service provider and use this to correlate their local account to the user in the service provider.  By doing so the consumer can avoid storing the SCIM user ID locally.  Am I misinterpreting what you are saying?

 

--Kelly

[Hasini Gunasinghe]

Hi Kelly,

On Mon, Jun 11, 2012 at 9:19 PM, Kelly Grizzle <kelly....@sailpoint.com> wrote:

+1 for the new text. 

 

> at the moment, it is anyway required to store a local mapping between the local identifier of the resource and the identifier used by service provider.

 

I don’t follow here.  I think the idea is that a consumer can store their local identifier on the service provider and use this to correlate their local account to the user in the service provider.  By doing so the consumer can avoid storing the SCIM user ID locally.  Am I misinterpreting what you are saying?

Actually according to the current spec, consumer does have to store Id attribute (defined by the service provider) locally because it is with that Id the consumer can perform CRUD operations on the resources stored at the service provider.

Thanks,
Hasini.

[Hasini Gunasinghe]

On Wed, Jun 13, 2012 at 8:37 PM, Hasini Gunasinghe <has...@wso2.com> wrote:

Hi Kelly,

On Mon, Jun 11, 2012 at 9:19 PM, Kelly Grizzle <kelly....@sailpoint.com> wrote:

+1 for the new text. 

 

> at the moment, it is anyway required to store a local mapping between the local identifier of the resource and the identifier used by service provider.

 

I don’t follow here.  I think the idea is that a consumer can store their local identifier on the service provider and use this to correlate their local account to the user in the service provider.  By doing so the consumer can avoid storing the SCIM user ID locally.  Am I misinterpreting what you are saying?

Actually according to the current spec, consumer does have to store Id attribute (defined by the service provider) locally because it is with that Id the consumer can perform CRUD operations on the resources stored at the service provider.

Adding further.. it is more or less the same concern raised in the issue 35 as well.

[Trey Drake]

It doesn't say the consumer needs to store the provider's id it says the consumer must use the id for update/delete.  The consumer need only store the externalID or some other attribute to correlate the service provider id with its local identifier.  If the consumer chooses not to store the service provider id then the access patterns is: search (with externalId), get the service provider id, perform update or delete operation using the id.

Thanks,

Trey

[Hasini Gunasinghe]

Thanks for the clarification...

Yes, this access pattern with two steps, allows consumer to avoid storing the service provider id.

Thanks,

Hasini.