Identity and access management (IAM) is a system of technical and non-technical mechanisms to ensure the proper...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
establishment and control of identities, the assignment of privileges to those identities, and then controlling access based on those privileges. Most organizations that are planning on utilizing cloud computing services need to ensure those mechanisms are appropriately integrated into their cloud plans. In this tip, we’ll address key parts of the identity portion of IAM and how they work in the context of the cloud.
When thinking about cloud identity management, two of the most important questions or architecture decisions that need to be made are:
• What type of Identity validation is acceptable?
• Will you trust others’ identity stores or only use your own?
Cloud identity management: identity validation
There are two primary mechanisms by which identities are validated: organizational and personal.
• Organizational: In an organizational validation, there is a process by which the identity of a person is confirmed or asserted by the organization that is creating the identity. This is basically the process by which users are assigned IDs within an organization. There is typically some level of trust that is associated with the validation.
• Personal: When someone says who they are. There is typically no additional validation of the information the user gives. For example, I can register a username with a well-known Web mail account and self-assert that I am John Wayne or Bill Gates or Steve Jobs, or some other famous person. There should be a much lower level of trust associated with this type of validation, as compared to the organizational type.
Companies should utilize organizational-based assertions for business-related purposes, but if you have consumer-focused services, self-assertion may be an acceptable option. It’s important to note that in order for you to be successful in implementing or using organizational identities for cloud identity management, you will need to be doing it right in the enterprise first. So, if you do not have a mature identity management environment in your enterprise, start there.
Cloud identity management: identity sources
The next question you need to answer is what sources of identity will accept? Will you, or even can you by policy/contract/regulation, rely on identities that others have asserted? Do you require all identities to be something that you have vetted? The answer to these questions will have a fundamental impact on how you proceed. The former is typically associated with federated identities, whereas the latter is a local identity store. The advantage of federated identities is leveraging the identity management aspects of the different organizations that are part of a federation. The disadvantage of federated identities is they require trust in those other organizations (more below). The trade-off between federated and local is management versus trust. As a side note, if you are looking at federated identities, there are two main standards that you will need to consider: Security Assertion Markup Language (SAML) and WS-Federation.
Cloud identity management: Who do you trust?
One of the issues with trust is likely to get down to how those other organizations actually assert identities, or validate the identities of their users. You should likely be much more trusting of an organization that validates their users’ identities, as opposed to one that allows users to self-assert their identities. Further, if the federation is a limited community, it may have some inherent trust within it.
Think of organizational assertion as utilizing your corporate identities to authenticate to a partner. The partner is relying on the fact that your organization has vetted you and is assigned you an IDE and takes your organizations assertion of who you are. It’s important to note that in order to enable this type of identity assertion, your enterprise IAM will need to be extended into the cloud.
Steps to take
Extending an organization’s identity services into the cloud is a prerequisite for strategic use of on-demand computing services. Much of your decision will be determined by the type of cloud computing that you are planning on utilizing, public or private, as well as IaaS, PaaS or SaaS. These will have a significant impact on your ability to choose an IAM solution. Organizations looking at extending their enterprise into the cloud should to do the following for cloud identity management:
• Inquire of proposed cloud service providers to see what type of IAM integration they have with the services you are looking at using;
• Plan on utilizing organizational assertion of identities;
• Create a project to figure out how to extend your current enterprise IAM solution to your cloud services, most likely utilizing SAML;
• Extend your organization’s IAM practices, processes and procedures to your cloud services.
About the author:
Philip Cox is a principal consultant of SystemExperts Corp., 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 Special Interest Groups. Cox 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).