Identity and access management (IAM) refers to the processes, technologies, and policies for managing digital identities and controlling how identities can be used to access resources. Typically, IAM includes three separate processes:
Identity management in a cloud system requires a complex collection of technologies to manage authentication, authorization and access control across distributed environments. These environments might include assets both on the internal cloud (Private
Cloud) and services accessed on the public cloud. These environments can also cross-security domains, as when two enterprise-level organizations collaborate and enable cross-domain access to users from the partner security domain.
This document is part of a collection of documents that comprise the
Reference Architecture for Private Cloud
document set. The Reference Architecture for Private Cloud documentation is a community collaboration project. Please feel free to edit this document to improve its quality. If you would like to be recognized for your work on improving this article,
please include your name and any contact information you wish to share at the bottom of this page.
Federated services are often used in cloud deployments, and might include the use of technologies such as
Microsoft Active Directory Federated Services (ADFS) 2.0, and
Windows Identity Foundation (WIF), to provide
services to their internal networks. You will need to determine which type of IAM provider to use when you host your services in the
Public Cloud. The underlying question you need to address is how do you leverage your existing identity infrastructure as you migrate some of that infrastructure into the Public
One possible solution would be to extend an existing (or planned) claims-based security model to the cloud. Claims-based security enables organizations to:
In claims-based security, the user provides a claim, often in the form of a
token, to an issuer. The issuer authenticates the claim. An issuer can be a
domain controller, or other technology that serves as a centralized user credential store. If the claim passes authentication the issuer passes the requesting thread to the service or application, which is responsible for authorizing the user based on its
claim. The service or application does not have to find or manage user accounts.
When claims-based authentication is used, it does not matter whether the application or service is hosted in the Private Cloud or the Public Cloud, the authentication mechanism is the same. The application simply evaluates the claim provided by the user
and determines whether that user has access rights to use the application, and, if so, what portions of the application the user can access.
Claims can be much more than just roles or permissions. One of the added benefits of working with a claims-based model is that a claim can carry information about an authenticated user, such as e-mail address, full name, birth date, team affiliation,
role within the company and more. Applications and services and also use claims to verify user information. For example, a claim could indicate that a user is at least the age required to perform an action (a
Boolean claim indicating IsOver21 or IsOver13), or verify that a user belongs to a particular department without sharing a list of all departments the user belongs to.
Claims-based security not only centralizes user data stores, after a claim has been authenticated, that claim is readable across platforms. This means that the claim can request resources in different trust domains, as long as the issuer is trusted by the
Microsoft Active Directory Federated Services (ADFS) 2.0, used with Windows Identity Foundation (WIF), can act as a claims issuer. WIF is the .NET managed framework that enables developers to create applications and services that support claims-based security.
The following links discuss some of the common IAM provider types: