**MACE-Dir Call 27-June-2011**
*** Changing call time ***
There was a proposal to change the time to an hour later, to better accommodate both west coast and EU participants, i.e. every other Monday at Noon ET.
**Attending**
Keith Hazelton, U. Wisconsin - Madison (co-chair)
Mark Scheible, MCNC
Chris Phillips, CANARIE
David Bantz, U. Alaska - Fairbanks
Scott Cantor, The Ohio State U.
Michael Pelikan, Penn State U.
Jim Leous, Penn State U.
Jimmy Vuccolo, Penn State U.
Bill Weems, UT-Houston
Steve Olshansky, Internet2 (scribe)
**Next call: July 11, 2011 Noon EDT (GMT-4)
(NOTE: All future calls will be at Noon ET)
PIN: 0179884#
**Carryover Action Items**
[AI] (All) discuss feedback or concerns about revised EPTID text on the mailing list.
[AI] (RL "Bob) will distribute information about the UW person registry web service.
[AI] (Keith) will draft a problem statement on person and organization identifiers from social IdPs related to VOs, as a discussion starter, and will refer to IPEDS for reference.
[AI] (Brendan) will distribute some reference materials related to person and organization identifiers from PESC.
[AI] (Keith) will send a discussion starter on the use of eduCourse to the mailing list.
[AI] (Keith) will issue a last call for eduPerson edits, beyond EPTID revisions, for inclusion in a forthcoming revision.
[AI] (Keith) will develop a Bamboo use case for persistent identifiers.
[AI] (Keith) will write up the current state of the identifier discussion and apparent consensus, and associated explanatory material, for use by REFEDs.
[AI] (Keith) will edit the previous versions of the SAML Attribute Profiles documents to note that they have been superseded by a newer
version:
http://docs.oasis-open.org/security/saml/SpecDrafts-Post2.0/sstc-saml-attribute-x500-cd-01.pdf
http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200604.pdf
http://middleware.internet2.edu/dir/docs/draft-internet2-mace-dir-saml-attributes-20071202.pdf
http://middleware.internet2.edu/dir/docs/internet2-mace-dir-saml-attributes-200804.pdf
http://wiki.oasis-open.org/security/SstcSaml2AttributeX500Profile
http://www.oasis-open.org/committees/download.php/28042/sstc-saml-attribute-x500-cs-01.pdf
See also:
http://www.edugain.org/policy/edugain_policy_build20110124/attribute_profile_20101215.pdf
[AI] (RL "Bob") will query the REFEDs list about whether identifier reassignability is an issue for them esp. in grid environments.
[AI] (Keith) will take a first pass at revving http://middleware.internet2.edu/dir/docs/internet2-mace-dir-ldap-group-membership-200507.html in the wiki, then run it by the group for comment, with the goal of perhaps finalizing it in the near future.
[AI] (Brendan) will poll the mailing list for feedback on the use of name fields, and whether they have had the need to extend eduPerson locally with additional name fields.
**Discussion**
1. Simple Cloud Identity Management (SCIM) the face of federated provisioning? (Chris Phillips)
It was proposed that MACE-Dir could play a useful role in this work...
https://spaces.internet2.edu/display/macedir/Simple+Cloud+Identity+Management-SCIM
Chris' slides at http://slidesha.re/myQavX
SCIM was originally advertised as "LDAP in the cloud" but this may be somewhat simplistic...
Emerging Themes
- Intention
-- designed to make managing 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, 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. If you have suggestions for inclusion now is the time... This will likely end up under IETF rather than OASIS.
One view of SCIM (see Chris' diagram on slide 4)
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
Q: How does the concept of "role" fit into this, e.g. assigning roles to groups?
A: Roles (as a collection of entitlements) are in there, but assigning roles to groups has not yet been addressed. Some roles are not map-able to groups, e.g. "auditor." Group memberships, roles, and entitlements need to be handled, likely as optional attributes.
[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
[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.
-- 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?
- Licensing is OWF (Open Web Foundation)
-- Cisco, Ping Identity, Salesforce, unBoundID already signed on
- IETF candidate org for specification submission.
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
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?)
(See Chris' diagram in slide 9)
Other Items
- Coverage is primarily on person provisioning activities and mechanics therein
-- Light coverage on groups
-- No coverage (as of yet) on privacy
- No clear way to move something from ‘an extension’ to ‘core’.
-- 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 ingain 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
- 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 (not-yet-a-)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?
2. eduCourse/psuCourse
Michael will send a link to his slides to the list for comment, and discussion on a future call.