As happens on occasion, I'm stepping aside this week to let someone from my company, Open Software Integrators, take the spotlight. This time around, my friend and colleague Phil Rhodes has provided a fantastic primer for provisioning multiple SaaS applications. Phil has been there and done that. I think you'll benefit from his experience. -- Andrew C. Oliver
My employer, Open Software Integrators, recently made a wholesale move to the cloud for our internal IT needs. We replaced a rack of local servers -- running Zimbra, SVN, MediaWiki, Jira, SugarCRM, and the like -- with hosted SaaS applications. We now use the full Google Apps suite, Bitbucket, and the SaaS-delivered versions of Sugar and the Atlassian suite.
By and large, this move has made life easier -- and protects us against a car crashing into our building and taking out our entire infrastructure in one fell swoop.
But there's a fly in the ointment of wholesale SaaS adoption. I first noticed this when trying to commit some code to a Bitbucket repo, only to find that, while my Google account allowed me to log in, I had not given the necessary permissions to commit. When I went in to talk to our de facto system administrator, we found that finding and fixing this permissions problem was quite involved.
The provisioning legacy
Of course, this same kind of scenario happens with on-premises applications as well, and this sort of problem is exactly what led to the development of provisioning as a discrete topic of interest in IT. Eventually it led to the evolution of a variety of technical standards and associated implementations and toolkits to enable programmatic provisioning of services.
In the enterprise, SSO (single sign-on) and identity management systems are used to consolidate access to resources. Hence, in most larger organizations today, new user onboarding results in a user record being created in an LDAP or Active Directory server somewhere -- which allows for authentication and authorization -- as well as messages exchanged in a language like SPML (service provisioning markup language) or XACML (extensible access control markup language), to create corresponding authorizations for the new user in applications throughout the organization. Likewise, de-provisioning a user or modifying a user's rights can be managed centrally.
In the SaaS world, however, the state of provisioning is not quite as mature. Most SaaS providers support one or more popular cloud-based approaches to SSO, such as the aforementioned Google Accounts. But the ability to programmatically manage user roles and permissions -- and the capabilities needed to build tools for managing users across the smorgasbord of cloud applications a given firm may employ -- appears to be lacking. Worse, for organizations employing a hybrid IT model, with a mixture of private, on-premises applications and SaaS applications, the path to providing SSO and integrated user management is still somewhat fuzzy.
As it happens, work is under way to mitigate this problem. Technical standards have been or are being developed to support the capabilities needed to provide a seamless, integrated provisioning model that includes SaaS applications. Several startups have been spawned over the past couple of years, each of whom are providing solutions to address the SaaS provisioning problem.
SPML and its limitations
SPML and its limitationsThe granddaddy of provisioning standards is certainly SPML. Originally published in 2003, SPML is a product of the OASIS Provisioning Services Technical Committee. OASIS defines provisioning as "the automation of all the steps required to manage (setup, amend and revoke) user or system access entitlements or data relative to electronically published services."
The Statement of Purpose for the Provisioning Services TC explains the need for interoperable provisioning services for both intra-enterprise and inter-enterprise use, and which can transcend the boundaries of a single security domain in order to manage identities across domains. To that end, SPML is "a standard, XML-based framework for creating and managing information that represents user identities and related entities."
SPML supports operations for listing "target" objects that receive provisioning requests, adding objects (access and entitlements) to those targets, modifying objects, and deleting objects. Support is also provided for setting, expiring, resetting, and validating passwords, as well as for temporarily suspending (and later reactivating) user accounts. The standard provides support for asynchronous mode and for bulk operations too.
Using SPML, it becomes possible to programmatically automate the provisioning of user access and entitlement rights, across a wide range of services. Of course, for this to be possible, the target services must provide SPML -- and there's the rub. While this specification has been around for years, enjoys multiple solid implementations (including open source implementations), and has historical roots in the world of the wildly successful LDAP, it simply has not been widely adopted. This is even truer in terms of SaaS and cloud provisioning. You may find individual enterprises that use SPML for automatic provisioning behind the firewall, but not many SaaS providers support SPML -- yet.
Why has the SaaS world been so slow to adopt SPML? One reason is that we are only now reaching the tipping point where any one organization uses enough different SaaS applications from a variety of vendors that provisioning overhead has become a significant problem. Up until now, there was little reason for the provider of a SaaS app to worry about supporting programmatic provisioning, since no one was asking for it. The second reason, vis-a-vis SPML in particular: SPML is complicated. It works -- and works well -- for its intended purposes, but it is not a simple protocol, and integrations using SPML can be somewhat complex. This friction has served to slow down its adoption in the SaaS world.
Searching for standards
If not SPML, then what mechanism will simplify cloud provisioning? The new kid on the block is a protocol known as SCIM (system for cross-domain identity management). Developed under the auspices of the IETF, SCIM is more specifically designed for managing user identities in cloud-based applications and services.
SCIM has a modern feel to it, because the specification defines both JSON and XML encodings, and the spec defines a RESTful interface for provisioning operations. SCIM also has the backing of two giants in the cloud world: Google and Salesforce. The SCIM protocol specification is in draft status at this time, but the core schema has been submitted as a Proposed Standard, and the IETF Working Group road map calls for completion in early 2014.
In addition to SPML and SCIM, a handful of other standards exist that address varying aspects of automated provisioning. XACML, another OASIS standard, focuses tightly on managing access control lists in a security environment using ABAC (attribute-based access control). RBAC can also be implemented using XACML by treating it as a specialization of ABAC.
Like SPML, XACML is somewhat complicated and has not gained widespread adoption for cross-domain provisioning. It remains mostly limited to use behind the firewall. Another protocol, WS-Federation, is part of the Web Services Security framework and focuses on controlling access to Web Services. WS-Federation, along with WS-Trust and WS-SecureConversation, has yet to gain widespread adoption among SaaS providers.
Some have also suggested that OAuth could be adapted to serve as part of an approach for federated provisioning in the cloud. OAuth is a wildly popular and successful approach to user-level authorization, and it is not unreasonable to think that a revised OAuth protocol, or a new protocol spun off of OAuth, could gain significant traction. Keep your eye on this, although nothing appears to be imminent.
Identity as a service
Technical specifications alone are not the solution to managing provisioning issues. Few customers want to be in the business of writing code to perform custom integrations with cloud apps, even if every SaaS provider in existence supported both SPML and SCIM.
Luckily, cloud identity management providers are beginning to emerge to take care of the technical details and hide the nasty integration bits behind a simple, user-friendly interface. In particular, Okta has a very comprehensive enterprise identity management platform, which neatly encompasses the provisioning of SaaS applications -- and can unify an existing on-premises identity management mechanism with cloud apps. Okta already supports SaaS applications, including Google Apps, Microsoft Office 365, Salesforce.com, Box.com, and many more.
Of slightly more recent vintage, Bitium graduated from the Amplify startup accelerator in 2012 and recently raised $2.4 million in venture funding to further develop a SaaS provisioning platform. Like Okta, Bitium provides a single platform for administrators to manage access to all the SaaS applications. Bitium advertise support for a laundry list of applications, including Yammer, Box.com, Dropbox, Salesforce.com, Gmail, and so on.
What you should do
If you've taken a flying leap into the cloud and subscribed to multiple SaaS applications, no doubt you've encountered many of the same issues we have bumped into at Open Software Integrators. To sum up, here are our recommendations:
- Investigate Okta and/or Bitium and consider using their respective services if they fit your needs.
- Encourage SaaS vendors that you work with to add support for SPML and SCIM protocols for programmatic provisioning.
- If you're technically inclined, consider joining the SCIM Working Group or the OASIS Provisioning Services TC and help develop the protocols necessary to address your needs.
SaaS applications will only grow in importance, which guarantees that cross-domain provisioning will remain a hot issue for years to come. Dive in and become more knowledgeable about the work going on in this space. If you have the interest and ability, perhaps you can become part of the solution.
This article, "How to provision users in a cloud world," was originally published at InfoWorld.com. Keep up on the latest developments in application development, and read more of Andrew Oliver's Strategic Developer blog at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.
This story, "How to provision users in a cloud world" was originally published by InfoWorld.