1 / 8

SCIM Ticket #28 “Clarify the Spec on Multi-Tenancy”

SCIM Ticket #28 “Clarify the Spec on Multi-Tenancy”. Summary for IETF-86 Orlando, March 2013. From the last WG. Incorporate multi-tenancy into the spec OR

darin
Download Presentation

SCIM Ticket #28 “Clarify the Spec on Multi-Tenancy”

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SCIM Ticket #28“Clarify the Spec on Multi-Tenancy” Summary for IETF-86 Orlando, March 2013

  2. From the last WG • Incorporate multi-tenancy into the spec OR • Explain that the spec does not address the topic, but provide some pointers/ guidance/ recommendations (similar in spirit to what it does for authentication) OR • Explain that the spec does not address the topic at all.

  3. Approach Taken for the Proposed Text “Explain that the spec does not address the topic, but provide some pointers/ guidance/ recommendations (similar in spirit to what it does for authentication)” (Recognizing that multi-tenancy is an issue for many RESTful APIs) The proposed text is here: http://trac.tools.ietf.org/wg/scim/trac/ticket/28#comment:7

  4. Summary of Proposed Text • Adds a new section titled “Multi-Tenancy” • Lists four multi-tenancy cases • All Consumers share all Resources (no tenancy) • Each single Consumer creates and accesses a private subset of Resources (1 Consumer:1 Tenant) • Sets of Consumers share sets of Resources (M Consumers:1 Tenant) • One Consumer to Multiple Tenants (1 Consumer:M Tenants) • States: “Multi-Tenancy is OPTIONAL. The SCIM protocol does not define a scheme for multi-tenancy.”

  5. Summary of Proposed Text • Includes a sub-section “Associating Consumers to Tenants” • Illustrates four mechanismsthat MAY be used: • Authentication of the Consumer • Resource URL prefix or component • https://www.example.com/Tenants/{tenant_id}/v1/Users • Subdomain • https://{tenant_id}.example.com/v1/Users • HTTP Header: SCIM_TENANT_ID • States: “…the {tenant_id} is a unique identifier for the Tenant as defined by the Service Provider.”

  6. Summary of Proposed Text • Includes a subsection titled “SCIM Identifiers with Multiple Tenants” • States: “The SCIM id, defined by the Service Provider, MUST be unique across all Resources for all Tenants” • States: “The externalId, defined by the Consumer, is required to be unique ONLY within the Resources associated with the associated Tenant.”

  7. Considerations • Multi-Tenancy for RESTful interfaces is larger than just SCIM • A separate I-D can be created to contain specifications in this area • Tenant provisioning, standard URL formats, access control, etc • How burdensome is a “globally unique SCIM id” for Service Providers? • Interoperability

  8. Questions and Discussion

More Related