a primer on the system for cross domain · pdf filea primer on the system ... particularly...
TRANSCRIPT
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
PRIMER ON SCIMWHITE PAPER
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.
PRIMER ON SCIMWHITE PAPER
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.
PRIMER ON SCIMWHITE PAPER
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
PRIMER ON SCIMWHITE PAPER
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
PRIMER ON SCIMWHITE 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
PRIMER ON SCIMWHITE PAPER
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
PRIMER ON SCIMWHITE PAPER
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.
PRIMER ON SCIMWHITE PAPER
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
PRIMER ON SCIMWHITE PAPER
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.
PRIMER ON SCIMWHITE PAPER
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
PRIMER ON SCIMWHITE PAPER
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.
PRIMER ON SCIMWHITE PAPER
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.
PRIMER ON SCIMWHITE PAPER
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