By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
This tip is part of SearchCloudSecurity.com's Cloud Security School lesson, Identity management and access control in the cloud. Click on the lesson page for the other materials in this lesson. For dozens of free lessons on a variety of information security and compliance topics, visit SearchSecurity.com's Security School Course Catalog.
Most organizations have multiple identity stores and access management mechanisms that require user provisioning. Provisioning these users in the cloud, however, becomes another task the enterprise must wrestle with.
One of the features many organizations will want to implement to support cloud service is dynamic user provisioning. This technical tip will help identify practical mechanisms by which an organization can implement such dynamic cloud provisioning.
In the current state of the market, an enterprise's ability to implement dynamic account provisioning is dependent upon two things:
- The cloud service provider
- The tool(s) the enterprise currently uses for account provisioning
Your choice of the cloud service provider (CSP) has a direct effect on the organization's ability to implement dynamic provisioning. Most of the current CSPs provide proprietary APIs to allow enterprise customers to provision users. An organization can link its current enterprise account provisioning system with its CSP, and thus create “dynamic” provisioning. This entails creating a connector (i.e., a piece of software that links the CSP API to the enterprise's provisioning tool) and would thus allow dynamic creation of accounts in the cloud infrastructure based on provisioning that is performed within the enterprise. Basically, you will be creating connectors that translate your provisioning information to the provisioning information of the CSP.
Generally, organizations that use multiple cloud service providers will have to create a connector for each CSP, because most CSPs do not support open standards for their APIs. For those that use a single cloud service provider, the work is not as complicated as with multiple CSPs (but other issues arise, such as a lack of redundancy). So, the reality is, most dynamic provisioning is custom, even if you have a commercial provisioning product. Hopefully in the future, as more companies demand CSPs use open standards, standards can be much more universally accepted and utilized.
An enterprise's current account provisioning tools also play a major role in its ability to perform dynamic provisioning with a CSP. Typically, from a user provisioning standpoint, organizations fall into one of two camps:
1. Those that have a current, enterprise-wide identity and access management system (e.g., from Microsoft, Oracle Corp., Novell Inc., IBM, etc.) and will utilize that mechanism to provision accounts to cloud services.
2. Those that do not have a commercial tool and will develop customized internal provisioning.
For those that fall into the first group, the ability to enable dynamic provisioning will be controlled by the capabilities provided in the enterprise IAM product and the support provided from the IAM vendor. In order to enable dynamic provisioning, the first step will be either to look for a cloud service provider (CSP) that supports your IAM product, or work with your IAM vendor to figure out how to create the connectors. If your cloud service provider already has that connector, then you won't have to write it, and your dynamic provisioning integration will be much easier.
Those that fall into the second category -- the majority of enterprises -- will need to build a custom connector. The remainder of this tip discusses recommendations for doing just that.
As described earlier, the choice of cloud service providers will directly affect the enterprise's provisioning ability. I recommend searching for cloud service providers that support open standards; this lessens the likelihood of needing to create and maintain separate connectors for every cloud service provider. If the CSPs you use -- and you should use multiple, particularly considering the recent Amazon AWS outages -- do not support open standards, custom development will be needed to code specialized connectors for each one of them. This will increase the cost and complexity of the project, neither of which is desirable.
Once you’ve chosen your CSPs, you need to understand what the CSP supports for entitlements, and then map those entitlements appropriately to the enterprise's definition of entitlements (i.e., roles and permissions). This is likely going to be the most arduous part of the whole process. If you do not take the time to do this properly, it is likely that, while the organization may be dynamically provisioning these users, the access users have will be either inadequate or excessive, and, thus, will violate policy as well as good security practices. That’s why it is critical to get it right the first time. For example, it's important to validate at whatever cloud level you are using (i.e., IaaS, PaaS, SaaS) that a user provisioned in an enterprise role is accordingly provisioned in the cloud environment. Typically this is done through sampling and manual validation.
Along with the entitlements mapping, there is also the issue of ensuring identity mapping occurs correctly. Typically, this is not as hard as mapping entitlements, but still should not be overlooked. You do not want to have identity collisions (i.e., when similar UIDs/names from different identity stores representing separate users are merged) between the enterprise and the cloud provider.
Once you’ve got your identity mapping and entitlement mapping figured out, you need to understand the mechanisms by which confirmation or errors will be transmitted back and forth between the enterprise and the cloud service provider. You want to make sure that, when you believe an account is provisioned, it actually was provisioned, and the entitlements were appropriate for the account that was created. Hence, there needs to be some type of feedback loop to give you an indication of what was done, and the results. If that feedback loop is not integrated into the process, serious provisioning mishaps could occur. The feedback loop should be programmatic and automated. Detailed error messages as to “what” and “why” certain errors occurred are going to be important, because then appropriate actions can be taken to remediate any failures, and successes will be confirmed.
I mentioned open standards, and there are a couple you should consider when undertaking a dynamic provisioning project, as they can make the entire process run more smoothly. In particular, you should ask or require the CSP to support or adopt them:
- Service Provisioning Markup Language (SPML) for automated provisioning with workflows. This will potentially enable easier integration with other products in the future. Ping Identity recently had a push to standardize around their Simple Cloud Identity Management (SCIM) specification. This may be a good alternative to SPML, but we’ll have to wait and see.
- Security Assertion Markup Language (SAML), which provides authentication assertion for transient provisioning.
Considering the current state of CSPs, it's likely dynamic provisioning will be quite labor intensive for most organizations to actually implement. If your current provisioning process is streamlined and efficient, then the likelihood of success increases significantly. The most important things to remember, however, when embarking on a cloud IAM project specifically to create dynamic user provisioning, include the following:
- Take the time to map entitlements between your organization and your cloud service provider in detail.
- Ensure users are provisioned with appropriate entitlements. This basically means ensuring your connectors are mapping entitlements correctly.
- Make sure CSPs you sign up with support open standards such as SPML. This will potentially enable easier integration with other products in the future.
About the author:
Philip Cox is a principal consultant of SystemExperts Corporation, a consulting firm that specializes in system security and management. He is a well-known authority in the areas of system integration and security. He serves on the Trusted Cloud Initiative Architecture workgroup, as well as the PCI Virtualization and Scoping SIGs. Phil frequently writes and lectures on issues dealing with heterogeneous system integration and compliance (PCI-DSS and ISO). He is the lead author of Windows 2000 Security Handbook Second Edition (Osborne McGraw-Hill) and contributing author for Windows NT/2000 Network Security (Macmillan Technical Publishing) and CIW Security Professional Certification Bible(Wiley).