Identity and access management is changing and so must strategies for managing it. Read up on IAM architecture approaches and how to select the best for your organization.
Things can sometimes be so foundational that they become difficult to see clearly -- or even invisible. Imagine a typical office environment, for example -- what do you see? There are likely chairs, desks, telephones and filing cabinets. These things are so foundational to what an office is that we don't usually stop to think about the fact that they're there.
Identity and access management (IAM) -- the discipline of ensuring the right individuals have access to the right things at the right times -- sometimes falls into this invisible group. IAM is so foundational to enterprise security -- and so important to the manner in which resources are protected -- that we don't stop to think about it. Like many technologies that have reached a high level of maturity, it becomes standard plumbing, performing its necessary and critical functions unnoticed -- unless there's a major problem.
Despite how placid the waters of IAM might seem on the surface, there are fundamental tidal shifts happening below. Consider how cloud has impacted identity, for example. Many cloud-based IAM strategies have emerged over the past few years, from identity as a service (IDaaS) to authentication as a service, as well as identity systems offered inside cloud environments. Also, think about how service-oriented architectures have affected IAM, including the creation and rapid adoption of a new authentication state transfer mechanism, Open Authorization (OAuth).
So many interesting changes have happened -- and are continuing to happen -- in the IAM space that it behooves organizations to pay attention. Likewise, technologies such as cloud affect IAM systems -- they can change how IAM mechanisms are used, what they are used for, when they are used and what technical capabilities are needed to accomplish enterprise goals.
Despite how placid the waters of IAM might seem on the surface, there are fundamental tidal shifts happening below.
That said, there are many IAM architectural standpoints that must be considered, including the different approaches, design principles and what to consider when evaluating the best option for your organization's specific business needs.
The evolving IAM architecture
From an architectural point of view, the design of most IAM implementations is relatively straightforward at first glance. Complexities only arise when the implications are considered and extended to particular use cases.
Consider the Open Security Architecture (OSA) project's design pattern for Identity Management, SP-010. OSA represents an open, collaborative repository for security architectural design patterns -- i.e., strategies that encapsulate systems in pictorial format for use by the community.
Figure 1. SP-010: Identity Management Pattern by OSA, licensed under CC BY-SA.
This is the diagram portion of the OSA IAM design pattern. Textual elements, which explain in more detail the conceptual view, description and other salient notes, have been left out for the sake of brevity and because most of these details are implied in the diagram.
A few assumptions are implicit in the diagram. First, it addresses multiple roles that interact with IAM components, as well as systems that rely on it. Second, it separates policy enforcement -- in this diagram, enforced at the server level -- from policy decisions, which are handled via the combination of the directory and authentication server. Lastly, it is built around the assumption that the organization owns and manages user identity.
This is a traditional design pattern, and it is important to note that some of its underlying assumptions are changing in the 21st century. There is the question of federation to external service providers, which can require separate infrastructure to set up and maintain. Then, there is the question of extending identity into the cloud, which, depending on the model employed, can either use state transfer -- for example, Security Assertion Markup Language (SAML) or OAuth -- to federate between on-premises and cloud or can use cloud-native identity providers directly.
There is also the question of who is being authenticated and for what purpose. The OSA diagram, while appropriate for internal employees, is clearly targeted to employees. Organizations today must maintain multiple identities beyond their employees -- for example, customers, application users, system administrative users and other types of users that aren't baked into the Open Systems Interconnection model. An organization employing a model like this for internal user authentication and access control could very well also have a production application that contains within it customer user accounts. This might be as sophisticated as a customer IAM platform (CIAM), or depending on the use, it could be as simple as a database table that contains application-specific user credentials.
While descriptive of how IAM has functioned historically, the OSA diagram is likely not particularly descriptive of how most organizations are doing IAM today. This is true both because of changes in how IAM is used for employees and because it doesn't address customer identities.
Differences in IAM approaches
If IAM methods are changing and legacy approaches are in a state of transition, how should enterprises select the best approach for their needs? There are a few things to consider:
What is the organization looking to do?
What is the scope?
Where is the source?
It is important to remember that IAM is a huge discipline. It includes several subdisciplines -- such as authentication, privileged identity management, authorization and access control, federation, role-based access control (RBAC) and state transfer -- that are required for successful operation.
There are also multiple different kinds of users, from customers and privileged accounts to service accounts, internal employees, business partners and more.
IAM tools
When building an IAM architecture, security teams must consider the various tools and features offered by those tools. IAM tools include password management, reporting and monitoring, access control, identity management, provisioning software and identity repositories. Features of such tools may include the following:
When selecting an IAM architecture, organizations must also consider the intersection points with environments -- and, in particular, sources of identity and identity providers -- that they themselves don't directly control.
When all this is considered, enterprises might end up with a different design than the OSA model presented above. For example, take two completely different models: a CIAM application versus an internal employee-centric one, such as that described above. In a CIAM application, there could be a UI component that resides in an IaaS provider or is implemented in a PaaS, as well as RESTful APIs that implement business logic. Within that context, a traditional authentication server and directory -- as illustrated in Figure 1 -- may be employed, or cloud tools, such as an external IDaaS provider, may be used -- illustrated in Figure 2.
Figure 2. Sample CIAM application using cloud tools
This approach, while using the same logical elements -- directory, policy enforcement points, policy decision points -- as the legacy on-premises model, employs them for a different purpose.
3 key steps to selecting an IAM architecture
Ultimately, to derive the best IAM architecture for its specific use cases, an organization will need to do some legwork. It will need to be clear about what it hopes to accomplish; who it will be authenticating and why; what applications its users employ; and where users are located. As these questions are being answered, pay particular attention to two elements:
SaaS applications hosted outside the enterprise environment; and
usage that presupposes identities not belonging to the organization.
The process can be broken down into three steps.
Step 1
Security teams should make a list of usage -- applications, services, components and other elements -- that they anticipate users will interact with. Consolidating this into a list helps validate with others in the organization that usage assumptions are correct. It can also be used as input into the product selection process when the time comes to evaluate if IAM mechanisms provide the needed capabilities.
Step 2
Think through how different environments -- like cloud SaaS applications and on-premises applications, such as domain login -- will be linked together. There are times different systems might be needed to accommodate different types of applications and usage. Getting an understanding of what other systems outside enterprise boundaries exist is useful because these systems might need to federate in specific ways. For example, cloud provider A might enable federation via SAML, while provider B does so via OpenID Connect.
Step 3
Consider carefully which specific areas of IAM are most important to the business. The following list of questions will help enterprises evaluate potential vendors and systems:
Is MFA needed?
Do customers and employees need to be supported in the same system?
Are automated provisioning and deprovisioning required?
