In this blog post we will discuss how you can rethink and redesign your Identity and Access Management (IAM) architecture by implementing PBAC (Policy Based Access Control) as a central service. This architectural change allows organizations to improve their security posture, decrease risk and become more agile.
Not only should this PBAC service support one specific set of applications but rather act as a focal point (or a “brain” if you like) for different IAM technologies to provide dynamic access control to a diverse and larger set of applications and platforms.
IAM is a critical information security capability that protects users and data. As organizations digitalize their business processes and expose information to customers, partners and coworkers, IAM is becoming more important to enterprises than ever.
Global digital transformation and the continued growth of cybersecurity threat vectors, IAM specialists now find themselves in a position where traditional IAM architecture patterns are not always appropriate. A new, modern IAM pattern needs to evolve to better support more applications and more advanced use cases. Ultimately, this is the only way to support an organization's goal to become more agile and at the same time proactively reduce risk.
PlainID acknowledges this architectural challenge. That’s why we’ve developed a “modernized IAM architecture” pattern (or point-of-view) on how Authorization policy and PBAC can redesign IAM.
As input to this blog we have referenced two different publications from two organizations, Gartner and NIST (US National Institute of Standards and Technology).
Below are some excerpts that can serve as an introduction to how IAM can be modernized. PlainID recommends that you read both these publications to get the full view of each organization’s perspective.
After these excerpts we will discuss how to modernize IAM by applying PBAC. This modernization approach includes several perspectives on how different IAM technologies and solutions can interoperate to provide a more dynamic and agile IAM architecture.
In this technical report Gartner provides:
“Digital business and increased cybersecurity threats are placing greater demands on IAM systems. Organizations must support a broader set of identity use cases and be able to adjust to new requests and threats more quickly, including in near real time. To meet these challenges, organizations must adopt a new perspective on how IAM systems must operate and evolve. A new, dynamic, intelligent architecture, fortified with advanced analytic techniques, is evolving to meet the needs of modern identity.”1
Further Gartner provides:
“IAM must evolve from a set of capabilities that supports specific use cases in a series of identity silos to a more flexible platform that is able to quickly support new business and new combinations of access needs.” 1
Zero Trust Architecture (ZTA) is a quite recent concept that is embraced by several organizations. In February 2020 NIST released the 2nd Draft version of a document that is targeted towards security architects and how to build a road map to implement ZTA.
This is how NIST defines zero trust and zero trust architecture:
“Zero trust (ZT) provides a collection of concepts and ideas designed to reduce the uncertainty in enforcing accurate, per-request access decisions in information systems and services in the face of a network viewed as compromised. Zero trust architecture (ZTA) is an enterprise’s cybersecurity plan that utilizes zero trust concepts and encompasses component relationships, workflow planning, and access policies.”2
“This definition focuses on the crux of the issue, which is the goal to prevent unauthorized access to data and services coupled with making the access control enforcement as granular as possible.”2
NIST also defines a set of principles that needs to be applied. Several of these principles (#3, #4, #6) specifically point to the need for fine-grained and dynamic access control using a session based dynamic policy evaluation.
At the center of zero trust architecture is a concept of externalize access decisions to one logical point using a Policy Decision Point (PDP) and a Policy Enforcement Point (PEP) as per this depiction:
"In the abstract model of access shown in Figure 1, a user or machine needs access to an enterprise resource. Access is granted through a policy decision point (PDP) and corresponding policy enforcement point (PEP)."2
“The system must ensure that the user is authentic and the request is valid. The PDP/PEP passes proper judgment to allow the subject to access the resource. This implies that zero trust applies to two basic areas: authentication and authorization.”2
NIST elaborates that the transition to a zero trust model is a journey and not purely about new technologies but rather how modernization initiatives need to be applied incrementally to support more use cases.
“Organizations should seek to incrementally implement zero trust principles, process changes, and technology solutions that protect their data assets and business functions by use case.”2
At the center of PlainID’s IAM modernization approach is the Authorization ‘Policy’. We believe that policies defined within PlainID’s PBAC Platform provide a generic instrument (more on this topic below) to define contextual access permissions for a wide set of applications, services and APIs.
The PBAC approach clearly mimics how NIST defines the ZTA access model where “Access is granted through a policy decision point (PDP) and corresponding policy enforcement point (PEP).” But the issue with this ZTA access model is that all resources (applications, data etc.) need to be able to stop the Authorization flow and send an access request to the Policy Engine before access can be granted.
This model fits perfectly for a certain “type of application” where an externalized access control model can be implemented using simple extensions to the application i.e. a PEP. Even though these kinds of applications can be very important to the organization, they do not represent the majority of the applications that need to consume Authorization and implement access control in a modernized fashion.
In order to truly modernize the IAM architecture we need to support a larger set of applications and use cases. In our opinion, this is why we need to break the “identity silos”as described by Gartner above. We also need to “incrementally implement zero trust principles”, as NIST explains, to be able to address the wider and more advanced use cases.
In the picture below we see the four types of applications. These are abstract types of applications and they are not defined by any specific technology but rather by how they use and consume Authorization. Each application type is “supported” by a special kind of IAM technology.
The different types of applications are described below:
IdP Supported Applications (Application type 1)
This type is an application or a [micro]service that relies on an Identity Provider (IdP) for authentication, SSO and authorization. This type of application is often a quite modern application that receives authorization information as part of the login flow by using various types of tokens such as SAML, OAuth/OIDC, JWT etc. The term “IdP” is collectively used for any type of authentication service, web access management service, OAuth/OIDC service and/or an identity token broker service. IAM vendors in this space include OKTA, Microsoft, Ping, Curity, ForgeRock and several others.
Policy Engine (PDP) Supported Applications (Application type 2)
This type of application is already discussed in the ZTA model above. This is the application that can fully externalize and delegate the authorization decision to a Policy Engine that can make session based dynamic and fine-grained access decisions. The application will need to implement a PEP that calls the PDP for access decisions or authorization data needed to grant users with the correct access. These types of applications and services are typically home-grown bespoke business applications and technical platforms such as API Gateways, Business Process Management solutions, Data Virtualization/Proxy tools and Search Engines. This is the typical externalization use case.
IGA/IdM Supported Applications (Application type 3)
This type of application is typically a legacy application or a COTS (Commercial-of-the-Shelf) application that has its own user repository and internal controls for authorization. This type of application can be integrated with an Identity Governance and Administration (IGA) solution and make use of a connector that provisions and reconciles identity and access data to and from the application repository. Normally an HR system is connected to the IGA platform to drive the joiner-mover-leaver process. The IGA solution often exposes an access request workflow capability to handle access request processes from users. The identity and access management process, supported by IGA, most often relies on a RBAC (Role Based Access Control) model where roles and group memberships are statically assigned to users. IAM vendors in this space include SailPoint, Saviynt, Omada, OneIdentity and several others.
Disconnected Applications (Application type 4)
This type of application is the same as type 3 above but it is not relying on the IGA tool for fulfillment. These disconnected applications often use the IGA tool to handle the identity lifecycle and the access request but make use of an IT Service Management (ITSM) tool for the actual fulfillment process. Some organizations also make use of the ITSM tool to drive the access request process and integrate this with the IGA tool.
The policy definition of PBAC is generic and is not tied to any specific type of user, asset, application or system. The policies can express any type of association between a user and an asset/resource. These associations are rule-based and by that we mean that users are associated with a policy through rules. The same concept applies to the assets/resources. These are also associated with the policy through rules.
The policies are constructed by associating users to assets by connecting natural language “building blocks” as depicted below. This level of abstraction allows to hide the underlying authorization complexity.
Based on the policies the Policy Engine can provide other IAM solutions with dynamic and contextual “decisions” and/or “authorization data” on-demand. This architecture supports a common mechanism to define and enforce access across a larger set of applications disregarding which IAM solution that facilitates the process.
Below, we have outlined how the current as-is architecture can be modernized. We are solely focusing on how PBAC and Authorization models can be used to add more agility and dynamics to the picture. Other aspects and technology may also be applied to improve and modernize the IAM architecture.
In the diagram below the Policy Engine (PDP) and the concept of PBAC plays a vital role in architecture. The Policy Engine is the run-time “brain” and the Policy Administration Point is the management and governance layer for policies and other authorization artifacts such as entitlements and roles. The diagram shows how the IAM architecture can be realized and how authorization information can flow between the various components.
In the type 1 scenario below the IdP can query the PDP for dynamic scopes, claims, roles and/or entitlements that the user should present to the application. These dynamic permissions can make the existing coarse-grained access model more fine-grained and dynamic. This model would also be applicable in a microservices architecture where the OAuth/OIDC server can provide access decisions, access data and access filters to each microservice using the standardized OAuth/OIDC tokens and flows.
In the type 3 scenario below the IGA solution, much like the in the IdP scenario above, can query the PDP for applications, roles and entitlements to provision. These more contextual entitlements can significantly reduce static assignments in the provisioning process. Again, the value lies in the dynamics of policy evaluation and the single policy definition that can support multiple scenarios.
Closely related to the type 3 and 4 scenarios is also the aspect of how and where “governance” should be applied. Clearly, when evaluating this proposed architecture, you may find and overlay between the IGA tools management and governance capabilities and the PBAC platform. The main argument that PlainID brings to this discussion is that all of our focus is put on the Authorization aspects of the IAM architecture. We do not intend to provide functionality or capabilities that relate to any identity governance process, but we do intend to provide Authorization or access governance. And to that topic we have a lot to offer by providing visual representation of policies and roles, policy/role mining, workflows, SoD controls plus various investigation tools and dashboards that allow for more insight into the area of authorization. This is indeed an area of further discussion and it will be covered by PlainID in future webinars and blog posts.
Another topic that may be of interest is how this architecture also could encompass Privileged Access Management (PAM). It is not covered in the diagram above but an interoperation between a PAM tool and Policy Engine is not farfetched. If the PAM tool can send an access request to the Policy Engine the decision could of course support this use case as well. In this scenario we can think of policies that can be aware of environmental aspects such as IP-address, time etc. but also if there are planned service windows or an open IT emergency i.e. tickets. These factors can be evaluated and provided back to the PAM tool before granting an IT administrator access to a sensitive firewall, server or database.
Through the visual representation of policies/roles together with advanced analytics, workflow and a delegation model that supports large enterprises, the PlainID PBAC Platform is ideal for organizations that seek to modernize their IAM architecture.
The PBAC approach provides a clear “separation of concerns” where authorization policy is managed and governed in one central place but consumed by multiple channels and platforms.
This is not a “one-size-fits-all” architecture but rather a strategy, a journey or an architecture plan that needs a practical and incremental implementation road map to address the challenges, use cases and requirements of each organization.
PlainID welcomes a discussion on this topic. Click here to schedule a demo with a member of the PlainID team.
Sources quoted:
[1] Gartner Inc., “Architecting an Agile and Modern Identity Infrastructure,” Mary Ruddy, Erik Wahlstrom, 13 January 2020 (Gartner subscription required)
[2] NIST: Zero Trust Architecture - Draft (2nd) NIST Special Publication 800-207, February 2020