For the latest information, see http://www.technet.com/cloud
Download a Word .docx copy of this article from the TechNet Gallery
This paper is part of a two part series on Identity Management Architecture. The companion document is
Identity Infrastructure Capabilities - Managing Identity in the Age of Hybrid IT.
↑ Return to Top
The purpose of this document is to define and provide detailed conceptual information on the four fundamental pillars of identity that can be useful in creating a strategic direction for an identity infrastructure in your organization. Based on our knowledge
and expertise, we at Microsoft, believe that a strong, healthy, and flexible identity infrastructure must consist of processes, technologies, and policies that are derived from these four pillars. It is also our purpose to explore key industry trends related
to identity and access management and how you may apply them in your designs.
until recently that thinking has shifted and now considers device identity equally important. Currently there is a consensus that anything and everything that tries to enter a corporate environment from an external location, in other words, from outside of
corporate protection boundaries, must have an identity associated with it. Identity is a concept that spans an entire environment, from infrastructure to applications and services, and back to users and devices who try to gain access to these applications
Another important aspect of defining identity revolves around the issues of on-premises versus cloud computing. More and more, customers are maintaining traditional IT environments with identity on premises and at the same time starting to venture into setting
up and developing applications in private and public clouds, or adopting 3rd party cloud services. How do we unify identity across these different approaches, manage cloud identities synchronized with on-premises identities, foster a hybrid environment, and
ensure that access control is maintained? And while we’re at it, what is the definition of a hybrid identity? Right now various organizations have their own definition of what identity in a hybrid environment means, since the need is always different from
customer to customer and greatly varies between implementation to implementation.
Having a strong yet flexible identity story in your environment can make or break your business. It can either be a hindrance that keeps your organization from being flexible and cloud-ready, or it can make your organization nimble and adaptive to increasing
user loads and facilitate your transition to the cloud.
The importance of identity is highlighted by the following:
When you empower your users by providing them with self-service identity management capabilities, the cost of managing the identities can be reduced dramatically. For example, a new project is created and the project owner needs to share information and
access to project site with team members. With a robust identity management solution, the project owner can create the necessary security or email groups himself without engaging helpdesk or IT support. It makes your employees more agile and satisfied. But
you must remember to put the proper access controls in place.
You can use identity to take control of the access management infrastructure of all the resources within your organizational boundaries. There are thousands of applications and each application has a different security model. With the proper identity story,
you can unify access control for all those applications and thus save yourself a lot of time and yet always be aware of a potential danger.
For example, a rogue administrator might attempt to gain access to an application or a service within your environment. With a strong identity management architecture and design, you will be able to prevent or minimize the damage from such an event.
You want to move an in-house service to the cloud. But how can you move it into the cloud when all its data is in an on premises database? Do you also move the database into the cloud? How do you keep the data in sync between on premises and the cloud?
You need to be able to define identity in a way that allows you to plan for the future of Hybrid IT.
The following are some of the trends and challenges that Microsoft engineers encounter every day and that drive us to develop strong and flexible identity infrastructure solutions. Our constant goal is to provide our customers an identity story that can
expand and grow with these trends and challenges.
There are several industry trends that force us to reconsider out thinking around identity. These trends include:
As we become more connected while binding cloud and on-premises applications and services or connecting with partners and external organizations, there’s an avalanche of data that we must consume. It is not just identity data, but business, processes, and
analytics data. Once it is all assembled, we need to maintain access control to this data; keep it meaningful and make sure that redaction occurs. Coincidental with explosive data growth is the growing number of identities that will need to access large sets
of heterogeneous data. A single user account defined by pre-defined group memberships is unlikely to provide the rich and robust set of access control decisions that will be required.
Consider the current popularity of the "bring your own device" scenarios. In the years past, customers were not allowed to bring smartphones and tablets to the infrastructures that we built because these devices were not managed by corporate IT and therefore
could not be trusted on the protected corporate network. Yet now we are encouraging our customers and users to use their own devices. We need to define and manage an identity story for all these different devices. We need to make authentication and authorization
decisions based on a device type. We need to determine what level of granularity should be required, and we need to determine what changes need to be made at the level of network access devices, server access controls, and application access controls.
Corporate IT is always expected to do more with less. If we can enable you to spend less money on identity and infrastructure, in other words, provide you with processes and tools that just work, we consequently enable you to invest more time and effort
on your company mission, on growing your business, and growing the careers of your company’s employees.
The following numbers represent the way in which IT departments in most companies organize their expenses:
Therefore when a new capability (an application or a service) comes along, if we expect to spend some of that 14% on building a new identity and access control system on top of their infrastructure to support this application or service, we probably will
not be providing that customer with the capabilities they need in order to overcome current IT constraints. They will instead plug in whatever available application or service they have or need into their existing identity story.
Cloud computing and its variants such as Hybrid IT introduces a number of access control challenges that are either new or lend themselves to recasting traditional issues in order to insure that access is secure. These include:
One of the primary access control challenges is the enabling of secure access for users with various managed and unmanaged devices. When a new user with his variety of devices is introduced to an on premises environment, there is a great need to ensure that
this user’s devices are trusted. When thinking about enabling device access for application and services, there are multiple factors that comprise the trust level for a device, such as whether the device is managed versus unmanaged, has current anti-virus
signatures, or is located in a specific place. Access control decisions in the future must consider the totality of the computing environment of the client device.
High availability can wreak havoc on access control. When building an identity management and access control solution, you need to consider what level of availability is required and how to manage that availability. Do you use completely redundant hardware
or do you forsake hardware redundancy for cloud-based software resiliency? You need to consider what level of tolerance you are willing to accept a for service outage. If you depend on third-party identity providers, you need to know what their historical
levels of availability have been, their mean time between failures and mean time to restore service.
Role-based access control is increasingly necessary in a complex identity management environment. There can be both organizational role-based access control (RBAC) models and application-specific RBAC models.
With organizational models, the roles are aligned to the hierarchy of an organization. In an application-based RBAC model, the roles are application-specific and align to specific functionality inside the application. There can be a mixture of both, where
application roles map to organizational roles. Another aspect to consider when we think of RBAC is managing not just the roles of users, but also the roles of the devices since they also have identities associated with them.
User-based roles can be tied to a multiplicity of attributes. Some of these include:
Similarly, device identity can be defined in a number of ways:
All of these attributes and more can be used to determine user and device access.
Why is external-facing identity infrastructure, or in other words, allowing customers and partners who are not within your organization to access applications and services within your environment, a challenge? Because most organizations build their applications
for internal use only.
For example, a company might deploy a SharePoint site on premises with the intention that only the internal, corporate users will be granted access to it. However, all too often they find that suddenly they need to onboard a partner and share their SharePoint
site or some other network applications with someone from outside the organization. The problem quickly becomes apparent that the application or the site was not written for inter-organization collaboration. It was written to authenticate users against an
internal database that is specific to this application or site.
This leads to you needing to consider the following:
These are just a few of the options you might have to consider.
Identity management challenges include new and evolving requirements based on sea of changes in the quickly evolving computing landscape. These include:
Identity management related issues have been seen as a potential deployment blocker for moving applications into the cloud. Not only do you have to move the application, but you often have to move the identities and the identity infrastructure as well. This
introduces issues with keeping the data in sync and ensuring that the same entitlements and access controls are applied across on-premises and the cloud.
This introduces several important questions to answer when architecting an identity management solution for cloud applications:
These are some of the more important issues that you will need to consider when assessing identity management requirements in a cloud application scenario.
The last thing you want is to have a highly scalable application and resource model and an identity story that hinders scalability. If you scale your applications to the cloud and yet you don’t have an identity management system that is similarly scalable
to support these cloud-based applications, suddenly no one can log in to them. Such scalability requires that on-boarding new accounts be done quickly and with the least amount of overhead possible. This will require a significant amount of automation and
user self-service. Your identity story must facilitate this management challenge and not hinder it. You must make sure that your identity story is flexible and can grow with the needs of an application or service that are based on the current industry trends.
With the increasingly common scenario of mergers and acquisitions, you will need to consider what some of the challenges are when two completely separate organizations and their infrastructures are expected to come together and act as one.
The most common challenges are:
When the separate organizations started building their environments, they did not anticipate the day when they will merge to be the same company and therefore, have a need for a unified directory, or that all their applications and services will need to
access data from a foreign directory service.
As organizations onboard more users and hire more employees, and as people come in and as companies grow, so will the number of identities in their directories. The challenge with the proliferation of groups and users is to manage all these identities and
yet keep a relatively small footprint when it comes to the cost of access control cost and operations.
There are a number of security challenges to consider as well. Some of these include:
If a problem occurs, you need to know who caused it (identity), when did it happen, and how the trouble-maker or trouble-causing device got access. And you need to have all these answers fast.
When you extend the boundaries of your organization to the cloud or other partner organizations, having a cohesive identity story that properly identifies and manages the lifecycle of users, and properly controls access is extremely important to the security
story. In particular, when you extend your boundaries, your infrastructure inherently becomes more vulnerable. Not only do people have to be properly identified, but there needs to be a good handle on the entitlements they have and how they got those entitlements.
A centralized and standardized identity story guarantees tighter security which is always handy, especially in the case of mergers and acquisitions.
The reporting and auditing elements of an identity infrastructure are often neglected in many companies. Yet having a reliable and detailed reporting and auditing system in place will most definitely guarantee better identity security.
Based on our experience and customer interaction, Microsoft defines identity in four distinct but related pillars:
There are a number of definitions you can use for administration. In the context of this discussion we define administration as being about creating an accurate view of a user’s identity with the goal being a centralized view of the users or computer’s identity.
However, just because the view of a user’s identity is being centralized does not mean that there is only one view. The reason for this is that the nature of a user’s or computer’s identity can change based on context.
For example, a user’s identity might be one thing between 9AM and 5PM and quite different during non-working hours. In a similar fashion, the nature of a device’s identity might be different based on location or based on who the currently logged on user
might be or be based on the ever changing state of the device’s security status or configuration. We can have a centralized view of an identity while realizing that the object’s (either user or computer or service or any other entity) identity is in flux when
we think about the attributes and entitlements associated with that identity.
Identity provisioning is an important capability to consider when architecting an identity solution. Provisioning can include activities such as updating and synchronizing identities. You also need to consider:
You should avoid enabling any change in your identity management systems to propagate immediately. You should be able to leverage some level of control over that identity in terms of how the change is implemented and how it proliferates throughout your systems.
Many network administrators go directly into their directory service and edit the user’s identity directly. From a Microsoft identity infrastructure perspective, many go right into the Active Directory Users and Computers console and change a password without
any other actions. But there are some problems with this approach:
As you can see, there is no change control when users go directly to the identity store to make updates. You can’t determine who made the change and why, so it throws off your compliance reporting and bypasses any attestation controls that you may have
in place. All of these issues make it clear that a key attribute of good identity management is change control.
This direct “go in and edit the identity attributes directly approach” doesn’t allow for the changes to go through any change control system. This is manual change control. There’s nothing in a manual approach that tracks what happened in a way that you
can provide a report on. Such reports might be required in the case of an incident, where part of the forensics process will require such a report.
However, you could support the direct edit approach by synchronizing that change into central system for audit and report. Think about an HR system and the HR administrator updates a user’s department or title. That would be allowed and can be tracked in
a central administration location. You then have the option of support both direct edit and centrally managed and governed edit in this case.
Finally, there is the issue of entitlements in identity management. Topic level concerns include:
If you can understand how the entitlement was granted to a user, and then you see how it’s being used, and have a system that tracks granting and removing entitlements, then you can tell a cohesive story when you need to audit that user and the events that
lead to the user’s access to a system or a service within a system.
The authentication pillar tells the story of how much assurance for a particular identity is enough, in other words, how much does an IT system need to know about an identity in order to have sufficient proof that they really are who they say they are?
The very complex authentication pillar can be broken down into three sections:
Authentication strength can be expressed as the quantity and the complexity of the proof factors of a particular identity. The classic case is a knowledge-based proofing of a user secret (the user name and password). Current trends are moving towards more
proof factors and more complex proof factors. In the early days of application building, when applications came with their own databases for users and the passwords that were tagged to these users (in other words, application-specific identities), usernames
and passwords were stored in clear text and users were authenticated via a string comparison.
Security practices and identity control systems have become more sophisticated over the years. For example, most organizations no longer use LDAP binds for authentication, at least not without SSL, because it is the equivalent of sending un-encrypted passwords
over the wire. Over time, organizations moved on to using NT LAN Manager (NTLM) protocol with its challenge and response functionality. Instead of sending passwords over the wire, organizations started sending hashes. And then organizations got even smarter
and started using asymmetric cryptography, Kerberos, and private keys.
The current trend is multi-factor authentication – an approach which requires that the user provide more than one form of verification in order to prove their identity and be granted access to the system. How many factors do you need to ensure the strength
of the authentication? How many is just enough? The problem with multi-factor authentication is that it can become very expensive, and the customers who want to implement it, must buy tokens and manage (issue or revoke) those tokens and their certificates.
To implement multi-factor authentication properly and securely, you must do it yourself and there is no way to avoid very high maintenance costs of issuing and managing tokens. However, there are other options. One of the most frequently used approaches
in authentication evolution is a one-time password (OTP). OTP is popular because it’s inexpensive to implement, the idea being that a user can authenticate via a very common device which they most likely already have, like a phone.
Authentication delegation is establishing a trust with another organization that will provide you with an authenticated and validated-federated identity. Authentication delegation has its pros and cons. One of the pros is - you do not have to manage your
For example, if you have established an authentication delegation trust with Contoso and you have a customer who is a Contoso employee, and that person’s employment with Contoso is terminated, you do not need to manage that person’s identity and revoke his
access to your environment. Contoso’s decommissioning process will take care of that. One of the cons, however, is that authentication delegation does not necessarily make your identity story stronger. In fact, if implemented improperly, it can weaken your
With authentication delegation it is all about the trust and just how strong and secure the trust mechanisms are since when you implement authentication delegation, essentially you are:
Therefore it is highly recommended that you couple authentication delegation with strong authentication assurance, for example, multi-factor authentication, asymmetric cryptography, etc.
What is the experience that your users incur as they try to gain access (sign in) to your applications or services? Some organizations provide their users with a disjointed sign-on experience, where users have multiple credentials, multiple passwords and
have to log in to applications and services over and over, time and time again.
There are tools like LastPass that attempt to solve this problem by storing all those credentials in a single place. There are also more enterprise-ready solutions that store usernames and passwords to applications and services and allow users to have a
single sign on experience even if the remote systems still have different credentials that need to be managed and maintained.
Other companies provide their users with a global (same) sign-on, where a single username and password is replicated throughout all of the identity stores but users still have to enter their credentials every time they try to access an application or a service.
Global sign-on, with its single set of credentials and multiple authenticators is an improvement over disjointed sign-on.
There is also a reduced sign-on experience that can be achieved by moving most of the applications to one or two authenticators, thus guaranteeing single sign-on to most of the applications.
And then there is the elusive, but highly prized goal of gaining access to your environment, the single sign-on (SSO) experience that leverages just one identity and thus enables your users to log in once and then never being asked to provide their credentials
again. Many people think that they can simply buy a product and get the SSO experience as a result. There are SSO-oriented identity products available but they do not solve the entire SSO problem. That is because SSO itself is not a product.
The SSO experience is an outcome of a well architected identity solution and today, there are three ways to implement it:
The authorization pillar is about enabling an application or a resource to make the best decision possible. In other words, authorization means processing the incoming identity data in order to decide what an identity should be able to do within the application/service
that it wants to access. Authorization mechanisms can be very application-specific and built into an application or be completely abstracted from an application. SharePoint is a great example of an application with a strong built-in authorization capability.
And yet it’s this built-in authorization that undermines the strength of SharePoint’s identity management and access control capabilities. We must start abstracting access systems from the applications and moving them to a central system.
Authorization can be either coarse-grained or fine-grained. It is a common mistake to think of coarse-grained authorization in terms of URL access, or in other words, to define coarse-grained authorization as being able to access URL 1 but not URL 2, even
if both URLs are in the same application. Coarse-grained authorization means brokering access to an application as a whole and making the decision on whether an identity can get access to an application or it cannot. Properly implemented coarse-grained authorization
is completely abstracted from your application. In fact, in the best of coarse-grained authorization architectures, the application isn’t even aware that coarse-grained authorization is being applied on its behalf.
Fine-grained authorization is implemented in layers within the application or service. For example, URL-based authorization for an application can be fine-grained. Fine-grained authorization is operation-specific. For example, if a user wants to run a particular
function when they click on a button, you can use fine-grained authorization to determine whether they should be allowed to do that. More specifically, fine-grained authorization is essentially application-centric authorization. The application defines how
the users are authorized to do certain things inside the application. This will vary from application to application and can be a range of methods from URL-based authorization to method-based authorization within the application.
Every system needs both coarse- and fine-grained authorization. Coarse-grained authorization needs to live outside applications and services and fine-grained authorization needs to live within.
There are four ways in which you can implement authorization (both coarse- and fine-grained):
The most commonly overlooked pillar in almost every identity solution is the auditing component. The most likely reason for this is the complexity and enormity of the problem and one of the key reasons why organizations implement identity management solutions.
The most difficult issue to deal with is related to that fact that there is log data in multiple locations – web service logs, event logs, custom logs and an ever increasing number and types of logs. One could say that logging has become almost ubiquitous
and the size of the problem will grow with the coming cloud computing era. Given the vast number and disparate nature of these logs, you have to consider how easy (or difficult) is it for you to harvest, process, and filter that data.
This is even more of a problem when you participate in a federation with other organizations. It’s difficult to correlate audit trails across organizations. You need to consider the legal issues involved when it comes to accessing partner log data. In order
to solve these legal and operational problems, you should have explicit agreements with partners regarding log sharing. This includes what logs can be accessed, who in each organization can see the other organization’s logs, how long the wait time is to access
the logs, and log retention policies.
Another problem that you will encounter is due to the nature of the data that you have in those logs. The information could be erroneous (because it had been tampered with), heterogeneous or just undocumented. You can have some logs that contain very superficial
information and other logs that contain multiple levels of complex information that goes many layers deep.
When it comes to identities, you should not be concerned about trace logs that contain error information. What you want to look for in audit logs is detailed information about what a person did over time. For example, you might want to find out what time
the user authenticated, what IP address the authentication was from, and which applications the user attempted to access once they were already authenticated.
What does auditing look like when you move towards doing it in a more effective way? What you want to know is:
You will need a way to capture this data. In most cases some component of the system will have captured some or all of this information. The problem is that the log information is contained in disparate systems, which makes it very difficult to get a holistic
view of any particular access event. You need a way to bring all this information into a centralized location or system so that you can then leverage this data by feeding it into an integrated reporting system.
Alerting is another important consideration for efficient and effective auditing. If something important happens within the system, you need to be notified. There are some good point solutions available at this time, such as with System Center, which will
provide alerts if administrative access is abused or misconfigured on a server. The goal is to create an auditing solution that can help you maintain your standards so that it can tell your organization that “this person shouldn’t have access, an alert is
triggered and there was then some sort of remediation to the problem”.
You will need to address Governance issues and reporting in your identity management architecture. Most organizations would like to take a policy module and just apply it to a server. Many organizations have complex governance and regulatory requirements
that require certain types of audit information be retained for certain periods of time. Some of the regulations, such as PCI, lack specificity and can implemented in a way that is open for interpretation. Therefore, when considering policy modules, you need
to have an architectural framework that you can draw on when making decisions about the specific controls within the module.
Finally, you need to consider issues around data collection. As mentioned earlier, log data is located virtually everywhere in the data center and across public and private clouds. That log data will likely become even more distributed in a cloud infrastructure,
where the principles of cloud computing drive a service provider’s approach, an approach that requires rich logging and auditing so that the principle of continuous improvement can be instantiated.
The problem with aggregating diverse log information gets even complex when dealing with heterogeneous systems. Microsoft’s System Center offerings can be used to accomplish this goal, even with heterogeneous systems, but it does take a lot of work to get
to a place where you will be able to come up with a workable solution. In order to reach the place you want to be when it comes to auditing in your identity management system, you will need to find a way to aggregate this information.
In this paper we began with a discussion on the importance of identity and access control in the current world of enterprise computing and the evolving world of cloud computing. That new world will also include hybrid scenarios where on-premises enterprise
infrastructures will need to connect with public or private cloud resources and enable identity management, authentication, authorization and access control decisions to be made at all layers of the enterprise and cloud stacks.
Industry trends are forcing organizations to do more with the same resources and new trends in identity and access controls are making the jobs of all network security and identity architects and engineers increasingly challenging. Current infrastructure
designs were based on a firm delineation between on-premises corporate identity and external identities. However, there are now modern exigencies that force organizations to expand beyond traditional methods of identity provisioning, identity management, authentication,
authorization and access control so as to require a significant retooling effort. Much of this is due to the explosive growth of the “Bring Your Own Device” phenomenon and other important megatrends in the industry.
Organizations of today and those of the future will be able to address these identity management challenges by fully understanding the principles, concepts and patterns that are embodied by the four pillars of identity. The pillars of Administration, Authentication,
Authorization and Auditing, the “four A’s” of identity, can guide your identity management systems planning, design, deployment, management and operations processes. We believe that only by fully addressing each of these four pillars can a comprehensive and
robust identity and access control solution be put into place.
The challenges are significant, but they are not insurmountable. The key is that as part of an overall security solution, approaches in identity management and access controls must continue to evolve and that you need to consider identity and access control
solutions as part of the ever changing security landscape. We hope that this paper helped you understand that landscape and that it will provide you with some tools to help you take more control over your identity and access management challenges.