SCIM: a participants perspective & briefing for MACE-

DIR

June 27, 2011 - Chris Phillips – chris.phillips@canarie.caRefreshed & presented at Oct 3 I2FMMdifferences in red with addt’n of slide 4

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.

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

Person Registry

User Interface

‘Connectors’To resources

( akaSCIM )

Workflow Engine

Persistent datastore

Admin Interface API

SSO

Applications

LDAP

AD

The 4 minute diagram

EC2

Vendor X

App Y

One view of SCIM

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

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

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

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

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

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.

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