This article is part of the Identity and Access Management Security School lesson on building an IAM architecture. Visit the Building an identity and access management architecture lesson page for more learning resources.
The terms identity management and access control are found together in many product suites. However, while identity management has made great strides in maturity and acceptance, access control seems to be stuck in a holding pattern. In the past few years (since Sarbanes-Oxley compliance came to the fore), identity management has become a popular process improvement and technology initiative in many large organizations. It seems natural that these same organizations look to technology to help control access to resources based on the identities they manage.
Public companies faced with the challenge of managing provisioning and recertification of employees' accounts across a wide range of systems have looked for solutions to automate much of the hard work of enforcing process controls and capturing audit trails. Identity management products have come to the rescue. They help companies design and carry out approval workflow, automate administrative tasks and consolidate much of the reporting that regulations require.
Unfortunately, access control solutions do not provide the kind of help that these identity management products do. While identity and access management products sound like a marriage made in heaven, they often have less to do with one another than one would think. Access management products often provide rich mechanisms to manage groups, roles and privileges, but tend to focus on controlling access only to resources that can be addressed by URL. In other words, most of these products help to provide access control on Web resources.
This is a good start, but it doesn't cover the plethora of resources that live in applications that are not URL addressable.
In order to understand what these products can and cannot do, we need to decompose access management solutions into the components that comprise them and understand how these components relate to identities.
When a user attempts to gain access to a resource like a file, a record in a database or a Web page, there are four different models at work:
- There is the identity of the user. Identities are collections of information gathered under a unique identifier (like a user name) for a particular context (like your corporate Web environment). This is typically stored in a directory like LDAP, Sun Directory Service or Windows Active Directory that can be managed by an identity management service.
- There is the authentication of the identity to the service managing the resources. This service can be provided by authentication services like Kerberos, basic authentication or public key mechanisms built into SSL.
- There is a mapping of the user identity to privileges or roles. This is usually part of an authorization service. Here again, authorization services are built on top of one or more directories.
- And, finally there is the access control on the resource itself. This is where it gets complicated. Access control has traditionally been provided by the applications that manage the resources.
So, if you developed a Web application, it was incumbent upon you to authenticate the user and carry out the checks to ensure that only authorized users got access to the appropriate Web pages. This is a perfectly acceptable model in theory, but it leads to a number of problems:
- Inconsistency: Different developers create different access role and access control models, which can lead to user confusion and attendant security problems.
- Complexity: Multiple implementations of authorization code lead to more bugs, also leading to security vulnerabilities.
- Unmanageability: When each application is responsible for its own security components, it can be almost impossible to manage the roles and access controls across the many applications in the enterprise.
Enter gateway-oriented access management systems. Products from Tivoli, Sun, CA and others help to implement an enterprise authorization model and alleviate the three problems by externalizing most of the access management services from the applications. First, they allow organizations to use identities from enterprise directories. Second, they support multiple authentication providers, allowing companies to use mechanisms like tokens, smartcards, passwords or Kerberos according the needs of the environment. This flexibility in authentication also helps organizations to support single sign-on across multiple applications. Third, they allow applications to use groups and roles from enterprise authorization services. Fourth, they introduce a new gateway component that intercepts application resource access attempts and executes access control checks to ensure that only authenticated and authorized requests reach the application. This function is the heart of the gateway authorization model and, in short, takes the application out of the security business.
These products address the three problems above by having a single, consistent, professionally and securely implemented authorization system that can be centrally managed. Sounds like nirvana. Unfortunately, this gateway model only works when the gateway can intercept requests destined for the application, recognize the resources being requested and make an access control decision on behalf of the application. The model works well for Web applications, but not so well for more traditional applications that do not express their resources and activities in a Web-compatible manner or that need to support a more complex authorization model.
All is not lost. While one might be tempted to throw up one's hands at the incompatibility of gateway authorization with a large class of applications, it is better to solve some of the problems with centralized access management systems than abandon the problem altogether. Many organizations have realized that they can address many of the problems of access management by integrating their application authorization mechanisms with the enterprise identity and access management solution. In other words, companies are using the identities, authentication services and roles defined in the centralized system when they make access control decisions in applications. This is a significant accomplishment.
Some organizations that have the development skills and resources to apply to the problem have gone a step further and developed authorization libraries that applications can use to ensure consistency of the access control checks and manageability of the access controls on resources. This is no small task, but has worked well in many large environments.
Identity and access management systems provide valuable services to organizations trying to comply with regulations and do a better job administering the accounts and access controls throughout their environment. However, there is no silver bullet that will address the problems of access control across the entire enterprise. The solution that has worked well for many organizations is to address Web applications with gateway-based solutions and handle the identity, authentication and privilege aspects of more traditional applications using the centralized identity and access management services. Eventually, we may see rich authorization services that more traditional applications will use, but we haven't seen any significant move in that direction, yet.
About the author
Dick Mackey, ISACA, CISM, is a principal with consultancy SystemExperts. He is regarded as one of the industry's foremost authorities on distributed computing infrastructure and security. Mackey has advised leading Wall Street firms on overall security architecture, virtual private networks, enterprise-wide authentication, and intrusion detection and analysis. He also has unmatched expertise in the OSF Distributed Computing Environment. He has been a frequent speaker at major conferences such as Information Security Decisions and has taught numerous tutorials on developing secure distributed applications.