Subject: [scim] Proposed Text for Multi-Tenancy

From: Shelley <[email-masked]>
Date: Wed, 13 Mar 2013 14:17:27 -0500

As a developer of a service provider implementation that supports
multi-tenancy, this requirement seems a bit imposing with little value.
Given that all SCIM resources are relative to a given tenant and to a
particular endpoint/resource type, it seems that the scope of SCIM
identifiers need not go beyond these contexts. The SCIM Protocol is built
upon REST, which is resource-oriented and based on URIs as GUIDs, and so
requiring an additional GUID beyond this seems unnecessary.

Technically, for example, assume that a service provider is using a
standard RDBMS to persist user and group resources. This requirement now
imposes uniqueness of identifiers across tables. Further, consider a case
where a separate database schema maintains the data for each tenant. Not
only must uniqueness be guaranteed across tables, but also across schemas.

*a) Within the proposed text, there is no requirement that the Service
> Provider use the URL to distinguish tenants.  Thus, a URL including a
> non-unique SCIM Id would be ambiguous.*
>

I agree that if service providers choose not to use URLs to distinguish
tenants, they must use unique resource identifiers across all tenants. In
that case, I'd suggest that the burden of this limitation be placed on
these service providers, not on all service providers. This should be a
factor in choosing such a method for implementing multi-tenancy.

Given that the SCIM Protocol is built upon REST where URIs uniquely
identify resources, service providers that choose this method should be
aware of the limitation they are imposing. It is my opinion, however, that
this should be the exception and not dictate requirements for all providers.

*b) There is a use case for retrieval of a resource when the Consumer does
> not know the resource "type" and therefore cannot use a specific resource
> end point.   *
>

Could you elaborate on this use case? Further, if this is a valid use case,
why wouldn't the ability to search across multiple resource types be
sufficient for finding such resources? e.g:

   GET /Tenants/abc?filter=externalId eq xyz
   {
      "totalResults": 1,
      "Resources": [
         {
           "id": "123",
           "resourceType": "User",
           "externalId": "xyz",
           "meta": {
               "location": "https://example.com/Tenants/abc/Users/123",
               ...
           },
           ...
         }
      ],
      ...
   }

(Or alternative to the "resourceType", the response could contain a list of
"Users" and/or "Groups" instead of generic "Resources".)

The current SCIM protocol at least requires that resources are created and
managed at a particular resource endpoint, and the introduction of the
resource type and proposed search functionality seem to offset any need for
a global identifier across all tenants and resources.

---

From: "Morteza Ansari (moransar)" <[email-masked]>
Date: Wed, 13 Mar 2013 20:53:42 +0000

Another reason for this is group membership. Given group members are only identified using the ID field, if ID namespace is per tenant, then you can't have groups that cross tenant boundary regardless of whether the SP uses URL prefix or other mechanisms.

I do see your point that if SP is using multiple DB's, this requirement adds additional burden on the SP.  I think the original intent of this language (in 1.0) was for id to be unique within a given endpoint (in your example each DB), but the language is not quite clear.

Cheers,
Morteza

From: Shelley <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, March 13, 2013 11:17 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [scim] Proposed Text for Multi-Tenancy

As a developer of a service provider implementation that supports multi-tenancy, this requirement seems a bit imposing with little value. Given that all SCIM resources are relative to a given tenant and to a particular endpoint/resource type, it seems that the scope of SCIM identifiers need not go beyond these contexts. The SCIM Protocol is built upon REST, which is resource-oriented and based on URIs as GUIDs, and so requiring an additional GUID beyond this seems unnecessary.

Technically, for example, assume that a service provider is using a standard RDBMS to persist user and group resources. This requirement now imposes uniqueness of identifiers across tables. Further, consider a case where a separate database schema maintains the data for each tenant. Not only must uniqueness be guaranteed across tables, but also across schemas.

a) Within the proposed text, there is no requirement that the Service Provider use the URL to distinguish tenants.  Thus, a URL including a non-unique SCIM Id would be ambiguous.

I agree that if service providers choose not to use URLs to distinguish tenants, they must use unique resource identifiers across all tenants. In that case, I'd suggest that the burden of this limitation be placed on these service providers, not on all service providers. This should be a factor in choosing such a method for implementing multi-tenancy.

Given that the SCIM Protocol is built upon REST where URIs uniquely identify resources, service providers that choose this method should be aware of the limitation they are imposing. It is my opinion, however, that this should be the exception and not dictate requirements for all providers.

b) There is a use case for retrieval of a resource when the Consumer does not know the resource "type" and therefore cannot use a specific resource end point.

Could you elaborate on this use case? Further, if this is a valid use case, why wouldn't the ability to search across multiple resource types be sufficient for finding such resources? e.g:

(Or alternative to the "resourceType", the response could contain a list of "Users" and/or "Groups" instead of generic "Resources".)

The current SCIM protocol at least requires that resources are created and managed at a particular resource endpoint, and the introduction of the resource type and proposed search functionality seem to offset any need for a global identifier across all tenants and resources.

---

From: Shelley <[email-masked]>
Date: Wed, 13 Mar 2013 19:20:44 -0500

>
> *Another reason for this is group membership. Given group members are
> only identified using the ID field*
>

Group members are identified by both a value (ID) and a type (User, Group).
I asked a related question [1] on the mailing list a few weeks ago related
to requiring the type when adding group members, as I was under the
impression that identifiers are not required to be unique across all
resource types.

*if ID namespace is per tenant, then you can't have groups that cross
> tenant boundary regardless of whether the SP uses URL prefix or other
> mechanisms.*
>

I'm not sure that groups should* *ever cross tenant boundaries. The general
goal of multi-tenancy is to create virtual boundaries between
services/resources, so crossing them seems to defeat the purpose and expose
a security risk.

[1] http://www.ietf.org/mail-archive/web/scim/current/msg00935.html

On Wed, Mar 13, 2013 at 3:53 PM, Morteza Ansari (moransar) <
[email-masked]> wrote:

>  Another reason for this is group membership. Given group members are
> only identified using the ID field, if ID namespace is per tenant, then you
> can't have groups that cross tenant boundary regardless of whether the SP
> uses URL prefix or other mechanisms.
>
>  I do see your point that if SP is using multiple DB's, this requirement
> adds additional burden on the SP.  I think the original intent of this
> language (in 1.0) was for id to be unique within a given endpoint (in your
> example each DB), but the language is not quite clear.
>
>
>  Cheers,
> Morteza
>
>   From: Shelley <[email-masked]>
> To: "[email-masked]" <[email-masked]>
>  *b) There is a use case for retrieval of a resource when the Consumer
>> does not know the resource "type" and therefore cannot use a specific
>> resource end point.   *
>>
>
> Could you elaborate on this use case? Further, if this is a valid use
> case, why wouldn't the ability to search across multiple resource types be
> (Or alternative to the "resourceType", the response could contain a list
> of "Users" and/or "Groups" instead of generic "Resources".)
>

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 14 Mar 2013 00:26:24 +0000

I agree with Shelley.  It is a significant burden on the service provider to require fully unique IDs across tenants and resource types.

> Given group members are only identified using the ID field

This is likely going to change with the reference attribute type being added in issue #33.

> The SCIM id, defined by the Service Provider, MUST be unique across all Resources for all Tenants

Maybe this could be reworded so that the MUST is conditional on whether multi-tenancy uses fully unique URIs or not.

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of Morteza Ansari (moransar)
Sent: Wednesday, March 13, 2013 3:54 PM
To: Shelley; [email-masked]
Subject: Re: [scim] Proposed Text for Multi-Tenancy

Cheers,
Morteza

---

From: Phil Hunt <[email-masked]>
Date: Wed, 13 Mar 2013 23:55:49 -0400

Hmmm…calculating a UUID is fairly straight forward and doesn't require checking across tenancies to be universally unique (at least statistically).

Phil

@independentid
www.independentid.com
[email-masked]

On 2013-03-13, at 8:26 PM, Kelly Grizzle wrote:

> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: "Salvatore D'Agostino" <[email-masked]>
Date: Thu, 14 Mar 2013 00:34:22 -0400

I'm with Phil, 

RFC 4122  - x.667 

Not that hard.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil
Hunt
Sent: Wednesday, March 13, 2013 11:56 PM
To: Kelly Grizzle
Cc: [email-masked]; Shelley; Morteza Ansari (moransar)
Subject: Re: [scim] Proposed Text for Multi-Tenancy

Hmmm.calculating a UUID is fairly straight forward and doesn't require
checking across tenancies to be universally unique (at least statistically).

Phil

@independentid

www.independentid.com

[email-masked]

I agree with Shelley.  It is a significant burden on the service provider to
require fully unique IDs across tenants and resource types.

> Given group members are only identified using the ID field

This is likely going to change with the reference attribute type being added
in issue #33.

> The SCIM id, defined by the Service Provider, MUST be unique across all
Resources for all Tenants

Maybe this could be reworded so that the MUST is conditional on whether
multi-tenancy uses fully unique URIs or not.

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Morteza Ansari (moransar)
Sent: Wednesday, March 13, 2013 3:54 PM
To: Shelley; [email-masked]
Subject: Re: [scim] Proposed Text for Multi-Tenancy

Another reason for this is group membership. Given group members are only
identified using the ID field, if ID namespace is per tenant, then you can't
have groups that cross tenant boundary regardless of whether the SP uses URL
prefix or other mechanisms.

I do see your point that if SP is using multiple DB's, this requirement adds
additional burden on the SP.  I think the original intent of this language
(in 1.0) was for id to be unique within a given endpoint (in your example
each DB), but the language is not quite clear.

Cheers,

Morteza

Technically, for example, assume that a service provider is using a standard
RDBMS to persist user and group resources. This requirement now imposes
uniqueness of identifiers across tables. Further, consider a case where a
separate database schema maintains the data for each tenant. Not only must
uniqueness be guaranteed across tables, but also across schemas.

a) Within the proposed text, there is no requirement that the Service
Provider use the URL to distinguish tenants.  Thus, a URL including a
non-unique SCIM Id would be ambiguous.

I agree that if service providers choose not to use URLs to distinguish
tenants, they must use unique resource identifiers across all tenants. In
that case, I'd suggest that the burden of this limitation be placed on these
service providers, not on all service providers. This should be a factor in
choosing such a method for implementing multi-tenancy.

Given that the SCIM Protocol is built upon REST where URIs uniquely identify
resources, service providers that choose this method should be aware of the
limitation they are imposing. It is my opinion, however, that this should be
the exception and not dictate requirements for all providers.

b) There is a use case for retrieval of a resource when the Consumer does
not know the resource "type" and therefore cannot use a specific resource
end point.

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 14 Mar 2013 16:02:42 +0000

You're right ... generating a uuid is not hard.  My bigger concern is where the SP is putting a SCIM interface on an existing datastore (eg - a multi-tenant app that uses a database per tenant).  In this case we may be imposing a restriction that has little value (if they have unique URIs) but won't be able to use the underlying datastore's existing identifiers.

--Kelly

From: [email-masked] [mailto:[email-masked]] On Behalf Of Salvatore D'Agostino
Sent: Wednesday, March 13, 2013 11:34 PM
To: 'Phil Hunt'; Kelly Grizzle
Cc: [email-masked]; 'Shelley'; 'Morteza Ansari (moransar)'
Subject: Re: [scim] Proposed Text for Multi-Tenancy

I'm with Phil,

RFC 4122  - x.667

Not that hard.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, March 13, 2013 11:56 PM
To: Kelly Grizzle
Cc: [email-masked]<mailto:[email-masked]>; Shelley; Morteza Ansari (moransar)
Subject: Re: [scim] Proposed Text for Multi-Tenancy

Hmmm...calculating a UUID is fairly straight forward and doesn't require checking across tenancies to be universally unique (at least statistically).

Phil

@independentid
www.independentid.com<http://www.independentid.com>
[email-masked]<mailto:[email-masked]>

--Kelly

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Morteza Ansari (moransar)
Sent: Wednesday, March 13, 2013 3:54 PM
To: Shelley; [email-masked]<mailto:[email-masked]>
Subject: Re: [scim] Proposed Text for Multi-Tenancy

Cheers,
Morteza

The current SCIM protocol at least requires that resources are created and managed at a particular resource endpoint, and the introduction of the resource type and proposed search functionality seem to offset any need for a global identifier across all tenants and resources.
_______________________________________________
scim mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/scim

---

From: Bjorn Aannestad <[email-masked]>
Date: Thu, 14 Mar 2013 11:45:13 -0500

FWIW, when I once did this before (exposing multiple tenants through a 
single interface) it wasn't too hard to prepend the "database id" onto 
the not-globally-unique record ids.  They weren't used for internal 
references, of course.

More to the point: When unique URIs are in use in the context of 
multi-tenancy, can we equivocally say that there are no cases where a 
resource identifier would be used alone, without the disambiguating 
URI?   A single reasonable use case would indicate that there is a need 
for globally unique identifiers.

-Bjorn

On 2013-03-14 11:02 AM, Kelly Grizzle wrote:
>
> You're right ... generating a uuid is not hard.  My bigger concern is 
> where the SP is putting a SCIM interface on an existing datastore (eg 
> -- a multi-tenant app that uses a database per tenant).  In this case 
> we may be imposing a restriction that has little value (if they have 
> unique URIs) but won't be able to use the underlying datastore's 
> existing identifiers.
>
> --Kelly
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Salvatore D'Agostino
> *Sent:* Wednesday, March 13, 2013 11:34 PM
> *To:* 'Phil Hunt'; Kelly Grizzle
> *Cc:* [email-masked]; 'Shelley'; 'Morteza Ansari (moransar)'
> *Subject:* Re: [scim] Proposed Text for Multi-Tenancy
>
> I'm with Phil,
>
> RFC 4122  - x.667
>
> Not that hard.
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Phil Hunt
> *Sent:* Wednesday, March 13, 2013 11:56 PM
> *To:* Kelly Grizzle
> *Cc:* [email-masked] <mailto:[email-masked]>; Shelley; Morteza Ansari 
> (moransar)
> *Subject:* Re: [scim] Proposed Text for Multi-Tenancy
>
> Hmmm...calculating a UUID is fairly straight forward and doesn't 
> require checking across tenancies to be universally unique (at least 
> statistically).
>
> Phil
>
> @independentid
>
> www.independentid.com <http://www.independentid.com>
>
> [email-masked] <mailto:[email-masked]>
>
> I agree with Shelley.  It is a significant burden on the service 
> provider to require fully unique IDs across tenants and resource types.
>
> Maybe this could be reworded so that the MUST is conditional on 
> whether multi-tenancy uses fully unique URIs or not.
>
> --Kelly
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]]*On Behalf Of*Morteza Ansari (moransar)
> *Sent:*Wednesday, March 13, 2013 3:54 PM
> *To:*Shelley; [email-masked] <mailto:[email-masked]>
> *Subject:*Re: [scim] Proposed Text for Multi-Tenancy
>
> only identified using the ID field, if ID namespace is per tenant, 
> then you can't have groups that cross tenant boundary regardless of 
> whether the SP uses URL prefix or other mechanisms.
>
> I do see your point that if SP is using multiple DB's, this 
> requirement adds additional burden on the SP.  I think the original 
> intent of this language (in 1.0) was for id to be unique within a 
> given endpoint (in your example each DB), but the language is not 
> quite clear.
>
> Cheers,
>
> Morteza
>
> *From:*Shelley <[email-masked] <mailto:[email-masked]>>
> *Date:*Wednesday, March 13, 2013 11:17 AM
> *To:*"[email-masked] <mailto:[email-masked]>" <[email-masked] 
> <mailto:[email-masked]>>
> *Subject:*[scim] Proposed Text for Multi-Tenancy
>
> multi-tenancy, this requirement seems a bit imposing with little 
> value. Given that all SCIM resources are relative to a given tenant 
> and to a particular endpoint/resource type, it seems that the scope of 
> SCIM identifiers need not go beyond these contexts. The SCIM Protocol 
> is built upon REST, which is resource-oriented and based on URIs as 
> GUIDs, and so requiring an additional GUID beyond this seems unnecessary.
>
> standard RDBMS to persist user and group resources. This requirement 
> now imposes uniqueness of identifiers across tables. Further, consider 
> a case where a separate database schema maintains the data for each 
> tenant. Not only must uniqueness be guaranteed across tables, but also 
> across schemas.
>
> /a) Within the proposed text, there is no requirement that the Service 
> non-unique SCIM Id would be ambiguous./
>
>
> I agree that if service providers choose not to use URLs to 
> distinguish tenants, they must use unique resource identifiers across 
> all tenants. In that case, I'd suggest that the burden of this 
> limitation be placed on these service providers, not on all service 
> providers. This should be a factor in choosing such a method for 
> implementing multi-tenancy.
>
> identify resources, service providers that choose this method should 
> be aware of the limitation they are imposing. It is my opinion, 
> however, that this should be the exception and not dictate 
> requirements for all providers.
>
> /b) There is a use case for retrieval of a resource when the Consumer 
> resource end point. /
> case, why wouldn't the ability to search across multiple resource 
> types be sufficient for finding such resources? e.g:
>
> (Or alternative to the "resourceType", the response could contain a 
> list of "Users" and/or "Groups" instead of generic "Resources".)
>
> The current SCIM protocol at least requires that resources are created 
> and managed at a particular resource endpoint, and the introduction of 
> the resource type and proposed search functionality seem to offset any 
> need for a global identifier across all tenants and resources.
>
> [email-masked] <mailto:[email-masked]>

---

From: Shelley <[email-masked]>
Date: Wed, 20 Mar 2013 18:09:33 -0500

Generating UUIDs may not be hard, but why should SCIM dictate the use of
UUIDs? This seems like a technical implementation detail that should be
left to the service providers. I am still not sure that there's a valid use
case for *requiring* globally unique identifiers across all tenants and
resources unless the service provider chooses to do so (e.g. by opting for
a non-URL-based tenancy model). To reiterate - the general principle of
REST is to use URIs as global identifiers and it seems unnecessary for SCIM
to require anything beyond this.

Also, to clarify - I'm opposed to *requiring *uniqueness* across tenants*,
but I'm also opposed to requiring uniqueness *across different resource
types*. The language in the core schema for the *id* attribute is a bit
ambiguous about this:

Unique identifier for the SCIM Resource as defined by the Service Provider.
> Each representation of the Resource MUST include a non-empty id value. This
> identifier MUST be unique across the Service Provider's entire set of
> Resources.
>

The "entire set of Resources" may be interpreted as the set of resources
for a given resource type *or *across all resource types. As discussed on
this thread, it seems there should be no reason for identifiers to be
unique across different types of resources (i.e. Users and Groups) even
within the same tenant (provided the clarifications to group membership are
updated as discussed).

On Thu, Mar 14, 2013 at 11:02 AM, Kelly Grizzle <[email-masked]
> wrote:

>  You’re right … generating a uuid is not hard.  My bigger concern is
> where the SP is putting a SCIM interface on an existing datastore (eg – a
> multi-tenant app that uses a database per tenant).  In this case we may be
> imposing a restriction that has little value (if they have unique URIs) but
> won’t be able to use the underlying datastore’s existing identifiers.****
>
> ** **
>
> --Kelly****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Salvatore D'Agostino
> *Subject:* Re: [scim] Proposed Text for Multi-Tenancy****
>
>  ** **
>
> I’m with Phil, ****
>
> ** **
>
> RFC 4122  - x.667 ****
>
> ** **
>
> Not that hard.****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Phil Hunt
> *Cc:* [email-masked]; Shelley; Morteza Ansari (moransar)
> *Subject:* Re: [scim] Proposed Text for Multi-Tenancy****
>
> ** **
>
> Hmmm…calculating a UUID is fairly straight forward and doesn't require
> ****
> ** **
> Phil****
> ** **
> @independentid****
> www.independentid.com****
>
> [email-masked]****
>
> ** **
>
> ** **
>
> ** **
>
> On 2013-03-13, at 8:26 PM, Kelly Grizzle wrote:****
>
> ** **
>
> I agree with Shelley.  It is a significant burden on the service provider
> to require fully unique IDs across tenants and resource types.****
>
>  ****
>
> > Given group members are only identified using the ID field****
>
>  ****
>
> This is likely going to change with the reference attribute type being
> added in issue #33.****
>
>  ****
>
>  ****
>
> > The SCIM id, defined by the Service Provider, MUST be unique across all
> Resources for all Tenants****
>
>  ****
>
> multi-tenancy uses fully unique URIs or not.****
>
>  ****
>
> --Kelly****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>
> ] *On Behalf Of *Morteza Ansari (moransar)
> *Sent:* Wednesday, March 13, 2013 3:54 PM
> *To:* Shelley; [email-masked]
> *Subject:* Re: [scim] Proposed Text for Multi-Tenancy****
>
>  ****
>
> identified using the ID field, if ID namespace is per tenant, then you
> uses URL prefix or other mechanisms.****
>
>  ****
>
> example each DB), but the language is not quite clear.****
>
>  ****
>
>  ****
>
> Cheers,****
>
> Morteza****
>
>  ****
>
> *From: *Shelley <[email-masked]>
> *Date: *Wednesday, March 13, 2013 11:17 AM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[scim] Proposed Text for Multi-Tenancy****
>
>  ****
>
> ****
> non-unique SCIM Id would be ambiguous.*****
>
>
> ****
> resource end point.  *****
>
>
> a global identifier across all tenants and resources.****
>
> https://www.ietf.org/mailman/listinfo/scim****
>
> ** **
>

---

From: Bjorn Aannestad <[email-masked]>
Date: Wed, 20 Mar 2013 18:32:58 -0500

The discussion at Friday's meeting led to the same conclusion -- SCIM 
should not require the globally unique identifiers across tenants.   
That text will be removed from the next revision.

-Bjorn

On 2013-03-20 6:09 PM, Shelley wrote:
> Generating UUIDs may not be hard, but why should SCIM dictate the use 
> of UUIDs? This seems like a technical implementation detail that 
> should be left to the service providers. I am still not sure that 
> there's a valid use case for /requiring/ globally unique identifiers 
> across all tenants and resources unless the service provider chooses 
> to do so (e.g. by opting for a non-URL-based tenancy model). To 
> reiterate - the general principle of REST is to use URIs as global 
> identifiers and it seems unnecessary for SCIM to require anything 
> beyond this.
>
> Also, to clarify - I'm opposed to /requiring /uniqueness/across 
> tenants/, but I'm also opposed to requiring uniqueness /across 
> different resource types/. The language in the core schema for the 
> *id* attribute is a bit ambiguous about this:
>
>     Unique identifier for the SCIM Resource as defined by the Service
>     Provider. Each representation of the Resource MUST include a
>     non-empty id value. This identifier MUST be unique across the
>     Service Provider's entire set of Resources.
>
>
> The "entire set of Resources" may be interpreted as the set of 
> resources for a given resource type /or /across all resource types. As 
> discussed on this thread, it seems there should be no reason for 
> identifiers to be unique across different types of resources (i.e. 
> Users and Groups) even within the same tenant (provided the 
> clarifications to group membership are updated as discussed).
>
>
> On Thu, Mar 14, 2013 at 11:02 AM, Kelly Grizzle 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     You're right ... generating a uuid is not hard.  My bigger concern
>     is where the SP is putting a SCIM interface on an existing
>     datastore (eg -- a multi-tenant app that uses a database per
>     tenant).  In this case we may be imposing a restriction that has
>     little value (if they have unique URIs) but won't be able to use
>     the underlying datastore's existing identifiers.
>
>     --Kelly
>
>     [mailto:[email-masked] <mailto:[email-masked]>] *On
>     Behalf Of *Salvatore D'Agostino
>     *Cc:* [email-masked] <mailto:[email-masked]>; 'Shelley'; 'Morteza
>     Ansari (moransar)'
>     *Cc:* [email-masked] <mailto:[email-masked]>; Shelley; Morteza
>     Ansari (moransar)
>     require checking across tenancies to be universally unique (at
>     least statistically).
>
>     Phil
>
>     @independentid
>
>     Another reason for this is group membership. Given group members
>     are only identified using the ID field, if ID namespace is per
>     tenant, then you can't have groups that cross tenant boundary
>     regardless of whether the SP uses URL prefix or other mechanisms.
>
>     requirement adds additional burden on the SP.  I think the
>     original intent of this language (in 1.0) was for id to be unique
>     within a given endpoint (in your example each DB), but the
>     language is not quite clear.
>
>     Cheers,
>
>     Morteza
>
>     value. Given that all SCIM resources are relative to a given
>     tenant and to a particular endpoint/resource type, it seems that
>     the scope of SCIM identifiers need not go beyond these contexts.
>     The SCIM Protocol is built upon REST, which is resource-oriented
>     and based on URIs as GUIDs, and so requiring an additional GUID
>     beyond this seems unnecessary.
>
>     Technically, for example, assume that a service provider is using
>     a standard RDBMS to persist user and group resources. This
>     requirement now imposes uniqueness of identifiers across tables.
>     Further, consider a case where a separate database schema
>     maintains the data for each tenant. Not only must uniqueness be
>     guaranteed across tables, but also across schemas.
>
>     /a) Within the proposed text, there is no requirement that the
>     Service Provider use the URL to distinguish tenants.  Thus, a URL
>     including a non-unique SCIM Id would be ambiguous./
>
>
>     distinguish tenants, they must use unique resource identifiers
>     across all tenants. In that case, I'd suggest that the burden of
>     this limitation be placed on these service providers, not on all
>     service providers. This should be a factor in choosing such a
>     method for implementing multi-tenancy.
>
>     Given that the SCIM Protocol is built upon REST where URIs
>     uniquely identify resources, service providers that choose this
>     method should be aware of the limitation they are imposing. It is
>     my opinion, however, that this should be the exception and not
>     dictate requirements for all providers.
>
>     /b) There is a use case for retrieval of a resource when the
>     Consumer does not know the resource "type" and therefore cannot
>     use a specific resource end point. /
>
>
>     Could you elaborate on this use case? Further, if this is a valid
>     use case, why wouldn't the ability to search across multiple
>     resource types be sufficient for finding such resources? e.g:
>
>                    "location":
>     "https://example.com/Tenants/abc/Users/123",
>                    ...
>                },
>                ...
>              }
>           ],
>           ...
>        }
>
>     (Or alternative to the "resourceType", the response could contain
>     a list of "Users" and/or "Groups" instead of generic "Resources".)
>
>     The current SCIM protocol at least requires that resources are
>     created and managed at a particular resource endpoint, and the
>     introduction of the resource type and proposed search
>     functionality seem to offset any need for a global identifier
>     across all tenants and resources.
>

---

From: Phil Hunt <[email-masked]>
Date: Wed, 20 Mar 2013 19:31:35 -0700

Unfortunately group memberships and multi-tenancy seems to cause the complication at the moment. 

There was discussion in orlando about allowing optional reference attribute as an alternative way to point to a member, since the old way depends on a unique id - which in multi tenant scenarios becomes a problem. 

Phil

Sent from my phone.

On 2013-03-20, at 16:09, Shelley <[email-masked]> wrote:

> Generating UUIDs may not be hard, but why should SCIM dictate the use of UUIDs? This seems like a technical implementation detail that should be left to the service providers. I am still not sure that there's a valid use case for requiring globally unique identifiers across all tenants and resources unless the service provider chooses to do so (e.g. by opting for a non-URL-based tenancy model). To reiterate - the general principle of REST is to use URIs as global identifiers and it seems unnecessary for SCIM to require anything beyond this.
> 
> Also, to clarify - I'm opposed to requiring uniqueness across tenants, but I'm also opposed to requiring uniqueness across different resource types. The language in the core schema for the id attribute is a bit ambiguous about this:
> 
>> Unique identifier for the SCIM Resource as defined by the Service Provider. Each representation of the             Resource MUST include a non-empty id value. This identifier MUST             be unique across the Service Provider's entire set of Resources.
> 
> The "entire set of Resources" may be interpreted as the set of resources for a given resource type or across all resource types. As discussed on this thread, it seems there should be no reason for identifiers to be unique across different types of resources (i.e. Users and Groups) even within the same tenant (provided the clarifications to group membership are updated as discussed).
> 
> 
> On Thu, Mar 14, 2013 at 11:02 AM, Kelly Grizzle <[email-masked]> wrote:
>> You’re right … generating a uuid is not hard.  My bigger concern is where the SP is putting a SCIM interface on an existing datastore (eg – a multi-tenant app that uses a database per tenant).  In this case we may be imposing a restriction that has little value (if they have unique URIs) but won’t be able to use the underlying datastore’s existing identifiers.
>> 
>>  
>> 
>> --Kelly
>> 
>>  
>> 
>> I’m with Phil,
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt

---

From: Mark Ennis <[email-masked]>
Date: Thu, 21 Mar 2013 13:38:45 +1100

The issue of identifying members of a group when that member is not in 
the local repository is an issue that should be addressed independently 
of the multi-tenancy issue. Whether you are identifying an object in 
another tenant of the current service or on a different service should 
make no difference to the solution. Forcing service providers to 
implement uniqueness across all tenants seems unnecessary and doesn't 
address the real issue.

- Mark.

---

From: Phil Hunt <[email-masked]>
Date: Wed, 20 Mar 2013 20:55:09 -0700

If you don't change then you must have unique uuids or group members may conflict. Thats why i support more discussion on this issue. 

Iow i agree and understand the limitation of not being able to support uuids. But we still have a problem to address. 

Phil

Sent from my phone.

On 2013-03-20, at 19:38, Mark Ennis <[email-masked]> wrote:

> The issue of identifying members of a group when that member is not in the local repository is an issue that should be addressed independently of the multi-tenancy issue. Whether you are identifying an object in another tenant of the current service or on a different service should make no difference to the solution. Forcing service providers to implement uniqueness across all tenants seems unnecessary and doesn't address the real issue.
> 
> - Mark.
>

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 21 Mar 2013 13:07:43 +0000

> There was discussion in orlando about allowing optional reference attribute as an alternative way to point to a member

Once issue #33 is resolved, using a reference (ie - URI) in the group membership list will not be optional.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, March 20, 2013 10:55 PM
To: Mark Ennis
Cc: [email-masked]
Subject: Re: [scim] Proposed Text for Multi-Tenancy

Phil

Sent from my phone.