SCIM is intended to simplify user provisioning across cloud applications and services by defining a common schema and RESTful API for exchanging user identity data. The schema is based on existing standards and aims to balance a core set of common attributes with extensibility. While the protocol focuses on the mechanics of provisioning user accounts, it does not fully address related issues like group management, privacy, governance of the core schema, or best practices for provisioning workflows. Implementing SCIM brings the benefits of a standardized protocol but still requires intelligence and logic within applications to fully enable user provisioning capabilities.

1. SCIM:
a participants perspective & briefing
for MACE-DIR
June 27, 2011 - Chris Phillips – chris.phillips@canarie.ca
Refreshed & presented at Oct 3 I2FMM
differences in red with addt’n of slide 4

2. Emerging Themes
• Intention
– designed to make managing (read: provisioning )user identity
in cloud based applications and services easier
• How
– to build upon experience with existing schemas and
deployments
– Intentional simplicity of development and integration
– Based on authentication, authorization, and privacy models
• Provides/ intended delivery of
– a common user schema and extension model
– patterns for exchanging this schema using standard protocols
– fast, cheap, and easy to move users in to, out of (not too
sophisticated), and around the cloud.

3. Why?
• Stating the obvious: Everyone provisions
differently in absence of a standard $$$
– Fix this with some consistent way doing it, and it
will get easier to integrate with each other.
– Note that if only a handful of high volume
commercial service providers participate, it will
pay for itself (for them) through reduced
complexity of interacting.
– Schema definition is still fluid if sufficient use
cases can present & defend their inclusion

4. The 4 minute diagram
User Admin
API
Interface Interface
LDAP
Person Registry
‘Connectors’ AD
To resources SSO
Workflow Engine ( aka EC2
Applications
SCIM ) Vendor X
Persistent datastore
App Y

5. One view of SCIM

6. Schema
• Schema appears to have started from portable contracts schema[1] (as seen in
references)
– Some pieces derived from participants needs
• Handles a variety of attribute types (see [2]):
– Single valued, multivalued (term: Plural), and complex types
• Intriguing technique -- allows for significant flexibility,
• Me: introduces complexity under the hood about mapping that implementers will have to come
to terms with
• Philosophical Approach: a core plus extensions
– Partitions customizations much like LDAP schema extensions
– Observations: I see an 80/20 challenge. Will 80% of the value exist in the extensions
or the core schema?
• Me: I’m a proponent of having a strong core to avoid having the real game played in the
extensions
– Boil the ocean problem to define a universal schema? Maybe, maybe not. if the core has sufficient
useful attributes it will do better. ‘Roles’ and ‘Entitlements’ have been proposed and appear on their
way into the core.
– Missing/TBD: no clear way how core is governed and updated – yet
• [1] http://www.portablecontacts.net/draft-schema.html
• [2] http://www.simplecloud.info/specs/draft-scim-core-schema-01.html

7. Deployment inputs
• See scenarios doc [1]
• Tom Zeller’s lightning talk[2] depicts the
situations/user stories quite nicely:
– Plots discussions regarding SPML, SAML, and SCIM,
against LDAP
• UPDATE: I propose SCIM is something that has
noticeable utility for the protocol for provisioning.
– Discussion/thoughts?
• [1] http://www.simplecloud.info/specs/draft-scim-scenarios-03.html
• [2] https://spaces.internet2.edu/display/ACAMPIdSummit2011/Lightning+Talk+Topics+and+Slides

8. Timing & licensing
• Desired completion time on SPEC design is about Fall
2011 for IIW – looks likely
• Some are implementing as the spec evolves so early adopter
code will be available as of 1.0 intro
– map SCIM to inetOrgPerson in LDAP?
– UPDATE: Unboundid has an SDK:
» http://www.unboundid.com/blog/2011/07/26/the-unboundid-
scim-sdk/
• Licensing is OWF (Open Web Foundation)
• Cisco, Ping Identity, Salesforce, unBoundID already signed on
• CANARIE signed on as a formal way to contribute from higher ed
• IETF candidate org for specification submission. 
debating

9. How Adaptable is this?
• Will this concept be adaptable to other
environments ?
• I believe so, but YMMV.
– Me: Push for key items to be in the core the best foot
forward, otherwise you are always playing in
extensions (good/bad?)
– Participate and ye shall have opportunity to advocate
a position
• Participants are receptive. Proposal to include 2 additional
attributes – ‘Roles’ and ‘Entitlements’ in progress and
appears to be on track
• Both are in ‘core’ and not extensions

10. Is Simple Really Simple?
• RESTful API calls- keeps it simple & lightweight
• Me: this is the SPML is too big value proposition. It will
be more simple than SPML….but hard to escape
complexity of hard problems.
• Still have deal with what happens when the
method is invoked on either end:
• How well it happens here is going to make or break you
(use XACML? How much intelligence? How portable?)

11. Other Items
• Coverage is primarily on person provisioning
activities and mechanics therein
– Light coverage on groups  Grouper win
– No coverage (as of yet) on privacy
• No clear way to move something from ‘an
extension’ to ‘core’.  Governance challenge
– If the features of the mechanisms are all you care
about, then stick to exclusively extensions – is this
a bad design pattern? Maybe.

12. Parting Thoughts
• SCIM has an opportunity to simplify the provisioning experience and gain
consistency
• Lots of room for activity on schema to strengthen it
– Will require more diversity of opinion/participants as to what is important to be in
core in 1.0 UPDATE: we have roles+entitlments so core elements..
• Mechanics of the RESTful API will be very useful, but complexity and heavy logic
lurk beneath the surface at the API boundary on either end.
– These lie outside the scope of the protocol about the implementation.
– Question: Compare the Shibboleth IdP/SP software are endpoints for the SAML
protocol. How similar (or not) will the experience building endpoints for SCIM
protocol?
– Provocative statement: Just in Time provisioning ALREADY happens in SPs over SAML.
Is it such a stretch to invoke the key person object operations over SAML and have a
special add on for provisioning via Shibboleth (e.g. be an extension like ECP?)
• If one adopts SCIM, you gain a protocol, but doesn’t address all the best
practices/’right way’ to do provisioning/deprovisioning. Still need the
intelligence in there somewhere.
• What are your thoughts?
• Interesting Q: will OS4HeIDM use SCIM as a provisioning model? Me: yes