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.
[ Bitbucket vs. GitHub: Which project host has the most? | Work smarter, not harder; InfoWorld has all the tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Keep up with the latest developer news with InfoWorld's Developer World newsletter. ]
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.