Subject: [scim] Thoughts on SCIM WG charter

From: Phil Hunt <[email-masked]>
Date: Wed, 14 Mar 2012 14:44:43 -0700

In previous emails, I promised more thoughts on the Gateway/targeting issue. In order to support the scope discussion, I put a bunch of thoughts together on areas the WG might consider on my blog at:
http://www.independentid.com/2012/03/scim-what-should-new-scim-wg-address.html

I'm still planning to post more info to the list on the specific issue of "gatewayed" provisioning (aka targeting).

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Mar 2012 16:28:50 -0600

<hat type='AD'/>

On 3/14/12 3:44 PM, Phil Hunt wrote:
> In previous emails, I promised more thoughts on the Gateway/targeting
> issue. In order to support the scope discussion, I put a bunch of
> thoughts together on areas the WG might consider on my blog at: 

Hi Phil,

I really do hate to be a stickler, but I don't think that the IETF can
consider your blog post to be an "IETF Contribution" in accordance with
the Note Well rules <http://www.ietf.org/about/note-well.html> -- I
realize that you put time and energy into those nice graphics, but could
we trouble you to at least post the text of your comments to this
mailing list? It really is for your own good. :)

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Charliemortimore <[email-masked]>
Date: Wed, 14 Mar 2012 16:35:15 -0700

Hey Phil - good, thoughtful writeup.   

I agree the notion of gateways/hubs are a reality.  Not yet convinced the client needs to ( or even should have ) knowledge/power over the routing decisions, at least in v1.   Look forward to discussion and evolving my thinking on this.  

- cmort

On Mar 14, 2012, at 2:44 PM, Phil Hunt <[email-masked]> wrote:

> _______________________________________________
> scim mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/scim

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 Mar 2012 16:45:34 -0700

Cross posting as requested...

SCIM - What Should A New SCIM WG Address?
In my last blog post, I mentioned that SCIM 1.0 defines as a simple provisioning API for cloud application service providers. SCIM is architecturally oriented as a connector API specification in a hub and spoke architecture typically with an enterprise provisioning system at the hub and a cloud application service provider being a spoke. Other variations could include provisioning for on-premsise SaaS applications as well as directory synchronization. For each cloud application, the enterprise IDM hub should be able to just invoke the SCIM RESTful API of a target application's SCIM provisioning end-point.

But is SCIM about to repeat much of the history of SPML? Has it corrected some miss-steps? Yes, definitely. Is that enough? Let's look at some of the historical issues that will be of relevance to the evolution of SCIM. Just to be clear, my comments are not to suggest that SCIM adopt SPML features. My comments are intended so that SCIM learn from SPML's history.

The Value Problem

SPML 1 was very much like SCIM 1.0 is now. A simple API that supported basic CRUD operations. When SPML 1 was developed, the proposed value proposition was that provisioning would be made easier if applications would adopt a standard IDM protocol, then provisioning of enterprise applications would become easier. The value to application developers was that simpler, standardized management API would not be specific to individual IDM vendors and could inter-operate with any IDM provisioning product.

From the enterprise perspective SPML 1 made a lot of sense since it would make all applications provision the same way. They could pick and choose the IDM product they wanted to use. More importantly, enterprises would not have to pay for custom coding when attempting to provision to proprietary APIs of applications.

SPML 1 was somewhat successful, but before it could be broadly adopted, several new requirements emerged and SPML 2 was defined (though SPML 1 remains dominant).  SPML 2 introduced many new features such as
	• the clean separation of payload from protocol; 
	• the introduction of new common IDM operations (e.g. password operations);
	• a formalized DSML/XSD profile;
	• targeting - the ability to provision accounts through a gateway; and,
	• an extension mechanism for registering capabilities so that contributed capabilities could be made inter-operable.
Yet application vendors wanted more: they wanted standard schema conventions, they wanted a standard that enabled them not to have to introduce individual IDM vendor dependencies. If they could write one SPML provider once and be done with it, their costs would go down.

Many idM vendors were concerned that SPMLv2 had gone too far. In the end, it was either perceived complexity or the basic value proposition was not enough for SPML to succeed.

Has SCIM moved the ball forwards? On one important point, the answer is yes. SCIM has put forward a well defined schema with clear definition of attributes and their use or meaning. The RESTful style of SCIM keeps schema cleanly separated.

The Information Semantics Fidelity Trade-off

IDM Provisioning product developers have always faced an engineering trade-off. Would a standardized provisioning protocol/API lower development costs? Each application is unique, therefore each unique application APIs often has highly specific semantics and contextual meanings. While saving money initially by using a standardized SCIM or SPML API, does this mean a loss of "fidelity" or functionality? Do different systems treat the notion of person or user in the same way? What does delete person mean? In translating information semantics, is mapping intelligence in the hub or in the spoke or somewhere in-between? The engineering question is: should the provisioning system understand the true nature of the application, or should the application understand provisioning systems and behave like an identity store? In my experience, there's no clear answer. It depends on the nature of the application.

Does SCIM help in this regard? That is yet to be determined. The SCIM community will need to discuss issues like how to handle high level IDM operations like suspend vs. delete, password resets, federation and other deeply IDM specific issues and how they are operationally mated with a diverse application services API community.

The Gateway Problem

Corporations that are organized into divisions often end up with different independent IT organizations and outsourced providers -- especially after corporate re-organizations, acquisitions, and divestitures. In these cases, single-hub provisioning systems often become unpractical. While some may view this as rare situation, the whole idea of a cloud based apps hosted externally makes this situation de rigueur.

In these cases a key provisioning architecture element is the ability to support provisioning gateways and hub-to-hub provisioning. Gateways (or proxies) serve a dual purpose of both firewalling direct access to internal services and they serve to greatly simplify network complexity for inter-organization communication. As well as solving basic firewalling issues, gateways can also support mapping functions changing from a standardized provisioning protocol like SCIM into application specific connector protocols like CRM OnDemand who may or may not have built support for a protocol such as SCIM.

Since a gateway acts as a "proxy" to other connected SaaS services, SCIM needs the ability route or "target" operations to specific application end-points. SPML 2.0 and now RESTpml/SIMPLEST supports targeting. Targeting enables a provisioning "hub" to indicate to a provisioning "gateway" that particular person requires an account in a particular target system. In the diagram above, Alice, employee 1234 is to be provisioned into the "Finance" application.

SCIM with routing/targeting becomes a critical communication protocol for hub-to-hub and hub-to-gateway provisioning. Unlike SPML implementation of the past, inter-operability becomes a key requirement because in the world of cloud provisioning it is more likely that gateway and hub implementations will come from different provisioning product developers.

The Cloud Does Change Everything

SPML was built for a world where everything occurred inside an enterprise. But the requirements for cloud identity management are substantially different. Cloud based provisioning architecture must take into account:
	• Performance and Scalability – A lightweight HTTP protocol such as with REST/JSON is a cornerstone requirement when provision cloud environments with 100s of millions of users.
	• Firewall requirements – securely connecting directly to application APIs (standardized or not) will likely require some special sauce. It's not reasonable to expect all application end-points to be able to support this in the cloud.
	• Cloud Providers are often "hubs" themselves – since cloud providers offer more than one application service, cloud providers may behave more like "hubs" than spokes.
	• Cloud Providers With Value-Added Data – some cloud providers may have provisioning and identity management systems of their own. This suggests that cloud hubs may need to flow back to the enterprise.
	• Entitlement Reporting – A big requirement for provisioning these days with SOX is the need for entitlement reporting. Further, when you are paying an external cloud provider for services rendered, you want to make sure you are paying for the correct employees to use cloud services. A key component of provisioning systems need to report back available rights of all users from all applications, especially through cloud "hubs".
	• Inter-operability – no longer can we assume hubs and gateways are provided by a single vendor. Cloud-based provisioning will almost always be multi-vendor based.
What Should The New SCIM WG Address?

The main success of SCIM has been a standardized schema. It defines the attributes and says what each means -- something that application vendors always wanted. This is goodness. Yet, there are some gaps when you start to consider the overall provisioning system that will emerge from SCIM's adoption.

A couple of scope items that the future IETF SCIM WG should be considering:

	• Routing or targeting – SCIM needs to have a way to handle updates through gateways and hub-to-hub relationships for supporting multi-service cloud providers.
	• Persons as distinct from Users – Currently SCIM combines these entities together in a simple form. The reality is that in the hub, persons hold multiple user accounts. Is a change needed to SCIM schema to support managing the relationships between persons and their user accounts? This may not need change, but wider discussion is needed.
	• Peer relationships – Cloud providers with hubs may need to be able to flow updates back to client hubs.
	• Reporting – attestation is a key component of provisioning. Not only will clients want to be able to reconcile what cloud providers are charging for, but clients also still have requirements driven by Sarbanes-Oxley. SPML's approach was burdensome. Could SCIM support the ability for a client "hub" to get the information it needs to accomplish this in a lightweight way in the spirit of SCIM?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Wed, 14 Mar 2012 16:49:19 -0700

Chuck,

Agreed. Routing shouldn't be specific. The concern is that the client should not have direct knowledge of internal endpoints.  In this case, I think the routing requirement is "logical".   Create a Mail account, create a CRM account, and so on.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Mar 2012 07:52:18 +0100

Phil,

The chairs would like to add you to the agenda for a brief presentation
on this, based on BoF interest.  Again, please focus your presentation
on how you would scope the WG's work.  Plan for 10-15 minutes.

Eliot

---

From: Michael Hammer <[email-masked]>
Date: Thu, 15 Mar 2012 11:47:15 -0400

Phil,

Great information.  However, I was looking through this for one specific
word and unless I missed it, did not see it.
Namely, where is the discussion of the trust model?

It is easy to get lost in the weeds of pushing data around in various
formats, but if the result does not provide an adequate chain of trust,
then it could all be a house of cards.  Although i will not be in Paris, it
would be good if somewhere an explanation of how trust is maintained could
be included.

Mike

On Wed, Mar 14, 2012 at 7:45 PM, Phil Hunt <[email-masked]> wrote:

> In my last blog post, I mentioned that SCIM 1.0 defines as a simple
> provisioning API for cloud application service providers. SCIM is
> architecturally oriented as a connector API specification in a hub and
> spoke architecture typically with an enterprise provisioning system at the
> hub and a cloud application service provider being a spoke. Other
> variations could include provisioning for on-premsise SaaS applications as
> well as directory synchronization. For each cloud application, the
> enterprise IDM hub should be able to just invoke the SCIM RESTful API of a
> target application's SCIM provisioning end-point.
>
>
> But is SCIM about to repeat much of the history of SPML? Has it corrected
> some miss-steps? Yes, definitely. Is that enough? Let's look at some of the
> historical issues that will be of relevance to the evolution of SCIM. Just
> to be clear, my comments are not to suggest that SCIM adopt SPML features.
> My comments are intended so that SCIM learn from SPML's history.
>
> The Value Problem
>
> SPML 1 was very much like SCIM 1.0 is now. A simple API that supported
> basic CRUD operations. When SPML 1 was developed, the proposed value
> proposition was that provisioning would be made easier if applications
> would adopt a standard IDM protocol, then provisioning of enterprise
> applications would become easier. The value to application developers was
> that simpler, standardized management API would not be specific
> to individual IDM vendors and could inter-operate with any IDM provisioning
> product.
>
> From the enterprise perspective SPML 1 made a lot of sense since it would
> make all applications provision the same way. They could pick and choose
> the IDM product they wanted to use. More importantly, enterprises would not
> have to pay for custom coding when attempting to provision to proprietary
> APIs of applications.
>
> SPML 1 was somewhat successful, but before it could be broadly adopted,
> several new requirements emerged and SPML 2 was defined (though SPML 1
> remains dominant).  SPML 2 introduced many new features such as
> • an extension mechanism for registering capabilities so that
> contributed capabilities could be made inter-operable.
> Yet application vendors wanted more: they wanted standard schema
> conventions, they wanted a standard that enabled them not to have to
> introduce individual IDM vendor dependencies. If they could write one SPML
> provider once and be done with it, their costs would go down.
>
> Many idM vendors were concerned that SPMLv2 had gone too far. In the end,
> it was either perceived complexity or the basic value proposition was not
> enough for SPML to succeed.
>
> Has SCIM moved the ball forwards? On one important point, the answer is
> yes. SCIM has put forward a well defined schema with clear definition of
> attributes and their use or meaning. The RESTful style of SCIM keeps schema
> cleanly separated.
>
> IDM Provisioning product developers have always faced an engineering
> trade-off. Would a standardized provisioning protocol/API lower development
> costs? Each application is unique, therefore each unique application APIs
> often has highly specific semantics and contextual meanings. While saving
> money initially by using a standardized SCIM or SPML API, does this mean a
> loss of "fidelity" or functionality? Do different systems treat the notion
> of person or user in the same way? What does delete person mean? In
> translating information semantics, is mapping intelligence in the hub or in
> the spoke or somewhere in-between? The engineering question is: should the
> provisioning system understand the true nature of the application, or
> should the application understand provisioning systems and behave like
> an identity store? In my experience, there's no clear answer. It depends on
> the nature of the application.
>
> Does SCIM help in this regard? That is yet to be determined. The SCIM
> community will need to discuss issues like how to handle high level IDM
> operations like suspend vs. delete, password resets, federation and other
> deeply IDM specific issues and how they are operationally mated with a
> diverse application services API community.
>
> The Gateway Problem
>
> Corporations that are organized into divisions often end up with
> different independent IT organizations and outsourced providers --
> especially after corporate re-organizations, acquisitions, and
> divestitures. In these cases, single-hub provisioning systems often
> become unpractical. While some may view this as rare situation, the whole
> idea of a cloud based apps hosted externally makes this situation de
> rigueur.
>
> In these cases a key provisioning architecture element is the ability
> to support provisioning gateways and hub-to-hub provisioning. Gateways
> (or proxies) serve a dual purpose of both firewalling direct access to
> internal services and they serve to greatly simplify network complexity for
> inter-organization communication. As well as solving basic firewalling
> issues, gateways can also support mapping functions changing from a
> standardized provisioning protocol like SCIM into application specific
> connector protocols like CRM OnDemand who may or may not have built support
> for a protocol such as SCIM.
>
> Since a gateway acts as a "proxy" to other connected SaaS services, SCIM
> needs the ability route or "target" operations to specific application
> end-points. SPML 2.0 and now RESTpml/SIMPLEST supports targeting. Targeting
> enables a provisioning "hub" to indicate to a provisioning "gateway" that
> particular person requires an account in a particular target system. In the
> diagram above, Alice, employee 1234 is to be provisioned into the
> "Finance" application.
>
> SCIM with routing/targeting becomes a critical communication protocol for
> hub-to-hub and hub-to-gateway provisioning. Unlike SPML implementation of
> the past, inter-operability becomes a key requirement because in the world
> of cloud provisioning it is more likely that gateway and hub
> implementations will come from different provisioning product developers.
>
> SPML was built for a world where everything occurred inside an enterprise.
> But the requirements for cloud identity management are substantially
> different. Cloud based provisioning architecture must take into account:
> • Performance and Scalability – A lightweight HTTP protocol such as
> with REST/JSON is a cornerstone requirement when provision cloud
> environments with 100s of millions of users.
> • Firewall requirements – securely connecting directly to application
> APIs (standardized or not) will likely require some special sauce. It's not
> reasonable to expect all application end-points to be able to support this
> in the cloud.
> • Cloud Providers are often "hubs" themselves – since cloud providers
> offer more than one application service, cloud providers may behave more
> like "hubs" than spokes.
> • Cloud Providers With Value-Added Data – some cloud providers may
> have provisioning and identity management systems of their own. This
> suggests that cloud hubs may need to flow back to the enterprise.
> • Entitlement Reporting – A big requirement for provisioning these days
> with SOX is the need for entitlement reporting. Further, when you are
> paying an external cloud provider for services rendered, you want to make
> sure you are paying for the correct employees to use cloud services. A key
> component of provisioning systems need to report back available rights of
> all users from all applications, especially through cloud "hubs".
> • Inter-operability – no longer can we assume hubs and gateways are
> provided by a single vendor. Cloud-based provisioning will almost always be
> multi-vendor based.
> The main success of SCIM has been a standardized schema. It defines the
> attributes and says what each means -- something that application vendors
> always wanted. This is goodness. Yet, there are some gaps when you start to
> consider the overall provisioning system that will emerge from SCIM's
> adoption.
>
> • Routing or targeting – SCIM needs to have a way to handle updates
> through gateways and hub-to-hub relationships for supporting multi-service
> cloud providers.
> • Persons as distinct from Users – Currently SCIM combines these entities
> together in a simple form. The reality is that in the hub, persons hold
> multiple user accounts. Is a change needed to SCIM schema to support
> managing the relationships between persons and their user accounts? This
> may not need change, but wider discussion is needed.
> • Reporting – attestation is a key component of provisioning. Not only
> will clients want to be able to reconcile what cloud providers are charging
> for, but clients also still have requirements driven by Sarbanes-Oxley.
> SPML's approach was burdensome. Could SCIM support the ability for a client
> "hub" to get the information it needs to accomplish this in a lightweight
> way in the spirit of SCIM?
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 15 Mar 2012 09:21:55 -0700

Mike,

Thanks.

I didn't comment on trust because I did not see any additional scope requirements that aren't already being discussed (e.g. support for OAuth).

Phil

@independentid
www.independentid.com
[email-masked]

On 2012-03-15, at 8:47 AM, Michael Hammer wrote:

> Phil,
> 
> Great information.  However, I was looking through this for one specific word and unless I missed it, did not see it.
> It is easy to get lost in the weeds of pushing data around in various formats, but if the result does not provide an adequate chain of trust, then it could all be a house of cards.  Although i will not be in Paris, it would be good if somewhere an explanation of how trust is maintained could be included.
> 
> Mike
> 
>

---

From: Kelly Grizzle <[email-masked]>
Date: Thu, 15 Mar 2012 18:18:06 +0000

Phil,

Thanks for the great write-up.  I agree that the hub concept is highly relevant, and have actually been spending a fair amount of energy thinking about how this might look in SCIM.  In my mind there are two types of gateways: a provisioning hub and an identity hub.  A provisioning hub knows nothing about the person -> user relationship.  It simply provides a single SCIM-enabled endpoint that can manage accounts on different targets.  Similarly, an identity hub allows managing accounts on different targets, but also maintains the person -> user relationships.  Both have the firewall, single protocol, etc... benefits that you mentioned, but the latter is more suited to the IdM use cases that SPML addresses.  I think that both are useful, so we should consider making the person -> user relationship an optional part of targeting/routing.

I have some ideas on how this may fit into SCIM and would be happy to collaborate and help lead this effort.

Taking a step back ... while there is a strong need for this, I also think that a majority of the SCIM service providers are not going to be serving as a hub (ie - they will only be managing their own users), so targeting should optional.

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, March 14, 2012 6:49 PM
To: Charliemortimore
Cc: [email-masked]
Subject: Re: [scim] Thoughts on SCIM WG charter

Chuck,

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Thu, 15 Mar 2012 12:01:58 -0700

Kelly,

Agreed. Targeting should be optional.

I'd like to look specifically how we can layer this on without requiring disruptive change to the existing implementation. 

Would be great to collaborate with you on this.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Mar 2012 22:10:30 +0100

One of the things the draft charter has discussed is an extension
mechanism.  It is also useful to sort the order of work.  One useful way
to handle both of these is to have a test case in mind.  This might be
it.  That is- see if we can get the extension mechanism in place so that
we can address multipoint.

Eliot

---

From: Trey Drake <[email-masked]>
Date: Thu, 15 Mar 2012 16:20:43 -0500

Something to consider - if targeting is no more than introducing additional attributes (to describe the intended target) then a road has been paved with the submitted core schema draft (see section 4) http://tools.ietf.org/html/draft-scim-core-schema-00#section-4  

Thanks,
Trey

---

From: "Milas, Brian" <[email-masked]>
Date: Thu, 15 Mar 2012 22:37:06 +0000

We also see value in the hub approach and are interested in collaborating in this area.

Brian Milas
Chief Technology Officer
phone: +1 508 879-8400, ext. 202
[email-masked] 

Connect with us:
   
www.courion.com 
__________________________________________________ 
THIS EMAIL CONTAINS CONFIDENTIAL INFORMATION 
AND IS INTENDED FOR THE RECIPIENT ONLY. 
PLEASE DELETE THIS IF YOU HAVE RECEIVED 
IT IN ERROR. 

-----Original Message-----
From: Kelly Grizzle [mailto:[email-masked]] 
Sent: Thursday, March 15, 2012 2:18 PM
To: Phil Hunt; Charliemortimore
Cc: [email-masked]
Subject: Re: [scim] Thoughts on SCIM WG charter

Phil,

--Kelly

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Wednesday, March 14, 2012 6:49 PM
To: Charliemortimore
Cc: [email-masked]
Subject: Re: [scim] Thoughts on SCIM WG charter

Chuck,

Phil

@independentid
www.independentid.com
[email-masked]