a primer on the system for cross domain · pdf filea primer on the system ... particularly...

A PRIMER ON THE SYSTEM FOR CROSS DOMAIN IDENTITY

MANAGEMENT (SCIM)

WHITE PAPER

MAKING YOUR PROVISIONING PROCESSES SCALABLE FOR THE CLOUD

PRIMER ON SCIMWHITE PAPER

2

TABLE OF CONTENTS

EXECUTIVE OVERVIEW

THE CASE FOR SCIMLearning from the Past

Positive Indicators

SCIM COMPONENTS

Workforce to Cloud

Partner to Partner

IDAAS Provisioning

Authentication

Modern API Framework

Resources, Methods and Operations

Schema

Consumer Encoding/Decoding

Provider Multi-Tenancy

Backward Compatibility

Runtime SCIM Consumers

SCIM, OAuth and OpenID Connect

OAuth

OpenID Connect

USE CASES

PROTOCOL OVERVIEW

SERVICE DESIGN CONSIDERATION

CLOUD IDENTITY SUMMIT 2013 INTERLOP RESULTS

DEFINITIONS

CONCLUSION

03

03

05

06

09

14

12

16

15


3

Many organizations want to authenticate users and provide single sign-on (SSO). But authentication and SSO services are not

possible without user provisioning. The user provisioning process creates the user account—including associated attributes and

access rights—inside the application. In some cases, the application may have a dedicated, or “siloed”, identity store. This case is

particularly true for SaaS applications because of service level agreements (SLAs) and security requirements. In other cases, the

application may leverage a generalized identity store ( an on-premises, LDAP-based directory). Regardless, a user account must be

provisioned in the identity store before the user can access the application.1,2

There is high value placed on the provisioning of user access, but the de-provisioning of access is often neglected. Slow de-

provisioning can result in unnecessary licensing costs. Additionally, there is an increased risk of data breaches and unauthorized

transactions because unauthorized users continue to have access.

Traditional provisioning systems continue to struggle with user management because of the lack of standardization. Without a

common protocol for managing user identities, the system must leverage application-speci c provisioning connectors resulting in

a fragile user management process. Changes to the target application, its operating system or the provisioning system can break

the connection and therefore derail the user management process. Application-speci c schemas require an expansive mapping

of user attributes across applications raising the bar on complexity.

The System for Cross-Domain Identity Management (SCIM) is industry’s latest effort at standards- based provisioning. SCIM

provides a cross-application approach to managing users, groups and devices. It leverages developer-friendly, modern application

program interface (API) frameworks (REST and JSON). It also includes an optional user schema filling the need for an interoperable,

organizational-friendly set of user attributes.

The SCIM working group at the Internet Engineering Task Force (IETF) is responsible for the development of the standard. As of

the publishing of this document, the working group is evaluating enhancements and fixes for the 2.0 speci cation, but most of the

features of the protocol are defined.

EXECUTIVE OVERVIEW

THE CASE FOR SCIM

1 Some might argue that user access is possible without the provisioning process if user access to the application is anonymous. But anonymous access to applications is

extremely rare as it precludes the application’s ability to restrict access to speci c resources and audit user activity.

2 Just-in-time (JIT) provisioning via SAML is consistent with this axiom as it creates the user account prior to application access. But JIT provisioning will not support all

of the user lifecycle management milestones.


4

LEARNING FROM THE PASTAs the identity management industry evolved, several provisioning speci cations were developed, including the Active Digital

Pro le (ADPr), eXtensible Resource Provisioning Management (XRPM), Information Technology Markup Language (ITML), and

WS-Provisioning. None of these specifcations saw adoption.

Service Provisioning Markup Language (SPML) was the provisioning standard before SCIM and was built upon SOAP and XML3.

The rst version of SPML was approved by the Organization for the Advancement of Structured Information Standards (OASIS) in 2003,

with a second version approved in 2006. SPML saw some adoption with traditional provisioning systems, but failed to achieve broad

adoption due to complexity, lack of interoperability and subsequent lack of support by application vendors. As it evolved into v2, too

many functions were added. Conformance to SPML’s core capabilities was never achievable due to the standard’s complexity; not one

commercial provisioning system conformed to either the v1 or v2 core standard. SPML also lacked an optional user schema.

POSITIVE INDICATORSWhile SCIM’s success is not certain, there are some positive indicators:

• APPLICATION SUPPORT. While SCIM support is nascent, a number of vendors provide compatible products and

actively participate in the development of the standard. These vendors include Cisco, Microsoft, Google, Ping

Identity, Salesforce and UnboundID. For SCIM to be successful, more applications need to adopt the standard for

their identity administration APIs.

• SIMPLICITY. The IETF has currently limited the number of operations and their complexity to suit core provisioning tasks.

• OPTIONAL USER SCHEMA. Like the inetorgperson object class in LDAP, a standard schema may not be suitable for

every organization. But it provides a starting point for an organization interested in SCIM and enables partners to

provision users without a complicated attribute mapping process.

SCIM is experiencing adoption among application providers (see Interop Results), though more adoption is required for SCIM’s success.

There is little expectation that vendors will retro t SCIM onto existing, on-premises applications. Therefore, SCIM’s success relies

upon existing and future SaaS application adoption of SCIM. Because SCIM shares the same frameworks with many SaaS identity

management frameworks (such as REST and JSON), migration to SCIM will be easier as compared to typical on-premises applications.

3 Some of the concepts from WS-Provisioning were fed into the SPML 2.0 standard definition process.


5

Figure 1 illustrates the two components of SCIM: the SCIM service provider and the SCIM consumer. User and group objects are

called resources (see Resources, Methods and Operations). The consumer requests that the provider add, delete and modify user

identities. The provider performs the requested operations and sends back a response with the outcome (success, failure, user and/or

group attributes). The consumer can also search for identity information to make runtime authorization decisions (for example).

The provider is almost always coupled to a single identity store.

In rare cases (perhaps more in the future), providers can function as a proxy to support multiple identity stores (Figure 2). In this

case, the consumer communicates with the provider via SCIM, and the provider provisions users to multiple identity stores.

SCIM COMPONENTS

Figure 1. Core SCIM components

Figure 2. SCIM service with provider functioning as proxy

SCIM CONSUMER

SCIM SERVICE PROVIDER

SAAS APPLICATION

USER ATTRIBUTES

SAAS APPLICATION

USER ATTRIBUTES

SAAS APPLICATION

USER ATTRIBUTES

SCIM

SCIM CONSUMER

SCIM SERVICE PROVIDER

REQUEST(ADD, DELETE, MODIFY)

RESPONSE


6

The SCIM protocol supports many different provisioning use cases. This section explores three popular use cases: workforce

to cloud, partner to partner and IDaaS provisioning.

SCIM provisioning services are frequently built into an identity bridge, an on-premises gateway that seamlessly connects users,

applications and identity management functions across the hybrid cloud. Its goal is to overcome the “impedance mismatch”

between identity 1.0 services — like LDAP, Kerberos and web access management — and to provide services for partner- and SaaS-

based applications. Identity bridges may be bi-directional, allowing the workforce to access SaaS applications and providing

partner access to on-premises applications.

The identity bridge may be standalone with a dedicated administration console. It may also be coupled to an IDaaS, which

provides the SaaS-based administration console. Large organizations with users and applications across the hybrid cloud will

likely need an identity bridge.4

WORKFORCE TO CLOUDThe workforce to cloud use case combines SCIM consumer and federation IDP services to manage the user at “admintime”

and to provide authentication and SSO services at runtime (Figure 4). In most cases, the identity bridge also leverages a directory

synchronization service to monitor for user changes (for example, group membership, new attribute, organizational unit branch),

which trigger the user provisioning event in the SaaS application. SCIM consumer and directory synchronization allow the

organization to extend its identity management functions to SaaS applications without additional provisioning connectors.

The user provisioning flow has the following steps:

• The user is created/modified in the directory with the appropriate group membership or user attribute for

access to the SaaS application.

• The directory synchronization service detects the user event.

The SCIM consumer creates the user in the SaaS application. The user authentication flow includes the following milestones:

• The user authenticates to an Active Directory-bound Windows workstation.

• The user authenticates via Kerberos SSO to federation IDP.

• Federation IDP redirects the user to the SaaS application with SAML credentials.

• The user authenticates via SAML SSO to the SaaS application.

USE CASES

4 For more information on identity bridges and IDaaS, please see the PICK YOUR BRIDGE WHITE PAPER


7

PARTNER TO PARTNERPartner access requirements are increasing and they introduce user management, authentication and complexities. Using

standards-based services like SCIM and SAML, partners can enable access to on-premises resources (Figure 4). The process

starts out the same as the workforce to cloud use case. Instead of the identity bridge connecting to the SaaS application, it

connects to the partner’s identity bridge, which translates the SCIM provisioning request into a user management call to Active

Directory. The second partner’s identity bridge also translates the user SAML authentication to credentials understood by the

local on-premises application such as WAM cookies.

In Figure 4, SAML is speci ed as the federation protocol. In the future, the identity bridge could include an OpenID Connect

provider that issues OAuth-based ID tokens for mobile device-based access to SaaS applications with optional X.509 certi cate

authentication.

Figure 3. Workforce to cloud SCIM use case

Figure 4. Partner to partner provisioning and SSO

FEDERATEDSSO

AUTHORIZATIONQUERY

PARTNERONE

PARTNERTWO

SCIM CONSUMERFEDERATION IDP

ACTIVE DIRECTORY ACTIVE DIRECTORY

IDENTITY BRIDGE IDENTITY BRIDGE

SCIM PROVIDERFEDERATION IDP

SCIM

EMPLOYEE

EXTERNALLY HOSTED

ON PREMISES

KERBEROS SSO DIRECTORY SYNC

ACTIVE DIRECTORY

SAAS APPLICATION

USER ATTRIBUTES

SCIM CONSUMERDIRECTORY

SYNCHONIZATIONFEDERATION IDP

SCIM PROVIDERFEDERATION SP


8

IDAAS PROVISIONINGMany organizations are turning to SaaS applications, which provide deployment elasticity, reduce complexity and

infrastructure costs, and deliver better service levels. IT teams want to adopt SaaS for identity management — called identity

management as a service (IDaaS). One particular identity service that is ripe for IDaaS is provisioning, due to

the complexity and high cost of traditional provisioning systems (Figure 5). In this case, the identity bridge translates SCIM

requests to on-premises identity 1.0 protocols like LDAP and proprietary APIs. The identity bridges also perform the reconciliation

process comparing identities in target applications to the identities in in the SaaS-based authoritative identity store without

replicating the target application identities in the IDaaS. The use of the SCIM and SAML standards allow identity bridges

from different vendors to interoperate.

Figure 5. IDAAS provisioning

IDENTITY BRIDGESCIM PROVIDER

PROVISIONING IDAAS

ACTIVE DIRECTORYERP MANUFACTURING

IDENTITY BRIDGESCIM PROVIDER

ACTIVE DIRECTORY

EXTERNALLY HOSTED

ON PREMISES


9

PROTOCOL OVERVIEW

This section provides an overview of the SCIM provisioning speci cation, including componentry, API framework,

authentication mechanisms, resources, operations and schema.

AUTHENTICATIONSCIM supports several authentication methods for the authentication of consumers to service providers. These methods

include: basic (username/password), OAuth bearer token and X.509 certificate. Regardless of the consumer authentication

method, SSL/TLS is required between the consumer and provider. The use of SSL/TLS is the de facto implementation for

authenticating the provider.

Salesforce Identity (generally available in October of 2013) was the first commercial SCIM provider to require OAuth. Prior

to Salesforce Identity, most commercial SCIM implementations used basic authentication. Many vendors are adding OAuth

authorization server authentication to their products. OAuth authentication introduces an additional authentication step for

the consumer, as it must first authenticate to the OAuth authorization service to procure the necessary bearer token.

As of the publish date, SCIM does not support user authentication—consumers can set a user password, but they

cannot validate it. However, several members of the SCIM IETF working group have proposed a user authentication feature.

If implemented, SCIM would support runtime user authentication.

MODERN API FRAMEWORKSCIM has a modern API framework, leveraging REST for its request/response framework and JSON5 for its data format.

REST and JSON appeal to developers because of their relatively low complexity, and because they are the basis for newer

identity protocols like OAuth, OpenID Connect and FIDO. Additionally, most of the proprietary identity management APIs

provided by SaaS applications today leverage REST and JSON.

RESOURCES, METHODS AND OPERATIONSUser and group objects are called resources in SCIM. The SCIM consumer searches for specific resources via that resource’s

endpoint. This section includes examples of search, delete, create and modify operations of user resources to illustrate the

relationship between resources and endpoints. Table 1 summarizes the methods for the user and group resources6. Many

SaaS vendors have implemented an identity management interface with Windows Azure Active Directory and StormPath.

Their implementations share similarities with SCIM, including the use of REST and JSON, and the common HTTP methods

for create, modify, delete and retrieve operations.

5 SCIM v1 originally supported both XML and JSON. XML support since has been removed.

6 For clarity, other SCIM endpoints like ServiceProviderCon gs, Schemas and Bulk are not speci ed in the table.


10

RETRIEVE AND DELETE OPERATIONSBecause they do not require a JSON payload, SCIM operations like retrieve and delete are relatively simple. In the examples

below, the SCIM provider will return a 200 HTTP status code if the response is successful.

• GET https://pingidentity.com:8443/Users – returns all7 of the users.

• GET https://pingidentity.com:8443/Users? lter=externalId eq “tstark86753”8 – returns information about one user.

• GET https://pingidentity.com:8443/.search” – returns multiple resource types (e.g., user and group) stored by the provider.

The “server root” search type is new in SCIM 2.0.

• DELETE https://pingidentity.com:8443/Users/b0ff6208-bc82-37209 – deletes one user.

CREATE AND MODIFY OPERATIONSCreate and modify requests require a JSON attribute payload, which contains the object attributes (the user’s username and email

address). Figure 6 is an example of a SCIM request to create a user.

RESOURCE ENDPOINT METHOD OPERATION DESCRIPTION

USER /USERS GET RETRIEVE RETRIEVE SINGLE OR MULTIPE USERS

POST CREATE

PUT MODIFY DEFAULT OPERATION FOR MODIFY. REQUIRES ALL USER

ATTRIBUTES IN THE REQUEST.

PATCH MODIFY OPTIONAL OPERATION. REQUIRES ONLY MODIEFIED

ATTRIBUTES IN THE REQUEST.

DELETE DELETE

GROUP /GROUPS GET RETRIEVE

POST MODIFY DEFAULT OPERATION FOR MODIFY. REQUIRES THE LIST OF

ALL VALID ID(S) THAT HAVE GROUP MEMBERSHIPS

PATCH MODIFY OPTIONAL OPERATION - MAY NOT BE SUPPORTED. REQUIRES

ONLY THE ID(S) FOR CHANGES (E.G. GROUP MEMBERSHIPS

DELETE DELETE

Table 1. Summary of SCIM operations for users and groups

7 If the search returns an excessive number of objects, the server may opt to return a subset of objects via pagination, or return an HTTP status code of 403

due to a potentially excessive number of objects in the response.

8 This request would need URL-encoding prior to submission. This request would go over the wire as GET https://pingidentity. com:8443/Users?

lter=externalId%20eq%20%22NA-MarkDiodati369636%22”

9 URL-encoded as https://pingidentity.com:8443/Users/externalId%3Dtstark86753


11

If the create user request is successful, the SCIM provider will return an HTTP response of 201, the URL of the new user,

and user’s attributes. If unsuccessful, the SCIM provider will return an HTTP 4xx consumer or 5xx provider error10. The most

common SCIM error for a user create request is the speci cation of the wrong user attributes (e.g., too many, too few or misspelled)

by the consumer.

RETRIEVE AND DELETE OPERATIONSAs shown in Table 1, SCIM supports two different operations for modify: PUT (required) and PATCH (optional). PUT places more

burden on the consumer, as it must specify ALL of the user’s attributes in the request regardless of the number of modified

attributes. The PUT operation is a de-facto recreation of the user without resetting the user’s password. The optional PATCH

operation is a surgical update; the consumer need only provide the attributes that require modi cation. It places greater burden on the

provider because it must selectively update a subset of the object’s attributes. Few SCIM implementations today support PATCH.

Over time, PATCH will be required for many implementations because the management of group memberships is too challenging.

SCHEMASince its inception, SCIM has provided two optional core schemas, one for users and one for groups. For some organizations

with extensive attribute requirements, the core user schema may not be appropriate. The user schema may be very valuable

to SaaS vendors building a new provisioning service, as well as end-user organizations looking for an inetorgperson-like set of

attributes for use across applications. A standard schema reduces the need to map attributes among SCIM consumers, SCIM

providers, and identity stores. The core user schema also includes an optional extension for enterprise identity attributes like

employeeNumber, costCenter, and manager.

FIGURE 6. EXAMPLE SCIM REQUEST (CREATE USER)

10 Interested in SCIM error codes? You can find them at http://tools.ietf.org/html/draft-ietf-scim-api-01, page 45.


12

Ping Identity hosted a SCIM interoperability event at its 2013 Cloud Identity Summit. Vendors at SCIM’s forefront participated—

including Cisco, Nexus, Ping Identity, Salesforce, UnboundID, SailPoint and WSO2. As the speci cation for SCIM 2.0 was less than

three months old, the event focused on SCIM 1.1 interoperability. The results are summarized in Table 2; grey items with a “Y”

show conformance with the interop test.

The interoperability test was designed to test all of the possible operational aspects of a provisioning service based upon

SCIM operations. Each vendor’s product is unique and provides different functionality; conformance across all of the tests is

not required to each item. Three conclusive trends result from the interoperability event:

• SEARCH CAPABILITY IS SPECIALIZED. Each product supported a subset of search capabilities that were just

enough to satisfy its requirements. In the future, it is unlikely that each SCIM provisioning service will support all

permutations of the search capability for users and group resources. Further, some SCIM consumers may never

support search operations as their primary purpose is syncing identities across identity stores.

• GROUP MANAGEMENT CAPABILITY IS EVOLVING. Some interop participants supported group resources. As

SaaS-based applications continue to mature, the requirement for an abstraction layer between users and

entitlements (that is to say, groups) will increase.

• BULK CAPABILITY IS NOT UNIVERSALLY REQUIRED. The SCIM bulk operations are not unnecessarily

complex, but they do raise the technical bar on the implementation of a provisioning service. Not all

provisioning services need the SCIM bulk capability, and some applications deliver bulk capabilities via

other mechanisms (such as a CSV or LDIF file upload).

CLOUD IDENTITY SUMMIT 2013 INTEROP RESULTS

Table 2. Results of CIS 2013 SCIM interoperability test


13

SCIM, OAUTH AND OPENID CONNECTAs modern identity protocols, SCIM, OAuth 2.0 and OpenID Connect 1.0 share a common request/response framework and

data format—REST and JSON. The identity protocols may be combined synergistically.

OAUTHOAuth is primarily an access delegation protocol, enabling a client to access API resources on behalf of the user. Today,

SCIM supports access via the OAuth bearer token. Over time, most SCIM consumers will pick up the ability to authenticate

(on behalf of the service user) to an OAuth authorization service to procure the bearer token.

OPENID CONNECTOpenID Connect (OIDC) builds upon OAuth to deliver a broader framework for the trust of users and applications at greater

scale. As of the publishing of this document, the speci cations for OIDC are completed and in the final review stage. Google,

Salesforce and Microsoft have announced support for the protocol. As with the OAuth authorization service, the OIDC identity

provider can issue OAuth bearer tokens for the authentication of the SCIM consumer to the service provider.

OIDC provides something akin to the SCIM service provider. The OIDC user information endpoint (UserInfo endpoint)

is a read-only interface where an API client can retrieve user attributes for session personalization. While the protocols for

accessing these components are different, there is nothing that prevents the SCIM provider and the OIDC UserInfo endpoint

from sharing the same identity repository. Over time—if both SCIM and OIDC become widely deployed—the OIDC UserInfo

endpoint and SCIM service provider may become more tightly integrated.


14

SaaS providers and enterprises should evaluate the following design considerations when creating provisioning services based upon SCIM.

CONSUMER ENCODING/DECODINGAs discussed in the Resources, Methods and Operations section, SCIM consumers must perform two types of encoding with SCIM:

URL and JSON. Table 3 summarizes the required encoding and decoding requirements for a SCIM consumer.

SERVICE DESIGNCONSIDERATIONS

REQUEST

Consumer encodes to JSON for POST, PUT, and PATCH

(i.e., creations and modifications)

Consumer must URI-encode search filters for GET (retrievals).

These are appended at the end of the Resource URI

JSON

URL

RESPONSE

Consumers decodes JSON for update to local

identity store.

N/A

PROVIDER MULTI-TENANCYMulti-tenancy is important for SaaS applications, but many already provide multi-tenancy capabilities independent of the identity

management API. Multi-tenancy is optional in the SCIM speci cations. Further, the SCIM IETF has not prescribed how multi-tenancy

should be implemented. However, the SCIM 2.0 speci cation provides some examples of how multi-tenancy may be implemented

within SCIM.

• CREATE A SUBDOMAIN. The resource URLs are modi ed (for example, https://{tenant_id}/ pingidentity.com/

Users) to support multi-tenancy by inserting a tenant ID. The subdomain approach to multi-tenancy requires

changes to both consumer and provider, but it may provide a simpler architecture for the provider as it

supports a single namespace across all resources. Subdomains do not require extensive changes to the

consumer save the insertion of the tenant ID into the URL.

• SET A SCIM_TENANT_ID HTTP HEADER. The consumer sets the HTTP header in the REST request and the provider

maps the header to a localized tenant. The bene t of setting the HTTP header is that it does not require extensive

changes to the consumer—the resource URLs remain unchanged. The use of the HTTP header places additional

processing burden on the provider because it must map the HTTP header to a tenant and associated resources.

• MAP CONSUMER AUTHENTICATION TO A TENANT. The provider infers the tenant from the authentication of

the consumer, and maps the tenancy to local resources. The benefit of this approach is absolute transparency

to the consumer as it need not understand multi-tenancy concepts. The provider makes tenancy decision based

upon identification of the consumer. Authentication mapping places more of a burden on the service provider

(as compared to the consumer) because it must map each request to a local set of resources.


15

BACKWARD COMPATIBILITYThe IETF approved SCIM 1.1 in 2012. Few changes existed between the pre-IETF 1.0 and post- IETF 1.1 version; application providers

and enterprises began developing provisioning services with the standard. The 2.0 speci cation was first published in April of 2013 and

has fundamental changes, which preclude 1.1 and 2.0 components from interoperating. Organizations seeking interoperability between

1.1 consumers and 2.0 providers have two practical approaches. The first is building multi-protocol capabilities in the SCIM provider.

The provider can accept requests from both 1.1 and 2.0 consumers, typically via a unique URL structure (https://pingidentity.com/

v1/Users). Second, the SCIM consumer can be modified to support the 1.1 and 2.0 protocols. In most cases, organizations will choose

provider multi-protocol support, because it aligns with SCIM’s goal of keeping things as simple as possible for consumers.

RUNTIME SCIM CONSUMERSAs a provisioning standard built upon REST, every SCIM resource has a unique URL. URL-based resources may place an additional

burden on some consumers—particularly those making runtime authorization decisions. These consumers may not store the URL

and will require performing multiple SCIM operations to search for the resource URL, then for user attributes and group memberships

using the retrieved URLs.

Two approaches can minimize the impact of multiple SCIM operations for runtime identity requests. First, the consumer can store

the SCIM resource URLs to reduce the initial search for the SCIM URL. Second, the SCIM consumer service can be decoupled from the

authorization service. The consumer periodically syncs the identity information from the SCIM provider to a local identity store;

the authorization retrieves the necessary information from the local identity store at runtime.

SSO isn’t possible without user provisioning. Traditional provisioning systems have struggled to scalably manage identities

due to the diversity of applications. The lack of a standard user schema hasn’t helped. SCIM overcomes both issues and has

seen adoption among application vendors—a milestone that prior provisioning standards failed to achieve. SCIM’s ultimate

success depends upon SaaS vendors leveraging the protocol.

#3116 | 07.16 | v002

ABOUT PING IDENTITY: Ping Identity leads a new era of digital enterprise freedom, ensuring seamless, secure access for every user to all applications across the hyper-connected, open digital enterprise. Protecting over one billion identities worldwide, more than half of the Fortune 100, including Boeing, Cisco, Disney, GE, Kraft Foods, TIAA-CREF and Walgreens trust Ping Identity to solve modern enterprise security challenges created by their use of cloud, mobile, APIs and IoT. Visit pingidentity.com. 16

An on-premises gateway that connects users, applications and identity management functions across the hybrid cloud. The identity bridge may be standalone, with a specific administration console; or it may also be coupled to an IDaaS, which provides the management capability.

Identity management as a service. A turnkey, externally-hosted SaaS application that performs identity management functions. Examples include provisioning, stronger authentication and SSO.

JavaScript Object Notation. A data format to represent name value pairs. JSON supports hierarchical structures and complex data types.

Lightweight Directory Access Protocol. The default standard for enterprise-based directory services.

Representational State Transfer. A request-response framework for APIs that leverages HTTP conventions, including its methods (GET, POST, DELETE) and URLs to uniquely identify objects. The widespread adoption of REST was partially in response to the complexity of SOAP. While REST supports other data formats like XML, it is typically used with REST.

System for Cross-Domain Identity Management. A provisioning speci cation that leverages REST, JSON and several different authentication methods to add, delete and modify users in target applications. When conceived at the 2010 Cloud Identity Summit, the speci cation was named Simple Cloud Identity Management. After the speci cation moved to the IETF working group in July of 2012, the name changed to System for Cross-Domain Identity Management.

Service Provisioning Markup Language. SPML is a predecessor of SCIM, which relied upon SOAP and XML. The first version of the standard was approved by OASIS in 2003, and the approval of the second version was in 2005.

An application that is the destination of provisioning. In most cases, the SCIM service provider and the target application are the same. In rare cases, the target application may be one of many applications behind a SCIM service provider proxy.

IDENTITYBRIDGE

IDAAS

JSON

LDAP

REST

SCIM

SPML

TARGET APPLICATION

a primer on the system for cross domain · pdf filea primer on the system ... particularly...

Documents