A PRIMER ON THE SYSTEM FOR CROSS DOMAIN IDENTITY MANAGEMENT (SCIM)

MAKING YOUR PROVISIONING PROCESSES SCALABLE FOR THE CLOUD

WHITE PAPER TABLE OF CONTENTS

03 EXECUTIVE OVERVIEW

03 THE CASE FOR SCIM Learning from the Past Positive Indicators

05 SCIM COMPONENTS

06 USE CASES Workforce to Cloud Partner to Partner IDAAS Provisioning

09 PROTOCOL OVERVIEW Authentication Modern API Framework Resources, Methods and Operations Schema

12 CLOUD IDENTITY SUMMIT 2013 INTERLOP RESULTS SCIM, OAuth and OpenID Connect OAuth OpenID Connect

14 SERVICE DESIGN CONSIDERATION Consumer Encoding/Decoding Provider Multi-Tenancy Backward Compatibility Runtime SCIM Consumers

15 CONCLUSION

16 DEFINITIONS 2 WHITE PAPER PRIMER ON SCIM EXECUTIVE OVERVIEW

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.

THE CASE FOR SCIM

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.

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.

3 WHITE PAPER PRIMER ON SCIM LEARNING FROM THE PAST As 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 INDICATORS While 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.

4 WHITE PAPER PRIMER ON SCIM SCIM COMPONENTS

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.

SCIM SERVICE PROVIDER

REQUEST RESPONSE (ADD, DELETE, MODIFY)

SCIM CONSUMER Figure 1. Core SCIM components

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.

SAAS APPLICATION

USER ATTRIBUTES

SAAS APPLICATION SAAS APPLICATION

USER ATTRIBUTES USER ATTRIBUTES

SCIM SERVICE PROVIDER

SCIM

SCIM CONSUMER

Figure 2. SCIM service with provider functioning as proxy 5 WHITE PAPER PRIMER ON SCIM USE CASES

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 CLOUD The 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.

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

6 WHITE PAPER PRIMER ON SCIM 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.

SAAS APPLICATION

USER ATTRIBUTES

SCIM PROVIDER FEDERATION SP

EXTERNALLY HOSTED ON PREMISES

KERBEROS SSO DIRECTORY SYNC

EMPLOYEE SCIM CONSUMER ACTIVE DIRECTORY DIRECTORY SYNCHONIZATION FEDERATION IDP

Figure 3. Workforce to cloud SCIM use case

PARTNER TO PARTNER Partner 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.

PARTNER PARTNER ONE TWO

IDENTITY BRIDGE FEDERATED IDENTITY BRIDGE SSO

AUTHORIZATION QUERY SCIM

SCIM CONSUMER SCIM PROVIDER FEDERATION IDP FEDERATION IDP

ACTIVE DIRECTORY ACTIVE DIRECTORY

Figure 4. Partner to partner provisioning and SSO

7 WHITE PAPER PRIMER ON SCIM IDAAS PROVISIONING Many 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.

PROVISIONING IDAAS

EXTERNALLY HOSTED

ON PREMISES

IDENTITY BRIDGE IDENTITY BRIDGE SCIM PROVIDER SCIM PROVIDER

ERP ACTIVE DIRECTORY MANUFACTURING ACTIVE DIRECTORY

Figure 5. IDAAS provisioning

8 WHITE PAPER PRIMER ON SCIM PROTOCOL OVERVIEW

This section provides an overview of the SCIM provisioning speci cation, including componentry, API framework, authentication mechanisms, resources, operations and schema.

AUTHENTICATION SCIM 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 FRAMEWORK SCIM 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 OPERATIONS User 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.

9 WHITE PAPER PRIMER ON SCIM 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

RETRIEVE AND DELETE OPERATIONS Because 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 OPERATIONS Create 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.

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

10 WHITE PAPER PRIMER ON SCIM FIGURE 6. EXAMPLE SCIM REQUEST (CREATE USER)

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 OPERATIONS As 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.

SCHEMA Since 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.

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

11 WHITE PAPER PRIMER ON SCIM CLOUD IDENTITY SUMMIT 2013 INTEROP RESULTS

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).

Table 2. Results of CIS 2013 SCIM interoperability test

12 WHITE PAPER PRIMER ON SCIM SCIM, OAUTH AND OPENID CONNECT As 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.

OAUTH OAuth 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 CONNECT OpenID 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.

13 WHITE PAPER PRIMER ON SCIM SERVICE DESIGN CONSIDERATIONS

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

CONSUMER ENCODING/DECODING As 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.

REQUEST RESPONSE

Consumer encodes to JSON for POST, PUT, and PATCH Consumers decodes JSON for update to local JSON (i.e., creations and modifications) identity store.

Consumer must URI-encode search filters for GET (retrievals). N/A URL These are appended at the end of the Resource URI

PROVIDER MULTI-TENANCY Multi-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.

14 WHITE PAPER PRIMER ON SCIM BACKWARD COMPATIBILITY The 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 CONSUMERS As 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.

15 WHITE PAPER PRIMER ON SCIM An on-premises gateway that connects users, applications and identity management functions IDENTITY across the hybrid cloud. The identity bridge may be standalone, with a specific administration BRIDGE 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 IDAAS identity management functions. Examples include provisioning, stronger authentication and SSO.

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

LDAP 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. REST 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. SCIM 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 SPML 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 TARGET the target application are the same. In rare cases, the target application may be one of many APPLICATION applications behind a SCIM service provider proxy.

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

#3116 | 07.16 | v002