Published: January 2013
Contributors:  
Gayana Bagdasaryan, Microsoft
Thomas W. Shinder, M.D, Microsoft
Ken St. Cyr, Microsoft
Heath Aubin, Microsoft
Brjann Brekkan, Microsoft
Gary Verster, Microsoft
Bruce Wittenberg, Microsoft 
  
For the latest information, see http://www.technet.com/cloud

Download a Word copy of this article from the TechNet Gallery.

Table of Contents



Introduction


The purpose of this document is to provide detailed conceptual information on identity infrastructure capabilities specific to both on-premises and cloud computing that we at Microsoft are most often asked by our customers to implement. It is also in our purpose to provide introductory information on the existing Microsoft solutions that can help you obtain these popular identity infrastructure capabilities. The information presented in this document requires the reader to be familiar with the concepts and understand in detail the four fundamental pillars of an identity infrastructure as defined by our in-house solution architects. For more information, see Four Pillars of Identity.

In this document, we will cover the following identity infrastructure capabilities:

Access Control


Inherently, access control is at the root of all identity-related tasks and challenges that organizations seek solutions for. Access control consists of authentication, which helps determine if an identity presented to the protected environment should be allowed in, and authorization which helps determine what the accepted identity should be allowed to do within the boundaries of the protected environment. The following are the most common types of access control:

Role-based access control

Role-based access control (RBAC) is the most popular type of access control used by the majority of organizations with more than 500 employees. With RBAC, within an organization, roles are created for various job functions and the permissions to perform certain operations are assigned to specific roles. Employees or other system users are assigned particular roles, and through those acquire the permissions to perform particular functions within the organization. Since users are not assigned permissions directly and only acquire them through their role (or roles), management of individual user rights is a matter of simply assigning appropriate roles to the user's account.
This simplifies common operations, such as adding users or changing a user's department.

Microsoft has two RBAC solutions. The first is the Microsoft BHOLD suite. Integrated with FIM 2010 R2, Microsoft BHOLD suite provides RBAC and allows administrators to review access rights continually across the organization. With BHOLD, roles are assigned automatically based on user attributes, selected by the user’s manager, self-applied by the user based on the user’s eligibility into the role. For more information, see http://www.microsoft.com/en-us/server-cloud/forefront/identity-manager.aspx and http://support.microsoft.com/kb/2617874 .

Authorization Manager is another RBAC solution from Microsoft. Authorization Manager is a Microsoft Management Console (MMC) snap-in that can help provide effective control of access to resources. The two categories of role-based administration that benefit from this technology are user authorization roles, which are based on a user's job function, and computer configuration roles, which are based on a computer's function. For more information, see http://technet.microsoft.com/en-us/library/cc732077(WS.10).aspx.

Attribute-based access control

With attribute-based or claims-based access control, you examine and process claims or statements that users makes about themselves or other usersorefront/identity-manager.aspx and http://support.microsoft.com/kb/2617874 .

Authorization Manager is another RBAC solution from Microsoft. Authorization Manager is a Microsoft Management Console (MMC) snap-in that can help provide effective control of access to resources. The two categories of role-based administration that benefit from this technology are user authorization roles, which are based on a user's job function, and computer configuration roles, which are based on a computer's function. For more information, see h to make authentication and authorization decisions on allowing or preventing a user from accessing your resources. A claim or an attribute can be a name, an identity, a key, a group, a privilege, a capability, etc.

Microsoft has a few different solutions for this very popular type of access control.The easiest approach is for applications to read user attributes from Active Directory via LDAP or using the Active Directory Services Interface in .NET.  Applications can authenticate to the directory either with a dedicated service account or use a delegated Kerberos ticket to authenticate on the behalf of the user and gather the appropriate attributes. This method is good for internal applications, but external applications may not have access to the data inside of Active Directory.

Another approach is to make the application claims-aware and use Active Directory Federation Services (AD FS) 2.0 to provide a Security Assertion Markup Language (SAML) token to the application, which contains the attributes that the application needs. AD FS is able to gather the attributes from Active Directory, as well as other 3rd party directories and data stores that might hold the user’s attributes (or claims). For more information about AD FS, see http://technet.microsoft.com/en-us/library/adfs2(WS.10).aspx.

For cloud applications, Windows Azure Access Control Service (ACS) is an alternative to AD FS and functions in a similar manner. Rather than obtaining attributes from the on-premises directory like AD FS does, ACS would assert the attributes from trusted 3rd party identity providers (Microsoft Account, Google, Yahoo, Facebook). ACS can be used in conjunction with AD FS to augment the SAML token with information from a local directory.

Policy-based access control

Policy-based access control is becoming increasingly popular in the industry and is specific to authorization.  Policy-based access control makes a determination about whether or not the user should be able to access a resource based on:

With policy-based access control, you are not accepting, processing, and making decisions based on roles and attributes, but taking an identity, giving it to a policy service, and having the policy service make an access control decision for you.

There are various policy-based access control standards that have already emerged, for example, XACML (http://en.wikipedia.org/wiki/XACML). The idea is that you have a policy decision maker somewhere in your environment. Your application takes a SAML token or whatever identity it receives an access request from and passes it on to the policy decision maker. The policy decision maker examines the identity and decides whether this identity can have access to your application. 

Policy-based access control is very important to cloud computing.  As you move your data, identities, and resources back and forth between on premises and the cloud (as in the hybrid cloud model) you will need to be able to have every application, or at least those applications that are split between the cloud and the on premises portions of your environment, to be able to query the same policy store and apply the same policies regardless of who or where the data is.  Policies can be created and enforced centrally by the enterprise or defined by a designated policy administrator for an application.

Risk-based access control

Risk-based access control is specific to authentication. A risk-based access control mechanism takes into account the profile of the identity requesting access to a resource (an application or a service) to determine the risk profile associated with that transaction. The risk profile is then used to determine the complexity of the challenge. Higher risk profile leads to stronger challenges, whereas a static username/password may suffice for lower-risk profiles. Risk-based implementation allows the application or a service to challenge the user for additional credentials only when the risk level is appropriate. In other words, risk-based access control adapts the authentication strength to different circumstances. For example, if the previous day’s logon was at an IP address 3,000 miles away, the user would be asked to authenticate with an additional factor.

Application Access Management

Application access management is part of the overall access control identity infrastructure capability. You can think of application access management as coarse-grained access control – a solution that helps you determine whether a user should have access to a resource within a protected environment in the first place. It is the capability that handles the experience of a user requesting access to a resource and an administrator managing that access request. More specifically, application access management capability provides the request and approval system specific to requests for access to applications, along with the workflow and policy layer that enforces it and assigns applications administrators.

A good scenario where this capability can come in handy is coarse-grained access control for enterprise applications. For example, you could build a group-based and claims-based access control method and create some assets for FIM to tie this method into specific applications in the enterprise. The idea is that a user would request access to an application through FIM and an existing approval mechanism would either put this user in the appropriate group or give this user the correct attribute to enable access. 

Multi-factor authentication

Security and Identity management professionals generally agree that the traditional user name and password approach to authentication is no longer a viable option. There are too many ways this single credential can be compromised, and in many cases, the act of compromising these credentials is a relatively trivial affair and does not require a great level of expertise. One solution to this problem is to add more authentication methods to the basic user name and password credentials. Another option that is expected to be increasingly adopted in the future is to use alternative credentials only and not use user name and password at all.

The key factor in presenting a valid identity is that there needs to be an acceptable level of assurance that the credentials have some agreed upon fidelity with the user who is providing those credentials. There are two primary considerations when dealing with levels of assurance: proofing and the strength of the presented credentials.
For example, suppose an organization is considering allowing the use of a public credential (such as one derived from popular email or social networking sites). The organization does not control the password policy in this scenario. If the credentials for this public identity are stolen, the organization has no way of being made aware of this. In order to have a reasonable level of assurance, you would need a second or third level of authentication. Refer to the Public Identity Provider Federation section of this paper for more information on this issue.

The current trend is toward device-based two factor authentication. There are many device-based authentication options available on the market today. Some of these include:

There appears to be increasing interest in phone-based solutions, given the increasing uptake of smart phones in the user population today. The one-time PIN system appears to be making significant strides in the enterprise. The smart phone essentially becomes a one-time password generator. This is one of the reasons why Microsoft has recently acquired Phone Factor. For more information about Phone Factor, please see the PhoneFactor home page.

The advantages of using a phone as an authentication device is that users typically always have their phones on their persons, the phone can be locked to help prevent it from being used if it is stolen and can even be “erased” in the event of it being lost or stolen. On the other hand, not everyone has a smart phone. Therefore, if an organization is designing a MFA system for use by the public, there should be an alternative way to access the system that doesn’t require smart phone access.

One of the primary problems with device-based MFA is that they are expensive to acquire, issue, and maintain. Think about a public facing service provider – it would be cost prohibitive to have to buy smartcards for all of the users, not to mention the cost of distributing the cards and the certificate management costs associated with keeping them updated.

Public Identity Provider Federation

Public identity provider federation capability enhances an identity infrastructure with the ability to allow users to log in with accounts maintained by public identity providers. The advantage of supporting public identity provider federation is that you do not have to manage those public accounts. The public identity provider takes care of that. The disadvantage of supporting public identity providers in your identity alternative way to access the system that doesn’t require smart phone access.

One of the primary problems with device-based MFA is that they are expensive to acquire, issue, and maintain. Think about a public facing service provider – it would be cost prohibitive to have to buy smartcards for all of the users, not to mention the cost of distributing the cards and the certificate management costs associated with keeping them updated.

Public Identity Provider Federation

Public identity provider federation capability enhances an identity infrastructure with the ability to allow users to log in with accounts maintained by public identity providers. The advantage of supporting public identity provider federation is that you do not have to manage those public accounts. The public identity provider takes care of that. The disadvantageproducts and solutions is the lack of assurance that is inherently associated with a concept of a public identity.

Anyone can sign up for free Microsoft, Google, Yahoo!, Facebook, etc. accounts. In other words, if you want to prove that the user really is who they say they are, you as an application or a service provider must take on the burden of proving your users’ identities yourself. This can be very expensive to implement. Another disadvantage of supporting public identity provider federation is the lack of control over the password policies on the public identity providers. 

The National Institute of Standards and Technology (NIST) defined three levels of assurance for access control. These levels correspond to varying degrees of risk:

For example, for a level 3 application, you might want to allow a citizen, a resident of the state of Virginia to transfer a car title to another resident of VA. You do not want to manage credentials for these users and you allow them to log in with their public identities. How do you provide a strong enough level of assurance? 

One approach would be to place an enforcement layer between the user and the application, requiring the user to provide additional information about himself, such as a Social Security Number (SSN) or a combination of data facts, such as a SSN and home address before he can access the application.  This is the essence of the AEGIS solution created by Microsoft. Another approach might be to have your own public identity provider and require customers to pay to get an identity registered on it. The idea is that if you need a strong level of assurance for your application, you require your users to federate with your own identity provider. In theory (but not currently available in practice), you could partner with a local post office so that when a user registers  this public identity, the user’s home address will be collected and a letter with an access code to the application will be physically sent to the user’s home address.

Self-registration

Self-registration represents the ability of a user to provision an account either without or with minimal human intervention. In the case of minimal human intervention, but in this case it’s a checkpoint rather than having an administrator manually provision accounts for all users. Self-registration is required for onboarding users to support a service that can scale quickly and cost effectively. Self-registration can be used to create accounts that are unique for the system that the user wishes to access or the system can leverage existing identities through some form of federation.

Self-registration is necessary when you don’t know who all of the users are. For example, if you provide a public facing application, you might have people from all over world using the application, so there’s no way to know which accounts to provision ahead of time.

For example, consider the scenario where you are setting up a new service and you expect tens of thousands or even millions of users to register for the service. You don’t have the personnel or the money to provide human involvement in the registration process. Users will need to be able to provision their own accounts. What options are available?

The advantage of allowing users to self-register with an account maintained by another provider is that you don’t have to manage those accounts. The downside of this option is that you don’t have control over the level of assurance for that account because you don’t have access to their attestation system. Another disadvantage is that you have no control over how authentication is performed at the identity provider, so if you only want to use those identities in high assurance transactions you need to perform your own secondary authentication. This means you have to issue and manage secondary credentials for those users. It’s just as much (if not more) work than just issuing the users accounts directly.

For enterprise scenarios, self-registration may not be popular as it is for public services because a higher level of assurance is required before issuing corporate credentials. Users need to be able to confirm their identities before being entered into the system. This can be done by requiring the presentation of one or more government issued identity instruments, attestation by trusted individuals, or even matching biological markers such a fingerprints, retinal scans, or DNA patterns. Because of the level of complexity and the higher security bar, self-registration in an enterprise environment for access to proprietary corporate resources is not the norm.

However – it is possible for you to have a user self-register and get an identity that has a low level of assurance at the start. Then have the ns you have to issue and manage secondary credentials for those users. It’s just as much (if not more) work than just issuing the users accounts directly.

For enterprise scenarios, self-registration may not be popular as it is for public services because a higher level of assurance is required before issuing corporate credentials. Users need to be able to confirm their identities before being entered into the system. This can be done by requiring the presentation of one or more government issued identity instruments, attestation by trusted individuals, or even matching biological markers such a fingerprints, retinal scans, or DNA patterns. Because of the level of complexity and the higher security bar, self-registration in an enterprise environment for access to proprietary corporuser walk through a separate proofing process out of band that, once completed, you can up-level the user’s identity to a high assurance level.

An exception to this is when enterprises need to enable partner access to corporate resources. One option is to create accounts in the local enterprise identity provider system for each of the partner users who require access. This requires that the enterprises commit resources to provisioning and deprovisioning these partner accounts.

A better option is to take advantage of federated identities, so that partner accounts are “trusted” by the enterprise. In this case, the partner continues to manage the accounts in its own identity repository, thus lowering the management overhead for the enterprise.

 

Self-service Password Management

Self-Service password management enables users who have forgotten their passwords to gain access to a system or application by obtaining a new password without requiring assistance by the Help Desk. Self-service password management is also required when other conditions lead to the users being locked out of the system, such as when a security policy locks the user out of the system after a brute force attack is launched against that user account.

The key to self-service password management is that the users can do it themselves, by perform self-service password resets. This can significantly reduce Help Desk costs since the password reset request is one of the most common types of Help Desk calls. There are a number of ways the user can gain access to the password reset system. Some of these include:

Since the password is not available to the user, there needs to be a method in place that the self-service password reset system can use to authenticate the user with information other than the initial password. When the user account is set up during the account provisioning phase, the user will be asked a series of questions where it is assumed that only the user will know the answer. This might be a series of personal questions or a list of preferences. The knowledge based questions can be supplemented with biometric information. Other authentication could include a hardware device that generates a one-time password, an email that is sent to a predetermined account, or an SMS message. Any or all of these methods can be used as alternate authentication mechanisms.

There are significant security issues and concerns that need to be considered when designing a self-service password reset system. If the authenticators consist of a series of personal questions, it’s possible that the user will choose personal information items from the list of questions that turn out to be easily discovered by an intruder. This is even more problematic in this day of social networking, where people are inclined to share personal details with “friends” who they may actually know little about. Combine this with the fact that most organizations have some kind of standard that they use for naming user accounts, and an intruder can guess the user account name and the answers to the personal questions by doing a moderate amount of research.

The current trend in the enterprise space is in believing that the question/answer method of authenticating users for self-service password reset is not secure and cannot be thoroughly trusted and is considered to be a weak form of authentication. Thus, question/answer should not be thought of as being appropriate in an enterprise or corporate cloud environment. An increasing number of organizations are looking at tokens that provide one-time passwords, two-factor authentication, or SMS text based messages sent directly to the user’s phone.

Two-factor authentication should be strongly considered for self-service password reset. Similar to any other form of two-factor authentication, two-factor authentication in a self-service password reset scenario requires the user to use two methods of authentication in order to successfully authenticate before the password reset is performed.

Newer types of authentication that can be used in a self-service password reset scenario include forms of preference-based authentication. This can be implemented in a number of ways. For example, the users can be presented with a series of items and asked if the user “likes” or “dislikes” the object. The results of these preferences are stored in the system. Alternatively, the user might be presented with a graphic or photograph and instructed to click or touch on several areas of the picture. The user will need to reproduce this series of clicks or touches when a self-service password reset request is made. This preference-based model promises to be extended even more sophisticated and personalized way as touch enabled devices enable the use of gestures on the graphic presented.

 

Single sign-on (SSO)

SSO is a way of managing access control of various related, but independent software applications or services.  With true textbook SSO implemented in your environment, a user will log in once and gain access to all the applications and services within your environment without being prompted to log in again at each of them. It is important to not think of the SSO experience as a product, but rather as of the outcome of well architected solution that utilizes several products and technologies (Microsoft or third-party) to deliver this identity infrastructure capability.

There are a definite distinctions between a true SSO (also called integrated SSO) experience, a “same sign-on” experience, and a “capture/replay” user experience:

There are three ways to implement an integrated SSO experience:

There are many reasons for why customers are interested in implementing SSO. High password-related help desk costs and the need for shared workstation support are two of the major factors driving SSO implementations. However, the most deeply seated need for SSO is always about improving users’ convenience.

Almost all of the identity-related products that are developed at Microsoft have some relationship to SSO. When a customer requests to implement an SSO capability in their environment, the challenge is not what product or products to use in order to implement it. The challenge lies in accurately defining this customer’s requirements and expectations. Even more specifically, customer’s applications and other resources must be analyzed and a determination needs to be made of whether or not these applications are even capable of supporting a true SSO experience. If they are not, then first there are some application architecture discussions to be had with the customer.

When a customer requests you to implement SSO in their environment, you must first obtain detailed information on how that customer defines SSO. Is it truly an SSO experience that they want?

For example, an organization might think they want to implement SSO and in order to do that they consider buying Forefront Identity Manager (FIM) from Microsoft. (Or they might consider buying another product focused on synchronization of identity information, for example, Oracle Identity enge is not what product or products to use in order to implement it. The challenge lies in accurately defining this customer’s requirements and expectations. Even more specifically, customer’s applications and other resources must be analyzed and a determination needs to be made of whether or not these applications are even capable of supporting a true SSO experience. If they are not, then first there are some application architecture discussions to be had with the customer.

When a customer requests you to implement SSO in their environment, you must first obtain detailed information on how that customer defines SSO. Is it truly an SSO experience that they want?

For example, an organization might think they want to implement SSO and in order to do that they consider buying Forefront Identity Manager (FIM) from Microsoft. (Or they mManager or Tivoli Identity Manager, etc). FIM is not an SSO product, but it can provide some capabilities similar to SSO by enabling password synchronization. In this example, the goal is to explain to this organization that if they are indeed interested in deploying FIM, what they can achieve with it is the same sign-on and synchronized passwords experience. FIM will not help them implement a true, integrated SSO capability with their users signing in once and thereafter having access to all the applications and services within the boundaries of their environment.

The following are three common scenarios for which you might be requested to implement an SSO experience:

The main problem with implementing SSO is that it’s nearly impossible to do it without overhauling the majority of the existing applications and services in a given environment. Applications and service are usually written with authentication methods that are specific to them and unless you change those or bring all application authentication methods under either a single protocol or a collection of protocols that support transition, you will not achieve true SSO.  Updating applications and services is a big effort since they are usually written on multiple platforms and vary greatly. Also, there’s a good chance that a customer might have a few Commercial off the Shelf (COTS) applications that don’t support your SSO approach and there’s very little you can do to integrate those applications. If you had a single AD forest and if all of the applications were AD integrated, implementing SSO would be a relatively easy and straightforward task. However in the real world that is not the case because of the vast array of heterogeneity.

Summary

In order to create a well architected identity management and access control infrastructure it is important to understand the key identity and access control scenarios that most enterprise environments encounter today and are expected to encounter in the future. Microsoft identity architects have identified single sign-on, access control, self-registration, self-service password reset, application access management, public identity provider federation and multi-factor authentication as the critical identity and access control scenarios that most organizations face or will be facing now or in the near future.

In this paper we attempted to call out definitions for each of these scenarios, what the advantages and disadvantages of various solutions for each of these scenarios might be and what some of the constraints are revolving around each of these scenarios. We also discussed some considerations and mitigations for issues that are included in each of these scenarios. The discussions around each of them are intended to help you think about the salient issues that you will encounter when tackling these issues. We hope that you found this paper useful in helping you in your planning and design process for the identity and access control scenarios your organization needs to address both in the near and long terms.