Subject: [scim] Proposed Text for Multi-Tenancy

From: Shelley <[email-masked]>
Date: Wed, 13 Mar 2013 11:15:41 -0500

Regarding the following text from the proposed text for multi-tenancy [1]:

 In any Multi-Tenant Implementation:
>
>    - The SCIM id, defined by the Service Provider, MUST be unique across
>    all Resources for all Tenants
>
>
In HTTP/REST, typically the URL in its entirety serves as the global
identifier for a resource. What are the reasons for imposing such
restrictions on SCIM resource identifiers to be globally unique? SCIM
resources are already relative to a resource and tenant, and MUST be unique
within that context, but it's unclear to me why IDs must be unique beyond
that scope.

*Re: Unique across all Tenants*

In particular, for service providers that use a URL prefix or subdomain to
represent multi-tenancy, the SCIM resource is scoped to the tenant and
therefore the ID is relative to that tenant and unique within that context.
e.g. /Tenants/abc/Users/123 and /Tenants/xyz/Users/123 should be acceptable
as it represents different resources, each relative to its corresponding
tenant.

Technically, this limitation might need to be imposed upon service
providers that use HTTP Headers since the resource identifier (URL) is not
scoped to a tenant; however, this should not be imposed on providers that
use URL-based tenancy.
*
Re: Unique across all Resources*

Likewise, why is this restriction imposed? Resource identifiers are
relative to a SCIM resource endpoint. e.g. /Users/123 and /Groups/123
should be acceptable, since each represents a different resource type.

[1] http://trac.tools.ietf.org/wg/scim/trac/ticket/28#comment:7

---

From: Bjorn Aannestad <[email-masked]>
Date: Wed, 13 Mar 2013 12:31:43 -0500

Good questions!

My take on it is that:
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.

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.

By making the SCIM Id unique across all Resources within the Service 
Provider, both of these are resolved.

Note that The SCIM id is generated by the Service Provider.  On the 
other hand, Resources created by different Tenants can still have 
duplicate externalIds.   This means that one Tenant will not impose any 
constraints on the ids generated by any other Tenant.

-Bjorn Aannestad

On 2013-03-13 11:15 AM, Shelley wrote:
>       * The SCIM id, defined by the Service Provider, MUST be unique
>         across all Resources for all Tenants
>
>
> resources are already relative to a resource and tenant, and MUST be 
> unique within that context, but it's unclear to me why IDs must be 
> unique beyond that scope.
>
> In particular, for service providers that use a URL prefix or 
> subdomain to represent multi-tenancy, the SCIM resource is scoped to 
> the tenant and therefore the ID is relative to that tenant and unique 
> within that context. e.g. /Tenants/abc/Users/123 and 
> /Tenants/xyz/Users/123 should be acceptable as it represents different 
> resources, each relative to its corresponding tenant.
>
> providers that use HTTP Headers since the resource identifier (URL) is 
> not scoped to a tenant; however, this should not be imposed on 
> providers that use URL-based tenancy.
> *
> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Samuel Erdtman <[email-masked]>
Date: Mon, 18 Mar 2013 08:12:54 +0100

Hi All,

A late comment. In the case that company A owning tenant abc buys
company X owning tenant xyz and only wants one tenant, then a merger
of tenants would have to be done. In this case it would simplify the
merger if all id's in them self where unique.
This argument might not grant a MUST on uniqueness but it would be god
to have it recommended with an explanation.

Sent from my iPhone

On 13 mar 2013, at 17:15, Shelley <[email-masked]> wrote:

> Tenants