Published 24 September 2020

Abstract

In our research reports, events, and consulting engagements, TechVision has relentlessly described the need for organizations to transform into Digital Enterprises. Being a Digital Enterprise emphasizes the requirement to be adaptive to the marketplace with enterprise-wide agility that optimizes responses to events, and opportunities. Business buyers and consumers are becoming adept at finding exactly what they want, and enterprises must become equally adept in finding, and aligning the people, knowledge and operating assets to match.

This granular, orchestrated approach to enterprise IT resources risks its carefully constructed risk management and IT governance capabilities and as we first described in our report “Identity is the New Perimeter”, shifts the focus of protection from the data center perimeter to the individual resources themselves – no matter where they are located. This new reality is driving new requirements for identity and access management.

This report lays out the case for evolving your IAM environment into an Identity Fabric capable of supporting the requirements of a digital enterprise. It also suggests building or obtaining capabilities to support emerging requirements putting pressure on enterprise IAM which is becoming the nexus of customer experience and risk management.

We suggest you begin the journey by adopting a Reference Architecture to

• Organize business requirements
• Tie the requirements to capabilities
• Identify strengths and gaps
• Measure progress

We have developed the IAM Reference Architecture templates we describe in the details of this report over many client engagements and they represent our best thinking on all of the capabilities that might be necessary and provides a checklist with which to gauge your progress.

Authors:

Gary Rowe CEO, Principal Consulting Analyst [email protected]

Doug Simmons Principal Consulting Analyst [email protected]

Executive Summary

In many of our research reports and events, we have described the compelling need for businesses to transform into Digital Enterprises. Being a Digital Enterprise emphasizes the requirement to be adaptive to the marketplace/customers with enterprise-wide agility that optimizes responses to events, and opportunities. Business buyers and consumers are becoming adept at finding exactly what they want, and enterprises must become equally adept in finding, and aligning the people, knowledge and operating assets to match. Digital business is simply how business is increasingly being conducted and the pandemic has accelerated this transition.

The Digital Enterprise is driven by market ‘pull’, recognizing its resources in a granular manner and orchestrating those resources to meet the market demands. In many ways this is the opposite of a traditional business focus of optimizing around the ‘push’ model for delivering a range of standardized products efficiently through well-defined processes.

For most, the existing Enterprise IT infrastructure was designed to support the stability of centralized applications optimized for the push model. The infrastructure can be continually cost reduced and made more efficient. Enterprise IT, for the most part, supports Client-Server applications, as evidenced in ERP, and is focused on ensuring the outcomes of all transactions will maintain a common state of all data. To do this, the dependencies of all technology elements must be identified in advance and integrated in fixed close-coupled relationships. But it’s a challenge to believe that this architecture can operate in support of such a fundamental change in both Business and Technology use as required by the market pull model.

The pull model introduces increasing number of cloud and device-based applications and services requiring both localized and edge computing environments in addition to large scale centralized Clouds. The addition of IoT provides massively distributed and hyper-connected endpoints leading to interactive ‘read and respond’ smart services. Added to this mix are changes in workplace through the adoption of Collaboration and Social Tools, Drag and Drop composition of low-code and no-code localized business infrastructure by Line of Business managers all leading to an increasingly distributed enterprise.

This granular, orchestrated approach to enterprise IT resources threatens its carefully constructed risk management and IT governance capabilities and as we first described in our report “Identity is the New Perimeter”, shifts the focus of protection from the data center perimeter to the individual resources themselves – no matter where they are located. This new reality is driving new requirements for identity and access management.

This report lays out the case for evolving your IAM environment into an identity fabric capable of supporting the market pull model required of a digital enterprise. It also suggests building or obtaining capabilities to support emerging requirements putting pressure on enterprise IAM which is becoming the nexus of customer experience and risk management. Remember, you can’t secure, manage and govern what you can’t identify…and the elements to be identified are increasing by an order of magnitude.

We suggest you begin this critical journey in the right way by adopting a Reference Architecture to:

• Organize business requirements
• Tie the requirements to capabilities
• Identify strengths and gaps
• Measure progress

TechVision Research has developed our IAM Reference Architecture templates we’ll describe in the details in this report by leveraging many client engagements, our primary research and the best TechVision, customer and industry thinking on all of the capabilities that might be necessary to consider in building, architecting and understanding your IAM program. This also provides a checklist to help ensure you are considering all elements and a platform with which to gauge your progress.

Introduction

Digital transformation depends on consistent, clear, and secure identity management for every user, device, and asset across all lines of business. Identity management is the ability to set up and manage the relationships between users and things and to enforce rules for access and security. At its simplest, identity management must answer two questions: who/what are you, and what can you do?

These questions may sound simple but have never been more complicated. Nor have the stakes been higher. For enterprises, the ability to manage the digital identities of every contributor, every customer, and every prospect is a fundamental requirement to realize the full benefits of cloud computing, mobility, and the Internet of Things (IoT). Bottom line, every person (thing) of interest to the business must be able to access the resources they need to produce, buy, use, and recommend the products and services of the company.

In many of our research reports and events, we have described the compelling need for businesses to transform into Digital Enterprises. Being a Digital Enterprise emphasizes the requirement to be adaptive to the marketplace with enterprise-wide agility that optimizes responses to events, and opportunities. Business buyers and consumers are becoming adept at finding exactly what they want, and enterprises must become equally adept in finding, and aligning the people, knowledge and operating assets to match. It’s happening all around us.

• Rolls Royce doesn’t sell jet engines, they sell “thrust per hour”
• Auto companies are increasingly selling “miles driven” through leasing and subscription services
• NetJet doesn’t sell aircraft, they sell “flight hours”
• Trips to the shopping mall are being replaced by online storefronts with same-day delivery
• And now with the pandemic, SaaS applications have made it into your dining room, your office and into your personal life.

The Digital Enterprise is driven by market ‘pull’, recognizing its resources in a granular manner and orchestrating those resources to meet the market demands. In many ways this is the opposite of a traditional business focus of optimizing around the ‘push’ model for delivering a range of standardized products efficiently through well-defined processes.

Figure 1: Product Push Vs. Market Pull

For most organizations, the existing Enterprise IT infrastructure was designed to support the stability of centralized applications optimized for the push model. The infrastructure can be continually cost reduced and made more efficient. Enterprise IT, for the most part, supports Client-Server applications, as evidenced in ERP, and is focused on ensuring the outcomes of all transactions will maintain a common state of all data. To do this, the dependencies of all technology elements must be identified in advance and integrated in fixed close-coupled relationships. But it’s a challenge to believe that this architecture can operate in support of such a fundamental change in both Business and Technology use as required by the market pull model.

The pull model introduces increasing number of cloud and device-based applications and services requiring both localized and edge computing environments in addition to large scale centralized Clouds. The addition of IoT provides massively distributed and hyper-connected endpoints leading to interactive ‘read and respond’ smart services. Added to this mix are changes in workplace through the adoption of Collaboration and Social Tools, Drag and Drop composition of low-code and no-code localized business infrastructure by Line of Business managers all leading to an increasingly distributed enterprise.

This granular, orchestrated approach to enterprise IT resources risks its carefully constructed risk management and IT governance capabilities and as we first described in our report “Identity is the New Perimeter” 5 years ago, as it shifts the focus of protection from the data center perimeter to the individual resources themselves – no matter where they are located. These key trends will not apply to every organization but can be through of as a starting point to consider in assessing your requirements and future state IAM design. This new perimeter-less reality is driving new requirements for future state identity and access management as defined below.

1. Zero Trust Security Model: Ensuring authorized and approved subjects (a combination of user, application/service, and device) can access the proper resources (data, hardware, compute cycles, Internet of Things [IoT] actuators, etc.) at a granular level to the exclusion of all other subjects (i.e., attackers).
2. Connecting at Internet Scale/Speed: Connecting increasing numbers (millions) of subjects and resources in near real-time to support a market pull model.
3. Elegant User Experience: Provide optimal identity governance with the least amount of user effort. IAM in the distributed enterprise should never get in the way of developers, administrators and end-users as they try to get the proper resources they need.
4. Distributed Identity Fabric: Identity services are distributed to where they can best support zero trust, but the architecture must integrate distributed capabilities, along with traditional and legacy on-premise IAM to assure governance consistency across the entire enterprise.
5. New Identity Proofing Models: MFA, biometrics, passwordless authentication, adaptive authentication and low-friction token-based solutions are replacing traditional password-based proofing.

6. Use of AI/ML for Enhanced Identity Governance: During a complex decision-making process, AI can efficiently manage and control different factors (context, preferences, patterns) at the same point in time. While we humans face decision fatigue, algorithms do not have such limitations, which make AI-based decisions regarding identity governance faster and better.

1. Managing Diverse IAM Object Types–Internet of Everything: Support the registration, discovery, and verification of identifiers, attributes, and credentials for all subjects and resources in support of enhanced identity governance.
2. Customer-centric IAM and Identity of Things (IDoT): Currently, the objects and governance policies for CIAM /IoT services tend to be managed in separate technology stacks, but these are becoming increasingly integrated/accessible as an emerging distributed identity fabric via apps & services.
3. Identity and Risk Management as Discrete Services: Identity / security API’s and microservices are critical to enhanced identity governance within new systems of engagement required by the market pull model. Supporting the Continuous Delivery / Continuous Integration capabilities of DevSecOps with tested service components that facilitate zero trust and enhanced identity governance.
4. Integrated and Privacy Protecting Identity and Security Services: Increasingly leveraging AI / ML, contextual data to better support least privilege per access decisions and adaptable consent management in response to evolving threats and privacy regulations.
5. Decentralized Identity and Verifiable Credentials: Planning for Identity services leveraging blockchain for registry and discovery of user-controlled identifiers, verifiable credentials and trust frameworks to support user-centric, privacy-compliant IAM services.

12. Choreographed Identity Governance: Achieving policy-consistent yet responsive control across distributed resources including networks, clouds, applications, things, services, and data. Improved identity governance leads to better harmonization of IAM across multiple functional areas. Additionally, Privileged Access Management (PAM) emerges as a distinct and important category for governing administrative and service accounts.

Identity Management is the foundation that supports the new Digital Enterprise. In fact, it may be the most important capability in enabling a successful and sustainable Digital Enterprise. The establishment of identities and use of those identities will support virtually every substantive application and process throughout most organizations. Identity should ultimately be a “utility”; it should be easy to identify subjects and resources and connect them under proper security controls that maintain privacy. As enterprises accelerate their Digital Enterprise programs, the impact that the right IAM foundation can have in properly securing, orchestrating and managing this expanding set of interactions can’t be overstated. But what is the first step you’ll need to take to understand your current IAM capabilities? How do you evolve them into that utility, that identity fabric that can handle today’s requirements as well as those mentioned above?

“Would you tell me, please, which way I ought to go from here?”

“That depends a good deal on where you want to get to.”

“I don’t much care where –”

“Then it doesn’t matter which way you go.”

― Lewis Carroll, Alice in Wonderland

As this exchange between Alice and the Cheshire Cat reminds us, if we don’t have a vision of where we are going, if we don’t know the right questions to ask, we may not get where we want to go. For the IT team to avoid Alice’s predicament as it answers the questions above, it needs a point of reference – an IAM Reference Architecture.

What are Reference Architectures?

Reference Architectures are standardized frameworks that provide a model for a domain, sector, or field of interest. Reference models or architectures provide a common vocabulary, reusable designs and industry best practices. They are not solution designs and as such are not meant to be implemented directly. Rather, they are used to guide more concrete efforts. Typically, a Reference Architecture includes common architecture principles, patterns, building blocks and standards.

Six Reasons to Use a Reference Architecture.

Why would you want to use a Reference Architecture?  Here are six reasons why adopting a Reference Architecture is a good thing:

1. A Reference Architecture helps you to get an understanding of a domain. It provides a starting point for your own enterprise architecture effort. And it provides you with a basic vocabulary and structures, so you do not have to reinvent the wheel.
2. A Reference Architecture supports interoperability. In our increasingly networked world, organizations need to connect and cooperate with all manner of other parties. The standards and building blocks provided by a Reference Architecture facilitates these connections. A related benefit is that using standards improves flexibility, because it is easier to exchange building blocks that connect via standardized interfaces; vice versa, it is much easier to develop standards if the building blocks themselves are standardized.
3. A Reference Architecture supports digital transformation of the enterprise. For many enterprises, transformation means their value chain is being redistributed among partners, service providers, and customers. If all parties speak the same language, use the same standards, and recognize the same boundaries between functions, processes and/or services, it will be much easier to recombine their elements in new ways.
4. A Reference Architecture facilitates measurement. Often, the differences between companies are not in the design of their business processes, but in their execution. Using reference designs makes it much easier to compare progress and execution results with others.
5. Measurement leads us to a fifth reason why a Reference Architecture is important: regulatory compliance. Often, Reference Architectures are prescribed (or at least strongly recommended) by regulators. For example, in the EU General Data Protection Regulation (GDPR) privacy protection principles, practices and processes are standardized and mandated. This leads to audit requirements and business reporting standards that are supported by a proper Reference Architecture.
6. A Reference Architecture can put your organization in control of your vendor and partner relationships. A well-defined Reference Architecture that describes capabilities and includes combinations of capabilities that form patterns to support specific user stories (like logging-in) will help in evaluating and selecting the right vendors for your organization’s future-state needs. A strong Reference Architecture can change the dialogue from vendors telling you what you need to your organization telling vendors what they need to deliver.

The TechVision Research IAM Reference Architecture.

The TechVision Research Reference Architecture for IAM is a master template that identifies the IAM capabilities (rather than technologies) that can be improved or enabled, allowing business stakeholders and technical architects to achieve a common language for IAM functions, which can then be refined over time. ­­­This high-level template starts the journey.

Figure 2: IAM Reference Architecture master template

These IAM capabilities are described at the highest level as:

Interact: Interact is a layer of user interaction (UI) and application programming interfaces (API) that simplify consumer and application developer interaction with the rest of the IAM infrastructure. In this way, non-experts can follow the best practices of IAM without having to be experts in the field.

This allows the enterprise to:

• Incorporate new security capabilities without having to reengineer applications.
• Increase speed to market by removing security from the critical path of service development.
• Enhance security through the automatic adoption of best of breed security and privacy components.
• Decrease on-boarding friction by isolating complex security infrastructure through intuitive user interfaces.

Access: Access is the layer that answers the “Who has access to what?” question. It ensures customers can confidently exchange information and get the services they need to buy and use your products. It ensures employees and partners have all the digital resources they need to get the job done, nothing less and nothing more.

This allows the enterprise to:

• Ensure the right people have the right access to the right resources at the right time.
• Protect the assets of the company and its customers.
• Reduce productivity drains and costs caused when people can’t access the resources they need.

Change: Change manages the relationships between all the moving parts within the digital environment. Change establishes the connections between people, devices, applications, and data when they enter the environment, manages the connections while the relationship exists, and disconnects when access is no longer necessary.

This allows the enterprise to:

• Establish and maintain the proper rights, entitlements, and restrictions in order to reduce your attack surface, because Users and their identities are the most vulnerable link in a network.
• Orchestrate identity across device, network, and application boundaries because in the absence of the traditional security perimeter, identity is the common denominator across the entire digital environment.
• Prevent toxic combinations through transparency of entitlements across business processes.

Manage: Manage is where the administrators of the IAM platform upgrade, configure, tune, troubleshoot, document, and audit the platform and its components.

This allows the enterprise to:

• Incorporate new security capabilities without having to reengineer applications.
• Increase speed to market by removing security from the critical path of service development.
• Enhance security through the adoption of best of breed security and privacy components.
• Increase agility through isolating security software releases and patches to the underlying infrastructure components.

Measure: Measure is the lens into the digital environment. It allows live behavior observation, anomaly detection, platform health checks, and deeper analysis of usage and threats. It also provides the audit and reporting capabilities necessary to prove you are performing your duty to protect.

This allows the enterprise to:

• Understand behavior to improve the customer experience.
• Detect vulnerabilities before they are crises. The costs of prevention are much less than the costs of a breach.
• Prove compliance as required by law.

Store: Store is the shared place where the identity profiles, attributes, and relationships are kept and maintained. It may be physically centralized or distributed, and contains the map which defines “who has access to what?”

This allows the enterprise to support two important groups:

• For customers, it becomes the backbone for the entire customer experience; the customer data layer where all your interactions are captured.
• For employees, it becomes a user-centric view of entitlements across the entire digital environment.

The capabilities we describe above are present in all IAM systems (to varying degrees) and, in each of these areas, there are decisions to be made and many layers of supporting capabilities. The essence of the reference architecture is to continue to build on and further refine the decisions that are being made. In time of change operations for example, there are capabilities associated with the management of entitlements such as access reviews and entitlement catalogs that we. This category also provides identity lifecycle management and identity orchestration capabilities that helps to better connect and normalize the overall set of identity services and sources of data. Each major category follows this pattern. This is the foundation for TechVision’s IAM Reference Architecture and the foundation we’ll build on in the rest of the document.

Capabilities Needed in the IAM Service Portfolio

Enterprise information protection starts and ends with the business. It involves understanding how the business works and why it works that way, turning that understanding into a set of defined duties to protect, and carrying out those duties to affect reasonable and prudent operation of the business. From an IAM perspective, this means we start with a business focus on the capabilities that need to be in the IAM service portfolio. Building on the Top-Level of the Reference Architecture shown previously in Figure 2, we can now inject the IAM capabilities in business terms, such as “How can I consume and use the service?” Within the Interact layer, this implies a requirement for an intuitive User Experience. There is no mention of interface types, protocols, or related technologies – just the capabilities required, in non-technical terms.

Figure 3: Capabilities Needed in the Portfolio

In answering the questions outlined in Figure 3 (and the follow-up questions they may spawn), the business requirements are defined and refined before any technology is applied. Then at each Reference Architecture layer, the typical types of capabilities that correspond with the requirements in service layer itself are defined; the Access layer describes common capabilities associated with accessing resources. On the other hand, the Change layer describes capabilities that are focused on managing the users’ or things identity lifecycle on their journey within the enterprise.

The purpose is to assure the utility of the content – and how this is accomplished depends on the context of the business at hand.  Because enterprises have many moving parts, structuring a protection program requires an architectural context in order to be effective and efficient. The following identifies the structure of such an architecture and the elements it normally contains. Taking this as a starting point, details typically get filled in at increasing levels as the specifics of the needs of the enterprise are analyzed and structured.

Capabilities of the Combined Portfolio Architecture

The next level of the architecture outlines the functional capabilities that are the foundation for a best-in-class IAM Reference Architecture. Each category is broken up into multiple capabilities at a level of greater detail. For example, interfaces can be for applications / developers (APIs, messaging services), Lines of Business, self-service or even robotic processes. This applies to each category and, based on stakeholder input, use cases and priorities can be further developed into Reference Architecture patterns or templates for specific services.

Remember, the Reference Architecture is not focused on the actual implementation of things that carry out these controls. Rather it is a model of what the controls are, how they work, and how they interact to assure the utility of content.

It is important to understand that these functional capabilities consider all type of objects and use cases within the IAM foundation. For example, identifying, securing, and collecting data pertaining to IoT devices is expected to be accommodated within the IAM Reference Architecture.

As ultimately implemented, different enterprises use different IAM capabilities in different ways to meet different protection needs. And they do so differently for different content and business functions because of the different risks and potential consequences associated with failures and costs associated with protection. One size does not fit all.

Once the required business capabilities are identified, the next layer of the TechVision Research Reference Architecture for IAM (Figure 4) allows us to explore each of the specific technology or process elements comprising each capability in the form of a combined portfolio architecture.

Figure 4: Combined Portfolio Architecture

Once again, it is important to acknowledge that the combined portfolio architecture needs to reflect the business requirements so the components and descriptions that follow are items we’ve seen within our clients but may not represent your specific situation. Use them to guide your thinking as you explore and build out your own IAM architecture.

Interact Layer

1. Self-Service UI – an intuitive interface providing access to all the functionality required by end-users and administrators. The Self-Service UI is accessed by end users to administer some of their own user-specific attributes and preferences, and to request access. Administrators can use the UI to review and approve access requests and to set specific user settings as policy allows.
2. Chatbot – a computer program designed to simulate conversation with human users, chatbots can be used to facilitate user registration and help solve simple anomalies such as password reset.
3. IVR – Interactive Voice Response is a telephony technology that can read a combination of touch tone and voice input. It gives users the ability to access specific IAM self-service functions via phone.
4. Robotic Process – software that performs specific repetitive IAM tasks just as human workers do, including registering users, requesting or approving access privileges, etc.
5. API – an Application Programming Interface is a set of routines, protocols, and tools for building software applications. An IAM API is used to embed specific IAM functions, such as register, login, etc. within applications in a consistent manner, and is used for programming graphical user interface (GUI) components that access IAM functions, including the Self-Service UI.
6. Messaging Events – a design pattern, applied within the service-orientation design paradigm and microservice architectures to enable the IAM system to receive notifications about specific IAM events in real-time.
7. ETL – Extract/Transform/Load is a mechanism for batch file processing, such as when a number of users or things must be registered or deregistered with the IAM system. It typically refers to extracting data from a database, putting into a file format (e.g., csv) that can be read by the target system (IAM) and running the file in the IAM batch process.
8. CLI – Command Line Interface is what processes commands to a computer program in the form of lines of text. The program which handles the interface is called a command-line interpreter or command-line processor. CLI can sometimes be a useful way to administer portions of the IAM system.

Access Layer

Adaptive Authentication

Adaptive / step up authentication – enables the enforcement of additional authentication steps based on risk factors associated with the resource the entity is attempting to access, which may include the entity’s current geo-location, device, sensitivity of the information being accessed, etc. It includes the following processing elements:

1. Password management – the ability to reset user passwords and change/update user passwords via self-service interfaces.
2. Multi Factor authentication (MFA) – requires end user or endpoint to provide 1. Something they know (e.g., PIN or password); 2. Something they have (e.g., registered mobile device); 3. And possibly something they are (e.g., fingerprint, voiceprint, iris scan…) when authenticating to applications, networks or services.
3. Password-less authentication – a form of authentication that replaces the password with a more secure and manageable alternative, such as multi-factor authentication, biometrics or secure verifiable claims within the decentralized identity model.
4. Biometrics – typically fingerprint, iris scan, facial recognition, voice recognition that can be used to better ensure the end users are who they claim to be.
5. Single Sign On – the ability to authenticate to multiple applications and systems with a single authentication event.
6. Access token management – access tokens are used in token-based authentication to allow an application to access the IAM API. The application receives an Access Token after a user successfully authenticates and authorizes access, then passes the Access Token as a credential when it calls the target IAM API.
7. Access key management – involves the monitoring and recording of each key’s access, use and context.
8. Certificate management – the capability to manage digital certificates that can be propagated to devices, workstations, network devices and so forth. Includes ability to revoke certificates when necessary.
9. App secrets management – refers to the tools and methods for managing digital authentication credentials (i.e., “secrets”), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.
10. Remote Access[1] Authentication – provides the ability to access a network, computer or device from any remote location, either using a Virtual Private Network (VPN) client or other VPN-less security protocols.

Adaptive Authorization

Adaptive authorization matches risk with request by evaluating additional environmental conditions, using risk score as a factor in dynamically determining authorization decisions. The following processing elements:

1. App Dashboard – the user interface that is like the ‘portal’ method of providing the applications a user can access on a single screen.
2. Fine-grained authorization – enables object level security. For data stored in tables, it means row-level or cell-level security, for data or metadata entered in forms, it means field-level security, and so on. This capability relies primarily on an attribute-based access control system (ABAC), also known as a policy-based access control (PBAC) system, where attributes associated with a user or action or resource are inputs into the decision of whether a given user may access a given resource in a particular way. Note that role-based access control (RBAC) can also be implemented as a specialization of ABAC. Fine-grained authorization systems typically involve a PEP and PDP. The PEP (Policy Enforcement Point intercepts a user’s, application’s or device’s access request to a resource, decides request to the PDP to obtain the access decision (i.e. access to the resource is approved or rejected), and acts on the received decision. The PDP (Policy Decision Point) therefore evaluates access requests against authorization policies before issuing access decisions. The PDP often interfaces with the IAM directory, called the Policy Information Point (PIP) to access information about the user or device in question in order to inform its decision-making process.
3. Coarse-grained Authorization – only allows one level of access.
4. JIT (Just-In-Time) Access – the ability to grant privileged access on-demand, subject to policy and for a specific set of purposes and time period, using the entity’s enterprise ID. Often integrated with MFA to enforce stronger authentication for administrative tasks. The JIT Privileged Access Management (PAM) is a strategy that aligns real time requests for usage of privileged accounts directly with entitlements, workflow, and appropriate access policies. Companies use this strategy to secure privileged accounts from continuous, always-on access by enforcing restrictions based on behavioral and contextual parameters.
5. Remote Access Authorization – evaluates whether access should be granted over a remote network connection, such as via VPN.

Federation

Federation occurs when a proxy acts as a broker and authentication protocol translator for applications and other resources, enabling single sign-on (SSO) to applications across multiple internal and external domains. The following processing elements are involved in supporting these capabilities.

1. Federated SSO – established when a user is successfully authenticated to their domain / Identity Provider (IDP) and then is able to access applications in other domains by virtue of a header token that contains assertion information about the authenticated user, typically in the form of OpenID Connect (OIDC), OAuth 2 or Secure Assertion Markup Language (SAML) protocols.
2. Federated Cross-Domain Authorization – established with trust between multiple organizations (inter-organizational) to authorize each other’s users. Again, this is typically accomplished via federation protocols such as OIDC, OAuth2 or SAML. Note this approach can also be practiced inside an organization (intra-organizational) so that the user can access resources (different web properties and applications) within an organization. This method can be useful in very large, geographically dispersed organizations.

Privileged Access

Privileged Access – used to control access to privileged accounts by controlling the administrative session; facilitates session isolation, session recording and command filtering. The following process elements are included when PAM is required.

1. Session Management – privileged session management refers to the monitoring, recording and control over privileged sessions.
2. App Secrets Management – refers to the tools and methods for managing digital authentication credentials (secrets), including passwords, keys, APIs, and tokens for use in applications, services, privileged accounts and other sensitive parts of the IT ecosystem.
3. Password Vaulting – a password vault is a system that stores passwords for various privileged accounts in a privileged account management system. Passwords are ‘checked out’ at the start of a privileged administration session and not able to be shared among multiple administrators. When the privileged session is completed, the passwords are rotated within the vault so that the next time an administrator requests access, a different password is provided for the new session.

Change Layer

Lifecycle Management

Identity Lifecycle Management is the process of managing identities through their lifecycle (i.e., Join, Move, Leave) and relationship with the organization.

1. Join, Move, Leave – events that indicate that a person (or thing) has joined the organization (Join) or changed jobs/functions/roles/locations, etc. (Move) or has left the organization (Leave). Such events can be detected on authoritative source systems such as HR, Contractor Management systems and so forth, and the events can trigger workflows, notifications, access right changes, entitlement updates, account disablement, and more depending on the rules associated with the IAM provisioning service listening for these events.
2. Identity Proofing – various forms of required proof that someone is who they say they are that are reviewed and verified before an account can be created/provisioned across the IAM-connected systems and applications.
3. Profile Management – the ability to manage one’s set of attributes associated with his/her/its digital identity.
4. Social Login – allows an end user to authenticate using their social media identification, such as Facebook or Google.
5. Decentralized Identity – also known as Self-Sovereign Identity (SSI) represent Identity systems and services that are controlled, managed by the individual on a decentralized basis and generally built on blockchain/distributed ledgers. They often integrate a verifiable claims infrastructure to support the exchange of trusted credentials associated with the decentralized identifier.
6. Federated Identity – authentication protocol for applications and other resources, enabling single sign-on (SSO) to applications across multiple internal and external domains.
7. Consent Management – a system, process or set of policies for allowing consumers and patients to determine what health information they are willing to permit their various care providers to access. It enables patients and consumers to affirm their participation in e-health initiatives and to establish consent directives to determine who will have access to their protected health information (PHI), for what purpose and under what circumstances. Consent management supports the dynamic creation, management and enforcement of consumer, organizational and jurisdictional privacy policies.

Access Administration

Account administration contains the capabilities associated with creating, modifying and deleting/disabling computer / network / application user (or device) accounts.

1. Access Request and Approval – workflows that facilitate any approval processes that may need to be enacted as part of an access request fulfillment. Access requests may be initiated through a self-service identity registration process, a delegated administrator request or an event trigger listening for changes on an authoritative source system such as HR.
2. Access Provisioning – automates the steps required to set up the required accounts and entitlements and fulfill any required changes on one or more connected systems or applications, such as the enterprise network, Google Suite, Active Directory and so forth.
3. Birthright Access – the set of entitlements someone (or something) can be granted immediately, without requiring workflows and approvals.
4. Time-bound Access – policy that grants access for a specific period.
5. Group Management – the ability to create and manage static and dynamic groups of accounts that are associated with runtime access control decisions.
6. Policy-based Access – using policies, based on a set of rules, to decide on authorization.
7. Self-Service Administration – the capability to manage one’s own profile or request access to specific resources, typically through the Self-Service UI.
8. Delegated Administration – the capability for an administrator to manage a user’s or thing’s profile, request access or based on policy, approve access. This is performed typically through a version of the Self-Service UI that is tailored to the administrator view.
9. RBAC, ABAC – Role Based Access Control (RBAC) associates one or more enterprise roles with an account, while Attribute Based Access Control (ABAC) associates one or more attributes within an account’s profile – in both cases this information is used during runtime authorization decisions.

Identity Governance

1. Access Review and Re-Certification – a process by which an organization reviews and verifies the appropriateness of access privileges.
2. Entitlement Catalog – a method for organizing and entitlement definitions and mappings, listing what is assignable, describing what these entitlements do; facilitates entitlement ownership and accountability.
3. Access Risk Management – the overall management of access risk and actions or permissions that, when available to a single user (or single role, profile, or HR Object), creates the potential for fraud or unintentional errors.
4. Predictive / Autonomous Governance – uses artificial intelligence (AI) and machine learning (ML) to recognize and act on access rights and entitlements in relation to policy.
5. Access Policy Violation and Remediation – like predictive/autonomous governance, acts on existingentitlements that appear to violate policy by fixing the issue without direct human interaction.
6. Segregation of Duties – an internal control to mitigate risk by having different individuals handle different tasks.
7. Closed-loop Remediation – direct revocation of roles/entitlements from the provisioning system.
8. Dormant Access Discovery and Suspension – uses a crawling mechanism to discover accounts and access privileges that have not been used in a specified period and, based on policy, suspend the access privileges until further admin or user intervention.

Privileged Access Governance

1. Privilege Definition – the aspect of defining what systems require administrator access and what the specific privileges are, based on specific criteria regarding several variables, including who, what, when, where and why.
2. JIT Privileged Access Granting – a least-privilege security model that requires users, processes, applications, and systems to have just enough rights and access—and for no longer than required—to perform a necessary action or task. Eliminating persistent privileged access for privileged user accounts—and activating it only for the duration it is needed to perform an activity is the objective of JIT PAM.
3. Privileged Access Discovery and Reduction – uses a crawling mechanism to discover admin accounts and access privileges that are in violation of policy and removes the access privileges until further intervention.

Identity Repositories Layer

1. Directory Management – maintaining a persistent, scalable view of the common identity information that is easily referenceable from other components within the IAM architecture; manages the identity object and attribute stores (i.e., directories), manages the directory database schema and hierarchy.
2. Directory Virtualization – a method for instantiating identity correlation and aggregation in lieu of persistent data synchronization between source and target systems; is the cornerstone of an Identity Data Service.
3. Identity Correlation and Aggregation – the ability to automatically match and associate multiple identities across multiple, disparate, connected systems; allows for a single logical view of these associated identities spanning all connected systems.
4. Identity Profile Propagation – maintaining a persistent, scalable view of the common identity information; easily referenceable from other components within the IAM architecture.
5. Identity Data Customized View – the ability to control or limit what a user or application sees when querying the IAM directory infrastructure; may also support data transformation to tailor the view to the specific application’s requirements.
6. Authoritative Identity Data Source Enrichment – refers to a bi-directional data integration mechanism that allows certain IAM attributes to be identified as the authoritative source for the data, that can then be synchronized back to the original authoritative source database.

Identity Analytics Layer

1. Access Monitoring and Reporting – on-going surveillance and reporting to ensure that inappropriate access is not occurring and that the results are logged.
2. Access Policy Analysis and Recommendations – reviewing, analyzing and making recommendations with respect to access policies.
3. Trust Scoring – a trust engine establishes a trust score for an actor (e.g., user, device) based on many factors. An example might include having a user or devices trust score adjusted negatively because the actor is exhibiting behaviors that are well outside of an established baseline.
4. Risk Scoring – dynamically evaluates risk of a given operation based on current environmental factors and filters access to operations if the risk level exceeds the accepted threshold. The risk engine incorporates elements of the risk management framework and threat intelligence to calculate a risk score for each asset on the network. Factors that are taken into account include data classification, vulnerabilities found, and the controls that are applied to an asset. Together an actor’s trust and risk score determine if the authorization request is within defined tolerances for the organization. The policy repository is where baseline policies are managed and stored. The policy repository can also serve as a historical record of baseline policy changes and the policy changes made for each entity.
5. User Entity Behavior Analysis – (UEBA) uses machine learning and deep learning to learn how users and other entities on the corporate network typically behave, detect abnormal behavior, outlier access attempts (e.g., outside the ‘norm’) and figure out if this behavior has security implications. This information is fed in real-time to the PDP to provide relevant information to the runtime access decision. The goal is to identify abnormal behavior, determine if it has security implications, and alert security teams.
6. Insider Threat Access Detection and Remediation – reviews access entitlements in concert with segregation of duties (SoD) requirements to uncover SoD violations and recommend remediation via workflow or autonomously remediate. It focuses on perpetual analysis of the organizational entities’ access permissions in concert with the lifecycle of the entitlement assignments and policy definitions. This process will also help reduce the attack surface by removing unused entitlements from entities’ profiles; and can assist in identifying entity logins that do not have an entitlement to go further into the application. This will provide more access granularity to prevent entities from being able to view anything that doesn’t pertain specifically to their current assigned entitlements – which is key from the security and compliance perspective.
7. Approval Review and Recommendations – reviews workflow approvals for access requests – whether initiated by self, administrator or authoritative source system and evaluates risk of approval in conjunction with SoD policy. If deemed risky, recommends alternatives to Approver and application owner.
8. Access Recommendations – a method of governance decision making that leverages AI, ML and predictive data to make recommendations regarding appropriate access for a specific user, device, role, etc.
9. App Access Trend Analysis – monitors the access privileges being granted to users and devices, based on specific criteria, and provides trend reports to help with IAM access policy refinement.
10. IAM QoS Trend Analysis – measures the Quality of Service being provided by the entire IAM system to determine how well IAM meets Key Performance Indicators (KPIs).

Manage Layer

1. Configuration Management – the ability to record changes to the configuration of your Identity and Access Management (IAM) users, groups, and roles (collectively referred to as IAM entities) and the policies associated with them.
2. Process Optimization – the configuration of processes such as workflows and data integration flows.
3. Access Policy Management – the configuration of access policies.
4. App Onboarding Self-Service – the mechanism that app owners can make available / publish their IAM-enabled applications.
5. Data Governance – pertains to how long to archive IAM log data in support of regulatory, legal and privacy compliance, legal.
6. Monitoring and Reporting – the ability to monitor all aspects of the IAM system and report on performance.
7. Auditing and Logging – the ability to log specific activities, such as login, access requests, approvals and so forth in support of audits.
8. Archiving / Purging – the mechanism used to save (archive) specific identity data and IAM activities for a specific period, and the subsequent ability to permanently delete such information – usually in accordance with data governance and privacy regulations.
9. Disaster Recovery – the configuration of key IAM subsystems to enable operability in the case of a disaster.

With this information, technical architects can rapidly zero-in on the current options (technology and process) their IAM architecture should evaluate to achieve the required capabilities for the business. In the form of architecture considerations, each of the options available is then described in more detail to help identify the right approach for an optimal IAM architecture and deployment strategy. As such, the TechVision Research Reference Architecture for IAMis a comprehensive ‘checklist’, a methodology to break down the business capabilities a client is endeavoring to facilitate, coupled with the technology and process necessary to achieve its objectives.

Conclusion

Being a Digital Enterprise emphasizes the overarching requirement to be adaptive to the marketplace with enterprise-wide agility that optimizes responses to events, and opportunities. Business buyers and consumers are becoming adept at finding exactly what they want, and enterprises must become equally adept in finding, and aligning the people, knowledge and operating assets to match. This is core to becoming a successful Digital Enterprise and the right IAM foundation is critical in achieving a safe and secure digital ecosystem.

The Digital Enterprise is driven by market ‘pull’, recognizing its resources in a granular manner and orchestrating those resources to meet the market demands. In many ways this is the opposite of a traditional business focus of optimizing around the product ‘push’ model for delivering a range of standardized products efficiently through well-defined processes.

For most, the existing Enterprise IT infrastructure was designed to support the stability of centralized applications optimized for the push model. The infrastructure can be continually cost reduced and made more efficient. Enterprise IT, for the most part, supports Client-Server applications, as evidenced in ERP, and is focused on ensuring the outcomes of all transactions will maintain a common state of all data. To do this, the dependencies of all technology elements must be identified in advance and integrated in fixed close-coupled relationships. But it’s a challenge to believe that this architecture can operate in support of such a fundamental change in both Business and Technology use as required by the market pull model.

The pull model introduces increasing number of cloud and device-based applications and services requiring both localized and edge-computing environments in addition to large scale centralized Clouds. The addition of IoT provides massively distributed and hyper-connected endpoints leading to interactive ‘read and respond’ smart services. Added to this mix are changes in workplace through the adoption of Collaboration and Social Tools, Drag and Drop composition of low-code and no-code localized business infrastructure by Line of Business managers all leading to an increasingly distributed enterprise.

This granular, orchestrated approach to enterprise IT resources risks its carefully constructed risk management and IT governance capabilities and as we first described in our report “Identity is the New Perimeter”, shifts the focus of protection from the data center perimeter to the individual resources themselves.

This is causing enterprises to rethink their identity management architecture traditionally based on centralized access control and governance to a more of a distributed identity fabric with choreographed governance safely connecting subjects and resources no matter where they reside.

How do you evolve your current IAM platform(s) to such a capability? Start by adopting a Reference Architecture such as the one TechVision Research has described to:

• Organize business requirements around identity
• Tie the requirements to capabilities needed in the combined portfolio architecture
• Identify strengths and gaps between current and target environments
• Measure progress toward the end goal

We believe that the templates, descriptions and advice in this report is a tool that any large organization should invest in to evaluate and elevate their critical IAM foundation. In doing so, you’ll create a prioritized plan for making IAM an enabler rather than a roadblock to digital transformation. We have helped hundreds of clients develop custom Reference Architectures over the years and will be happy to further support your organization in this journey.

About TechVision

World-class research requires world-class consulting analysts, and our team is just that. Gaining value from research also means having access to research. All TechVision Research licenses are enterprise licenses; this means everyone that needs access to content can have access to content. We know major technology initiatives involve many different skillsets across an organization and limiting content to a few can compromise the effectiveness of the team and the success of the initiative. Our research leverages our team’s in-depth knowledge as well as their real-world consulting experience. We combine great analyst skills with real world client experiences to provide a deep and balanced perspective.

TechVision Consulting builds off our research with specific projects to help organizations better understand, architect, select, build, and deploy infrastructure technologies. Our well-rounded experience and strong analytical skills help us separate the “hype” from the reality. This provides organizations with a deeper understanding of the full scope of vendor capabilities, product life cycles, and a basis for making more informed decisions. We also support vendors in areas such as product and strategy reviews and assessments, requirement analysis, target market assessment, technology trend analysis, go-to-market plan assessment, and gap analysis.

TechVision Updates will provide regular updates on the latest developments with respect to the issues addressed in this report.

About the Authors

Gary Rowe is a seasoned technology analyst, consultant, advisor, executive and entrepreneur. Mr. Rowe helped architect, build and sell two companies and has been on the forefront the standardization and business application of core infrastructure technologies over the past 35 years. Core areas of focus include: Identity and Access Management, blockchain, Internet of Things, cloud computing, security/risk management, privacy, innovation, AI, new IT/business models and organizational strategies.

Prior to starting TechVision Research, he was President of Burton Group from 1999 to 2010, the leading technologyinfrastructure research and consulting firm. Mr. Rowe grew Burton to over $30+ million in revenue on a self-funded basis, sold Burton to Gartner in 2010 and supported the acquisition as Burton President (now Gartner for Technical Professionals) at Gartner.

Doug Simmons brings more than 25 years of experience in IT security, risk management and identity and access management (IAM). He focuses on IT security, risk management and IAM. Doug holds a double major in Computer Science and Business Administration.

While leading consulting at Burton Group for 10 years and security, and identity management consulting at Gartner for 5 years, Doug has performed hundreds of engagements for large enterprise clients in multiple vertical industries including financial services, health care, higher education, federal and state government, manufacturing, aerospace, energy, utilities and critical infrastructure.

[1] Includes authorization to connect to the enterprise network(s) from the Internet (e.g., off-site). Includes, virtual private network (VPN) connections that encrypts all traffic between source and destination workstations and systems