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