PINGIDENTITY.

COM
PROVISIONING

Copyright © 2015 Ping Identity Corp. All rights reserved.2

MANAGING IDENTITIES BETWEEN ORGANIZATIONS

§ Accounts need to be synchronized between IdP and

SP
§ Needs to be independent of SSO
I have a new employee that
wants to SSO onto your app!
Identity Provider
SaaS
I don’t have them in my own
Provider
identity store, so I don’t have an Identity
account for them to SSO into Store
Identity
Store

Tell me about the user first

Copyright © 2015 Ping Identity Corp. All rights reserved.3

WE NEED TO BE ABLE TO…
I have a new
employee; here is
his name and email
Identity Provider
I’ll add them to my data SaaS
store. Provider
Identity
Store
Identity Also, employee2
Store
quit.

I’ll delete them from my

datastore so they can’t
access my apps anymore.
USER PROVISIONING WITH SERVICES
Three kinds of user provisioning for browser-based
SSO
– SP side: JIT (Just-in-Time) Provisioning
– IdP side: Outbound Provisioning
– Either side: SCIM (acronym changes often)

Copyright © 2015 Ping Identity Corp. All rights reserved.5

 1. SP: JUST IN TIME PROVISIONING

• Creates accounts on-the-

fly in the Service
Provider’s local directory
› Attributes from incoming
assertion
• No deprovisioning

Copyright © 2015 Ping Identity Corp. All rights reserved.6

2. IDP: OUTBOUND PROVISIONING
§ IdP PingFederate uses a separate database internally
– monitors the state of the user store
§ Includes deprovisioning

Copyright © 2015 Ping Identity Corp. All rights reserved.7

3. BOTH SIDES: SCIM
§ Open
provisioning
standard
SCIM SCIM Service
client Provider
§ REST-based
provisioning
API

§ Platform
neutral – JSON

Copyright © 2015 Ping Identity Corp. All rights reserved.8

SCIM – OUTBOUND PROVISIONING
§ Makes provisioning
requests to the
provider
Identity Provider
SaaS
SCIM Client Provider § Monitors directory
SCIM
Identity
for user account
Create?
Store changes:
Update?
Delete?
– Create
Identity – Update
Store
– Membership Update
– Delete / Disable
SCIM – INBOUND PROVISIONING

§ Handles
inbound user & SaaS
Provider
provisioning Identity Provider
requests SCIM
SCIM Service
Provider

Identity
§ Propagates Identity Store Store

changes to
identity store
SCIM BASICS
§ Take some information • Give an action about that info to another
(schemas) organization
§ Maps from AD/LDAP – GET
– User email (mail) – POST
– Username – PUT
(userPrincipalName)
– DELETE
– cn
SaaS
– sn Identity Provider

– etc Provider Identity

PUT: “Update Bob’s email” Store
User
Directory SCIM Service
SCIM Client
“Okay” Provider

Copyright © 2015 Ping Identity Corp. All rights reserved.11

REST API
§ Everything is relative from a base URL
– “https://serviceprovider.com/scim/”

§ Specifies well-known endpoints and HTTP methods for managing core resources
– User and group resources correspond to /Users and /Groups, respectively
– “https://serviceprovider.com/scim/Users” or
“https://serviceprovider.com/scim/Groups”

§ Standard serializations of the schema using JSON and XML are provided
– Lightweight, platform independent with JSON
– Responses are returned in the body of the HTTP messages in JSON or XML format

Copyright © 2015 Ping Identity Corp. All rights reserved.12

EXAMPLE 1: CREATE USER
§ The SCIM REST API defines the form of the “create user”
message sent from the HR SaaS provider

POST /User HTTP/1.1

Host: saas.com
Content-Type: application/json
Content-Length: ...
{“schemas”:[“urn:scim:schemas:core:1.1”],
“userName”:”bjensen@example.com”,
“name”:
{“familyName”:”Jensen”,
“givenName”:”Barbara”},
“displayName”:”Babs Jensen”,
“emails”:[
{“value”:”bjensen@example.com”,
“type”:”work”,
“primary”:true}]}
POST – create.
Sent to saas.com\User
“Hey SaaS2, create the user below”
We’re using SCIM 1.1 here
“Here’s all the information I
have about the user you need
to create.
Copyright © 2015 Ping Identity Corp. All rights reserved.13
 EXAMPLE 1: CREATE USER
• And the SaaS partner would return an OK response
HTTP/1.1 201 Created
Content-Type: application/json
Location: https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646
ETag: W/"e180ee84f0671b1"
201 – everything is okay
{
"schemas":["urn:scim:schemas:core:1.0"], and the user was created
"id":"2819c223-7f76-453a-919d-413861904646",
"externalId":"bjensen",
"meta":{
"created":"2011-08-01T21:32:44.882Z", I’ve created the user
"lastModified":"2011-08-01T21:32:44.882Z",
"location":"https://example.com/v1/Users/2819c223-7f76-453a-919d-413861904646",
"version":"W\/\"e180ee84f0671b1\""
},
"name":{
"familyName":"Jensen",
"givenName":"Barbara"
}, Here’s what I put about the
"userName":"bjensen"
} user in my local datastore

Copyright © 2015 Ping Identity Corp. All rights reserved.14

EXAMPLE 2: DELETE A USER
Identity Provider An employee was just
fired.

HR Directory
I see the directory has just deleted a
user.
HR SCIM Client SaaS1, you need to delete this user too!

SaaS1
OK!

My access to SaaS1 is gone

DELETE https://sp.com:8443/Users/41209481-3252-141-A214B-14D1

Copyright © 2015 Ping Identity Corp. All rights reserved.15

EXAMPLE 3: GET USER DATA
GET /Users/41209481-3252-141-A214B-14D1
Host: idp.com
Accept: application/json User ID 200 = successful response
“Here’s everything I have on
that user”
GET request = read
“I’d like to know what you
HTTP/1.1 200 OK
have about this user”
Content-Type: application/json
Location: https://sp.com/v1/Users/41209481-3252-
141-A214B-14D1
{ Same User ID
“name”:
{“familyName”:”Jensen”,
“givenName”:”Barbara”},
“displayName”:”Babs Jensen”, Attributes
“emails”:[
{“value”:”bjensen@example.com”,
“type”:”work”,
“primary”:true}]}
 AUTHORIZATION BETWEEN SCIM SERVERS

§ HTTP basic authorization

– base64 encoded in the HTTP request header
POST https://localhost:8080/oxTrust/seam/resource/restv1/Users/
Accept: application/json
Authorization: Basic bWlrZTpzZWNyZXQ=

§ OAuth access tokens (presentations later)

– SCIM consumer gets a token : “I’m allowed to make this
request”
POST https://localhost:8080/oxTrust/seam/resource/restv1/Users/
Accept: application/json
Authorization: Bearer IGrzAFZWNyZXQAf
SUMMARY
Requirement JIT Provisioning Outbound Provisioning SCIM
SP provides just-in-
IdP establishes user IdP establishes user
time access to
Use Case accounts at SP before accounts at SP before
applications
enabling SSO enabling SSO
(No deprovisioning)

Account Data
SSO transaction IdP corporate directory IdP corporate directory
Source

IdP must have SAML-

Other Party Service Provider must Must support SCIM
based Internet SSO
Requirement have a provisioning API standard
solution
Target
Proprietary
Directory/Interfa LDAP, JDBC REST API / JSON
implementation
ce Supported

Copyright © 2015 Ping Identity Corp. All rights reserved.18

TECHNICAL DETAILS – REFERENCE
SLIDES

Copyright © 2015 Ping Identity Corp. All rights reserved.19

THE INDUSTRY HAS TRIED TO DO
PROPRIETARY PROVISIONING…

Pros Cons
Manual No additional configuration. Doesn't scale.

Simple when only a handful Tedious for administrators.

of users to a single app are
involved. Error prone.
Just-In-Time Single protocol for both SSO Doesn't handle de-
and Provisioning provisioning use case.
Automated Covers both provisioning and Implemented differently for
(proprietary) de-provisioning every partner.

…But there was no standard

SCIM SCHEMAS
§ Schemas – what sorts of resources we can play with
– Basic schema
› Maps from Active Directory – mail, userPrincipalName, sn, cn, whenCreated…
“I have a new user, Bob..”

– Group schema
› Contain members, influencing group- and role- based access control. “Add
Bob to the manager group..”

– The schema is extensible – can add, say, Enterprise schema

› Manager, department, organization…“Bob’s manager is Alice”
› Others can be added at will – similar to auxiliary object classes in LDAP
BASIC SCHEMA MAPS FROM ACTIVE
DIRECTORY

Active Directory SCIM

userPrincipalName userName
mail email.value@type=work
givenName name.givenName
sn name.familyName
whenCreated meta.whenCreated
userPassword password
cn displayName
SCIM USER SCHEMA
User Attribute Attribute Type Required?

userName Single Yes

name Complex No
displayName Single No
nickName Single No
profileUrl Single No
title Single No
userType Single No
preferredLanguage Single No

locale Single No
timezone Single No
active Single No
password Single No
emails Multi No
phoneNumbers Multi No
ims Multi No
photos Multi No
addresses Complex, Multi No
groups Multi No
entitlements Multi No
roles Multi No
x509 Certificates Multi No
SCHEMA - GROUPS
§ Group resources enable group- and role- based access
control
§ Groups contain members
§ How SP implements access control out of scope
PATCH /Groups/abe73-727ef
Host: example.com
Accept: application/json
Authorization: Bearer 48h74e2cf ETag: W/”a537bc”
{
“schemas”: [“urn:scim:schemas:core:1.0”]
“members”:[
{“display”: “Babs Jensen”,
“value”: “24626efab457be” }]
}
SCHEMA - ENTERPRISE EXTENSION
§ Extends generic user with enterprise semantics
§ Others can be created at will
§ Attributes:
– employeeNumber
– costCenter
– organization
– division
– department
– manager
SCIM CORE SCHEMA (REQUIRED!)
Resource Attribute Sub-Attribute Required? Modifiable? Comment
externalId No No Defined by the consumer at the time of
resource creation – “Stable and non-
reassignable”. May eliminate the need for the
consumer to maintain local mapping of user
resource
id Yes No Defined by the service provider at the time of
resource creation – “stable and non-
reassignable”
meta created No No Included in SCIM response.
lastModified No No Included in SCIM response.
location No No Included in SCIM response. URI of resource (e.g.
“https://yourscim.com:8334/Users/uid-
mdio,ou=people,o=yourscim.com”

version No No Included in SCIM response.

attributes No Yes Attributes to remove from the Resource during
a PATCH operation
resourceType Yes No New in 2.0 to support root search

schemas No No When not using JSON, a schemas attribute is

used to indicate the version of SCIM schema
ALSO:
§ PUT:
– Required for SCIM conformance
– Consumer must provide ALL of the resource attributes
– Service Provider should be smart enough to ignore ID and externalID (read-
only) attributes in the request
§ PATCH
– Optional operation (not required for support)
– Requires only the attribute being modified
– Handy for adding or deleting users from group
– Requires more processing on the service provider side
› Few products support PATCH today
 SUMMARY: SCIM RESOURCES AND METHODS
Resource REST Operation SCIM Operation Comment
Users GET Retrieve Retrieve single or multiple users

POST Create
PUT Modify Default operation for modify. Requires all user attributes in the request.
PATCH Modify Opitional operation. Requires only modified attributes in the request.
DELETE Delete
Groups GET Retrieve
POST Create
PUT Modify Default operation for modify. Requires the list of all valid id(s) that have
group membership
PATCH Modify Optional operation – may not be supported. Requires only the id(s) for
changes (e.g. group membership)
DELETE Delete
ServiceProviderConfigs GET Retreive
Schemas GET Retrieve
Bulk POST Modify Optional operation. Enables the modification of many resources.
Consumer must embed the operation (e.g. POST, PUT, PATCH, DELETE)
for each resource modification. Retrieval of multiple resources is not a
bulk operation (this achieved with a GET on the resource).
 SCHEMA – METADATA
§ To simplify interoperability, SCIM provides two end points to
discover supported features and specific attribute details:

– GET /ServiceProviderConfigs
› Specification compliance, authentication schemes, data models.
– GET /Schemas
› Introspect resources and attribute extensions.
– E.g. “Hi, SCIM Service Provider! What do you support?”
“schemas”:[“um:scim”schema”core”1.0”]
“patch”:{“supported”:true},
“bulk”:,”maxOperations”:1000,”maxPayloadSize”:1048576},
“filter”:{“supported”:true,”maxResults”:200},
“changePassword”:{“supported”:true},
API – RESPONSE CODES
§ Returned by SCIM service provider
– After receiving a SCIM request (“update this user!”)
§ API uses / overrides HTTP Response Codes
– indicates operation success or failure
§ Errors are returned in body of the response and human-
readable explanations
HTTP/1.1 404 NOT FOUND
{
“Errors”:[
{
“description”:”Resource 3525-151-987a-1b-not found”,
“code”:”404”}]
} Copyright © 2015 Ping Identity Corp. All rights reserved.30
API – ERROR CODES
Code Applicability Suggested Explanation

400 BAD REQUEST GET,POST,PUT,PATCH,DELETE Request is unparseable, syntactically incorrect, or violates

schema
401 UNAUTHORIZED GET,POST,PUT,PATCH,DELETE Authorization Failure

403 FORBIDDEN GET,POST,PUT,PATCH,DELETE Server does not support requested operation

404 NOT FOUND GET,PUT,PATCH,DELETE Specified resource, e.g. User, does not exist

409 CONFLICT PUT,PATCH,DELETE The specified version number does not match the resource’s
latest version number or a Service Provider refused to create
a new, duplicate resource

412 PRECONDITION FAILED PUT,PATCH,DELETE Failed to update as Resource {id} changed on the server last
retrieved
413 REQUEST ENTITY TOO POST {“maxOperations”:1000,”maxPayload”:1048576}
LARGE
500 INTERNAL SERVER GET,POST,PUT,PATCH,DELETE An internal error. Implementers SHOULD provide descriptive
ERROR debugging advice
501 NOT IMPLEMENTED GET,POST,PUT,PATCH,DELETE Service Provider does not support the request operation
SCIM HAS SOME HISTORY…
§ Started at Cloud Identity Summit 2010

§ Google, Salesforce, Ping Identity, UnboundID, Microsoft,

Sailpoint, etc…

§ SCIM 1.1 is the version the industry currently uses

– Drafted, tested, and released in 2011
– 1.0 deprecated
– 2.0 developed Spring 2013, still in stages, to be finished 2014
ENTERPRISE RECOMMENDATIONS
§ Wait before developing internal provisioning services until the 2.0 spec is farther
along
– 2.0 spec still evolving and likely not backward compatible with 1.1
§ If backward compatability with 1.1 consumers is required, then your service
provider must be smart enough to handle both versions of the protocol
– Consumers can be directed to different endpoints
› https://yourscim.com/V1/Users

› https://yourscim.com/V2/Users

§ Or don’t do internal development:

– SCIM adoption by on-premise applications will be slower
– Leverage products that use SCIM (whatever revision) to connect to SaaS applications
SUMMARY - SCIM
• Specification designed to simplify cloud-based identity management
• Makes it more convenient and cost-effective for users to move into, out of
and around the Cloud
• Builds upon SaaS provider and enterprise customer experience with existing
proprietary mechanisms
• Places specific emphasis on simplicity of development and integration
• Applies existing authentication, authorization, and privacy models.
• Provides
• A common user schema and extension model,
• Binding documents to provide patterns for exchanging this schema using
standard protocols
PINGIDENTITY.COM