The Four Pillars of IdentityIdentity Management in the Age of Hybrid IT

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

1 | P a g e

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This white paper is for informational purposes only. Microsoft makes no warranties, express or implied, in this document.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2013 Microsoft Corporation. All rights reserved.

The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred.

Microsoft, BitLocker, Hyper-V, SharePoint, Windows PowerShell, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

2 | P a g e

Table of ContentsDefining Identity and Identity Infrastructure...............................................................................................5

Importance of Identity.................................................................................................................................5

Identity Can Empower Your Users.......................................................................................................6

Identity Enables You to Take Control...................................................................................................6

Identity Enables You to Plan for the Future.........................................................................................6

The Impact of Identity.................................................................................................................................6

Industry Trends........................................................................................................................................6

Explosive Data Growth........................................................................................................................6

Proliferation of Devices.......................................................................................................................7

Budgetary Concerns............................................................................................................................7

Other IT Constraints............................................................................................................................7

Access Control Challenges.......................................................................................................................7

Secure Access for a Wide Array of Devices..........................................................................................8

High Availability...................................................................................................................................8

Role Based Access Control...................................................................................................................8

Customer and Partner Access to Data.................................................................................................9

Infrastructure Management Challenges..................................................................................................9

How to Adapt Current Identity Infrastructures to Work with Cloud Scenarios..................................10

On-boarding large number of users...................................................................................................10

Handling Mergers and Acquisitions...................................................................................................10

Reduce the Impact on Expanding Users and Groups.........................................................................11

Security Challenges................................................................................................................................11

Rapid Response.................................................................................................................................11

Protecting While Extending...............................................................................................................11

Centralize and Standardize................................................................................................................11

Report and Audit...............................................................................................................................11

Four Pillars of Identity...............................................................................................................................12

Administration.......................................................................................................................................12

Identity Provisioning..........................................................................................................................12

3 | P a g e

Change Control..................................................................................................................................13

Entitlements......................................................................................................................................13

Authentication.......................................................................................................................................14

Authentication strength....................................................................................................................14

Authentication delegation.................................................................................................................15

End-user experience..........................................................................................................................15

Authorization.........................................................................................................................................16

Coarse-Grained Authorization...........................................................................................................16

Fine-Grained Authorization...............................................................................................................16

Implementing Authorization Schemes...............................................................................................17

Auditing.................................................................................................................................................17

Trace Logging versus Identity Logging...............................................................................................18

Alerting..............................................................................................................................................18

Governance Reporting.......................................................................................................................18

Data Collection..................................................................................................................................19

Summary...................................................................................................................................................19

4 | P a g e

Defining Identity and Identity Infrastructure 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.

An identity infrastructure is a collection of processes, technologies, and policies for managing digital identities and controlling how identities can be used to access resources. The industry formerly thought of identity only in terms of users. It wasn’t 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 and services.

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.

Importance of IdentityHaving 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:

Identity Can Empower Your Users Identity Enables You to Take Control Identity Enables You to Plan for the Future

5 | P a g e

Identity Can Empower Your UsersWhen 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.

Identity Enables You to Take ControlYou 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.

Identity Enables You to Plan for the FutureYou 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 Impact of IdentityThe 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.

Industry TrendsThere are several industry trends that force us to reconsider out thinking around identity. These trends include:

Explosive Data Growth Proliferation of Devices Budgetary Concerns Other IT Constraints

Explosive Data GrowthAs 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

6 | P a g e

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.

Proliferation of DevicesConsider 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.

Budgetary ConcernsCorporate 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.

Other IT ConstraintsThe following numbers represent the way in which IT departments in most companies organize their expenses:

66% of all funds is spent on running the existing capabilities, in other words, keeping the lights on 20% of all funds is spent on growing the existing capabilities and making them more mature 14% of all funds is spent on transforming their environments, in other words, introducing new

capabilities into an environment

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.

Access Control ChallengesCloud 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:

Secure Access for a Wide Array of Devices High Availability Role Based Access Control

7 | P a g e

Customer and Partner Access to Data

Secure Access for a Wide Array of DevicesOne 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 AvailabilityHigh 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 ControlRole-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:

What team is that user on at this time? What division of the company? What projects are the users working on? Is the user part of the management team or is he or she non-management? What is the level of trust that the company has for that user?

Similarly, device identity can be defined in a number of ways:

What operating system is the device running? What is the device’s patch level? Is the device on a private or public network? What networks has the device been historically connected to?

8 | P a g e

Is the device a single user or multi-user device? Does the device have a history of compromise? What is the device’s degree of portability? Is the device encrypted? Does the device require a strong password to access the system?

All of these attributes and more can be used to determine user and device access.

Customer and Partner Access to DataWhy 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:

How will you inject external identities into an internal application or into an internal process Will you federate your two private identity repositories or just mirror accounts Do you need to create dedicated accounts in your organization that you need to manage Do you want to create a partition in your identity infrastructure that your partners can manage Do you want to create a dedicated identity infrastructure to support the single application Do you have a process or a mechanism in place in the event that you have tens or hundreds of

partners that need to be on-boarded Do you want to migrate your application to a cloud service and how each organization maps

corporate accounts to a third party identity provider

These are just a few of the options you might have to consider.

Infrastructure Management ChallengesIdentity management challenges include new and evolving requirements based on sea of changes in the quickly evolving computing landscape. These include:

How to adapt current identity infrastructures to work with cloud scenarios On-boarding large number of users Handling mergers and acquisitions Reduce the impacts on expanding users and groups

9 | P a g e

How to Adapt Current Identity Infrastructures to Work with Cloud ScenariosIdentity 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:

Should you make your applications transparent both on and off premises as a service? If you have an application that is 100% on-premises, how do you move it to the cloud in order to

make it more available or to take some of the load off of your infrastructure? What happens if your identity infrastructure is still fully on premises, but your applications are

now in the cloud? Have you established a way to connect your identity infrastructure and those applications? Will you use established connectivity mechanisms such as site to site VPN? Does the cloud service provider enable a dedicated link between your cloud service and your

on-premises identity infrastructure? Will you need to assess if there is some out-of-band mechanism for synchronizing identities or

perhaps a combination of in- and out-of-band solutions?

These are some of the more important issues that you will need to consider when assessing identity management requirements in a cloud application scenario.

On-boarding large number of usersThe 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.

Handling Mergers and AcquisitionsWith 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:

Application overlap Differences in identity schemas

10 | P a g e

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.

Reduce the Impact on Expanding Users and GroupsAs 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.

Security ChallengesThere are a number of security challenges to consider as well. Some of these include:

Rapid Response Protecting While Extending Centralize and Standardize Report and Audit

Rapid ResponseIf 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.

Protecting While ExtendingWhen 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.

Centralize and StandardizeA centralized and standardized identity story guarantees tighter security which is always handy, especially in the case of mergers and acquisitions.

Report and AuditThe 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.

Four Pillars of IdentityBased on our experience and customer interaction, Microsoft defines identity in four distinct but related pillars:

Administration

11 | P a g e

Authentication Authorization Auditing

AdministrationThere 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 ProvisioningIdentity 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:

Issues revolving around workflow and change control when it comes to updating and synchronizing identities.

The handling of requests and approvals

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.

12 | P a g e

Change ControlMany 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:

There is no formal change control in this process There is no mechanism in place that will allow you to know in the future who updated the

identity attributes There is no mechanism in place that will allow you to know in the future why were the attributes

updated There is no mechanism in place that enables a time-out for a particular attribute change

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.

EntitlementsFinally, there is the issue of entitlements in identity management. Topic level concerns include:

Processes need to be in place that determine how a user is entitled to access an application or other network accessible resources

Processes need to be in place that track how users exercise their entitlements Processes need to be in place that manage entitlements

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.

13 | P a g e

AuthenticationThe 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 Authentication delegation End-user experience

Authentication strengthAuthentication 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 delegationAuthentication 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 users’ credentials.

14 | P a g e

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 identity infrastructure.

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:

Trusting another organization to verify the users’ identities when they issue credentials Trusting the security mechanisms of the other organization to ensure that there is no rogue

administrator that can pose as a valid user for your application Trusting that the other organization is retaining all of the audit logs and will cooperate with you if

you need to correlate activities in order to determine the root cause of a security incident Trusting the identity management system of the other organization to ensure that any entitlements

for your application are legitimate

Therefore it is highly recommended that you couple authentication delegation with strong authentication assurance, for example, multi-factor authentication, asymmetric cryptography, etc.

End-user experienceWhat 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 disjoitned 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

15 | P a g e

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:

Establish a central token issuer (a directory) for all applications in your environment, for example, Active Directory (AD). Note, however, that being integrated with a directory does not necessarily grant you SSO. In order to implement SSO, the authentication protocol and the client both have to support SSO. You can implement SSO with AD as a central token issuer because AD uses Kerberos, which is a protocol that is conducive to SSO. Many other available directories use LDAP binds for authentication and therefore are not conducive to SSO.

Use a credential forwarder, in other words, place something in front of the application or a service to collect the credential and then respond with the appropriate protocol in the backend.

Use the protocol transition approach, for example, take a SAML token and turn it into a Kerberos ticket.

AuthorizationThe 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.

Coarse-Grained AuthorizationAuthorization 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 AuthorizationFine-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

16 | P a g e

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.

Implementing Authorization SchemesThere are four ways in which you can implement authorization (both coarse- and fine-grained):

Role-based authorization – defining roles either at an organization level or inside an application or service and making sure that those roles are applied consistently across all applications and services.

Attribute-based authorization – using attributes (bits of information) about the user in order to grant permissions.

Policy-based authorization – making a determination about whether or not the user should be able to access a resource based on the defined policy, the attributes of the resource, and the attributes of the user/session.

Risk-based authorization – using a mechanism that 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. As a result, the assurance level of the identity might be adjusted on the fly – for example, if there’s a high risk that the identity seeking access to a resource is not really who they say they are, then you may increase the authentication strength in order to authorize this identity to the application.

AuditingThe 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

17 | P a g e

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.

Trace Logging versus Identity Logging 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:

Who had access to what resource When did they access the resource What did they do when they accessed the resource What happened after the fact – what were the lasting effects of the access How was the user granted the entitlement that enabled him/her to access the resource

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.

AlertingAlerting 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”.

Governance ReportingYou 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.

18 | P a g e

Data CollectionFinally, 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.

SummaryIn 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.

19 | P a g e