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?

In my next post, I'll have more details on how I think the routing issue could be addressed.

....With thanks to Gary Cole and Mark Diodati for their wisdom and input.


Note well: the comments posted here are my personal comments and are intended as input to the IETF and are subject to the rules of RFC 5378 and RFC 3979 (updated by RFC 4879).