Security in any system involves primarily ensuring that the right entity gets access to only the authorized data in the authorized format at an authorized time and from an authorized location. Identity and access management (IAM) is of prime importance in this regard as far as Indian businesses are concerned. This effort should be complemented by the maintenance of audit trails for the entire chain of events from users logging in to the system, getting authenticated and accessing files or running applications as authorized.
Even in a closed, internal environment with a well-established “trust boundary”, managing an Active Directory server, an LDAP server or other alternatives, is no easy task. And for IAM in the cloud, the challenges and problems are magnified many times over. An Indian organization moving to the cloud could typically have applications hosted on the cloud and a database maintained internally, with users logging on and getting authenticated internally on a local Active Directory server. Just imagine attempting single sign-on (SSO) functionality in such a scenario! Cloud delivery models comprising mainly SaaS, PaaS and IaaS require seamless integration between cloud services and the organization’s IAM practices, processes and procedures, in a scalable, effective and efficient manner.
Identity provisioning challenges
The biggest challenge for cloud services is identity provisioning. This involves secure and timely management
When a user has successfully authenticated to the cloud, a portion of the system resources in terms of CPU cycles, memory, storage and network bandwidth is allocated. Depending on the capacity identified for the system, these resources are made available on the system even if no users have been logged on. Based on projected capacity requirements, cloud architects may decide on a 1:4 scale or even 1:2 or lower ratios. If projections are exceeded and more users logon, the system performance may be affected drastically. Simultaneously, adequate measures need to be in place to ensure that as usage of the cloud drops, system resources are made available for other objectives; else they will remain unused and constitute a dead investment.
- How many users on average will be accessing the system?
- What system resources are needed per user, on average?
- Are multiple logons allowed for a single username? This has a potential impact on capacity planning, since these numbers are not predictable.
- Are clients allowed to create an unlimited number of users? Capacity planning could be affected here too, as in such cases clients tend to create users unnecessarily and also forget to remove users no longer required, thus blocking precious system resources.
- What are the scalability requirements for the next 3/6/12 months?
- Is the infrastructure adequate to meet these scalability requirements?
- How will you handle performance spikes? Up to what level and for how long can the system continue to work without affecting user productivity?
- What are the processes for IAM in the cloud to ensure that system administrators are efficiently informed about users added to or deleted from the system?
- Will users be disabled or deleted once requests for removal of users come through?
- Will the data created by dropped users be retained or not? Do client administrators decide this? Will you allow this data to be merged with existing users?
IAM across organizations
The second challenge for IAM in the cloud, which is slowly being mitigated with technology advancements, is identity management across multiple independent organizations. The easy way out is to have multiple logon ids and multiple passwords, but this raises the issue of users reusing passwords, using weak passwords, sharing passwords, and so on.
The concept of federated identity management (FIdM) is one popular way of tackling this issue. FIdM plays a vital role in enabling organizations to authenticate their users of cloud services using the organization’s chosen identity provider (IdP). For instance, a user with a Google account ID can add to that account various applications provided by external providers (paying a license fee, if applicable). The user logs on using the Google account to use any of these applications, and is transparently authenticated and authorized as appropriate.
You can carve out an IdP or single sign-on provider using an internal directory service or a cloud-based identity and access management system. Using an IdP, client organizations can share identities without sharing user credentials or private user attributes. This approach helps organizations to extend IAM processes and practices to the cloud and implement a standardized federation model to support single sign-on to cloud services.
Federation technology consists of centralized identity management architecture utilizing industry-standard identity management protocols such as security assertion markup language (SAML), WS-Federation, Liberty Alliance, and so on. Of these, SAML is the unofficial standard for enterprise-controlled federation. In March 2005, SAML 2.0 was recognized as an official OASIS industry standard and now enjoys the support of vendors and organizations worldwide for deploying and managing open identity-based applications. You can obtain more information from: https://wiki.oasis-open.org/security and http://saml.xml.org/
So that’s it for IAM in the cloud. The next article in this series will address cloud privacy issues. Stay tuned!
This was first published in October 2012