Published 21 January 2022

Abstract

Over the past 10+ years, much of enterprise IT has moved to the cloud. In conjunction with this trend TechVision has written about IAM migrating to the cloud, Customer IAM is becoming primarily cloud-based and even Privileged Access Management is moving to the cloud. Today, we find ourselves with a largely mixed set of IAM capabilities residing on-premises, in the cloud, or both. Adding to this complexity for many organizations is that they may be using multiple Identity as a Service (IDaaS) offerings, may have multiple on-premise IAM systems and may be leveraging multiple cloud service providers. The many components that comprise an IAM environment, such as authentication, authorization, account lifecycle management and privileged access today can be sliced and diced in such ways that enterprises can select to run in the cloud certain capabilities that run more efficiently, are more cost effective and retain requisite security.

This report focuses on how enterprises manage, integrate, architect, migrate, operate and secure these hybrid IAM environments. Taking into consideration the most common enterprise requirements for IAM, we describe how to build a Reference Architecture for hybrid/cloud IAM that can fit well within the context of leading vendor offerings/directions in an effort to help you understand how to match vendor solutions to your needs and how to deploy those solutions thoughtfully and effectively.

Authors:

Doug Simmons Principal Consulting Analyst [email protected]

Gary Rowe CEO/ Principal Consulting Analyst [email protected]

 

Executive Summary

There is little disagreement today that that IAM is one of the most critical elements of an enterprise security posture. As we indicated in our most recent report titled “The Future of Identity Management 2021-2026”, IAM is the foundation that supports the new 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 individuals, applications and things and provide access under proper security controls that are privacy centric. The management of identities is also a critical part of how organizations directly interact with consumers and trading partners. As organizations accelerate their Digital Enterprise programs during the pandemic, the impact that the right IAM foundation can have in properly securing, orchestrating and managing this expanding set of interactions can’t be overstated.

Over the past 10+ years, enterprise IT is accelerating its overall movement to the cloud and in conjunction with this trend, enterprises have migrated or are beginning to migrate many of their IAM capabilities to the cloud. Today, we find ourselves with a largely mixed set of IAM capabilities residing on-premises, in the cloud, or both. The many components that comprise an IAM environment, such as authentication, authorization, account lifecycle management and privileged access today can be sliced and diced in such ways that enterprises can select to run in the cloud certain capabilities that run more efficiently, are more cost effective and retain requisite security.

To securely integrate and operate IAM capabilities that reside in multiple “on-prem and in-cloud” environments, enterprises must maintain a reasonably detailed Reference Architecture for IAM. Now, more than ever, it is imperative to architect and document the capabilities, services, integration interfaces, data flows and security policies that comprise the “hybrid IAM” landscape. Our mantra to our customers over the years has consistently been “If you don’t know where you’re going, any road will take you there.” Alice’s Cheshire Cat was evidently prognosticating about the perils of traveling blindly in the rapidly changing world of IT.

As we state in this report, 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. The Reference Architecture for Hybrid IAM is crucial to help identify the areas that require more stringent protection, monitoring and failover mechanisms – while at the same time identifying the key usability characteristics that will insure adoption and support enterprise-wide. Once a Reference Architecture that defines common architecture principles, patterns, building blocks and standards is developed, your organization can better evaluate cloud vendor solutions, such as Identity as a Service (IDaaS) offerings and credibly determine their ability to address the critical needs of your organization. It is important that organizations pay attention to this

This report focuses on how enterprises manage, integrate, architect, migrate, operate and secure these hybrid IAM environments. Taking into consideration the most common enterprise requirements for IAM, we describe how to build a Reference Architecture for hybrid/cloud IAM that can fit well within the context of leading vendor offerings/directions in an effort to help you understand how to match vendor solutions to your needs and how to deploy those solutions thoughtfully and effectively.

Introduction

Nearly all of TechVision’s reports over the past five years have highlighted the trend of migration to the cloud and “as a service” subscription models supporting many IAM services. These services include workforce, customer, vendor and business partner end user authentication, authorization, account provisioning, privileged access management, identity governance and reporting – to name a few! Within each of these services are more granular capabilities, such as multi-factor authentication, delegated administration, identity data integration and many more.

Coupled with this direction toward Identity as a Service (IDaaS) is the general strategy to loosely couple IAM services and capabilities as much as possible, to avoid inflexibility, technical debt, vendor lock-in and single points of failure – among several other reasons. In fact, loose coupling of the IAM infrastructure has been a TechVision mantra since the “beginning of time”. Without elucidating further on the reasons why in this particular document, we focus here on typical enterprise requirements, the types of solutions that comprise the IDaaS ‘playing field’ and how to develop a comprehensive IAM Reference Architecture that encompasses a loosely coupled set of services and capabilities – without sacrificing security, scalability and performance.

Current and emerging implementations of (or migrations to) cloud-based IDaaS range the gamut from addressing a single-but-far-reaching requirement for Multi-Factor Authentication (MFA) to complex enterprise workforce provisioning, deprovisioning, access governance and identity data integration. Take MFA for example. Today, there are several IDaaS vendors – large and small, that provide cloud subscription-based authentication services for companies that want to enable comprehensive MFA to their enterprise workforce (including business partners) or their customers. Such invaluable MFA services are offered by vendors such as Okta, Google, Cisco, ForgeRock, Trusona and 1Kosmos – among many others.

For another relevant example, consider Privileged Access Management (PAM). As we described in our report titled “Privileged Access Management: More Necessary Than Ever as Cloud-Shift Intensifies”, published in 2021, a consistent set of well thought out PAM controls that are aligned to a comprehensive cybersecurity framework is an imperative for nearly every organization, enabling the automation and enforcement of controls over privileged credentials in any system, platform, or environment.  PAM also identifies all known exceptions that require special control implementation. This is particularly important considering the large number and dynamic nature of resources many organizations are deploying in the cloud, coinciding with requirements to provide on-going support for multi-cloud environments. Most of these cloud environments (e.g., Azure, AWS, Google) have powerful management consoles and APIs that can expand the available attack surface requiring protection and defense.

Taking this ‘cloud economy’ one step further, large influential vendors such as CyberArk, BeyondTrust and others have made their PAM solutions available as a service. This is of enormous value, as it affords enterprise customers the capability to deploy PAM in myriad ways to address on-premises and cloud-based infrastructure (e.g., AWS, GCP, Azure, etc.) with more laser-like precision and leveraging the existing infrastructure and configuration that cloud-based as-a-service provides “out of the box”.

There are some principal considerations when embarking on any form of IDaaS journey, however. Chief among these is the necessity to further develop or update your enterprise IAM Reference Architecture to identify the services and capabilities that are to be supported by a subscription-based cloud service model in tandem with those that are to remain ‘in house’ or on-premises. The reason this is so important is that systems integration, information protection, data flow and data transformation are all requisite areas that enable the ‘Big IAM Picture’. In other words: the devil is in the details.

Secondly, it is absolutely imperative that your organization’s governance capabilities be focused on what can and cannot be accomplished via various IDaaS offerings. The key phrase to keep in mind here is “lowest common denominator”. The IDaaS offerings available from so many vendors, large and small, reputable and nascent, may provide a consistent level of service that may not meet your organization’s specific requirements. It is nearly impossible to be “all things to all people”. Vendors strive to identify (through their customers’ input) the services and configurations that most meet most customers’ requirements. You will note the previous sentence did not contain the word “all”. Every organization is different – at least to some degree. However, we have found over our three decades of working with companies on their IAM strategies that these differences can tend to be relatively minimal when taken into proper context. This is why IAM and Security Governance functions are so important when considering a move to various IDaaS offerings. There may be cases where an existing level of functionality that is currently enabled via an on-premises, legacy IAM environment cannot be replicated entirely through an IDaaS offering. In some instances, this may be a showstopper. But in other cases, the governance function may determine that a ‘slightly deprecated’ level of functionality is acceptable, based on thoughtful, detailed risk/benefit analysis (which is what governance organizations are supposed to do).

That is the objective of this report – to help you develop a viable Reference Architecture for your emerging Hybrid/IDaaS IAM Program. As we describe in the TechVision report titled “IAM Reference Architecture”, published in September 2020, we provide guidance for how to develop and use a Reference Architecture to:

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

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. Once a Reference Architecture that defines common architecture principles, patterns, building blocks and standards is developed, your organization can better evaluate vendor solutions and their ability to address the critical needs of your organization.

Before we dig into the specifics of developing a Reference Architecture for Hybrid/IDaaS IAM, let’s quickly review the related functional and technical landscape.

IAM Reference Architecture Considering Hybrid/IDaaS

In the TechVision Research report titled “IAM Reference Architecture”, we define and describe a comprehensive IAM architecture. We summarize this here to establish a level set regarding the services, capabilities and technologies that enable IAM.

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 1: IAM Reference Architecture master template

For a quick review, 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 IAM Reference Architecture is to continue to build on and further refine the decisions that are being made.

This is of enormous importance as these decisions include IDaaS offerings. 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. When deciding on whether to support such patterns with on-premises or cloud/IDaaS vendor solutions, it is necessary to map these vendor solutions to the capabilities that you absolutely require. In the next section, we’ll dive into the specific capabilities in more detail in order to help you understand exactly what you need, and why.

Capabilities of the Hybrid/IDaaS Functional and Technical Landscape

The next level of the architecture outlines the functional capabilities that are the foundation for a best-in-class Hybrid 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/LOBs, 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, at this level 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 hybrid IAM foundation. For example, identifying, securing, and collecting data pertaining to IoT devices is expected to be accommodated within the Hybrid IAM Reference Architecture.

As ultimately implemented, different enterprises enable 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. And they do so with solutions that simultaneously run on-premises and in the cloud. One size does not fit all.

The next layer of the TechVision Research Reference Architecture for IAM (Figure 2) allows us to identify the IAM capabilities that are to be supported in the hybrid IAM infrastructure.

Figure 2: IAM Capabilities Within Reference Architecture

Broken record time: it is important to acknowledge that the hybrid IAM Reference 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 hybrid IAM architecture. Please note that these are short summaries of IAM capabilities that are described in much more detail in several TechVision Research reports.

Interact Layer Capabilities

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 Capabilities

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. 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.
2. 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.
3. 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.
4. Single Sign On – the ability to authenticate to multiple applications and systems with a single authentication event.
5. Remote Access 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.
6. Password management – the ability to reset user passwords and change/update user passwords via self-service interfaces.
7. 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.
8. Access key management – involves the monitoring and recording of each key’s access, use and context.
9. 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.
10. 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.

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 similar to 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, 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, makes a decision 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 Capabilities

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 of time.
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 actually 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 – similar to 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 of time 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 a number of 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 Capabilities

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 Capabilities

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 Capabilities

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 of time, 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 hybrid IAM architecture should encompass 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. In the subsequent section, we’ll look at sample hybrid IAM Reference Architecture patterns that incorporate both on-prem and in-cloud services and capabilities.

Sample Hybrid IAM Reference Architecture Patterns

With this comprehensive understanding of the overall IAM Reference Architecture, we now look at some examples where our customers have deployed various IAM services and capabilities in the cloud using solutions offered by IDaaS vendors.

Hybrid Authentication Service Pattern

Typically, end users, devices/things, application service accounts and network services all need to “login” and be authenticated and authorized to perform functions enabled by IT. The Authentication Service requires discrete capabilities within the IAM infrastructure that will facilitate a low friction but appropriately secure experience. In the template below, we’ve illustrated the IAM capabilities required for the Authentication Service, removing all other IAM capabilities that are not directly supporting the service. At this point, we are not focused on whether each capability is enabled via on-prem or in-cloud services. That will come later.

Figure 3: Sample Authentication Service Capabilities Map

The capabilities necessary to support the Authentication Service have been color-coded as follows:

• Rose – requires significant investment over next 2 years. The enterprise currently does not support these IAM capabilities.
• Orange – requires investment over next 2 years. The enterprise either currently does not support these IAM capabilities or they may require additional investment and deployment in order to achieve a requisite level of functionality.
• Grey – indicates capabilities that the enterprise IAM has in place in some capacity, although it could be likely that some augmentation may be required to improve functionality and ubiquity to fully meet its requirements.

 

Generically, the Authentication Service IAM capabilities are used as input to the development of the Reference Architecture pattern illustrated below.

Figure 4: Typical Authentication Service Pattern

Now, let’s take a look at this Authentication Service pattern when the enterprise determines that it wants to leverage a passwordless MFA solution enabled by a 3^rd party vendor’s IDaaS offering. In this example, we’ll leverage Trusona’s authentication-as-a-service Workforce Passwordless MFA solution. Founded in 2015, Trusona provides cloud-based authentication to its customers who require leading (but not bleeding) edge capabilities to address workforce or customer login. For example, workforce end users can deploy Trusona’s mobile device agent on their phones or workstations – or the enterprise can stand up the Trusona proxy server in front of its front-end interface, such as the App Dashboard illustrated in the Reference Architecture.

Below is an illustration provided by Trusona that shows how its authentication as a service functions:

Figure 5: Trusona’s Authentication as a Service Architecture

Taking this vendor-supplied architecture and incorporating it into our Authentication Service Pattern is quite straightforward. As shown below, we have added the Trusona Proxy Front End, Back End and Data Store to the pattern in order to address where they fit and what functions they perform.

Figure 6: Vendor Specific Hybrid Authentication Service Pattern

Note that in Trusona’s case, the method of integration is through the FIDO2 WebAuthn (or Web Authentication) API, which is a specification of a JavaScript API that allows applications to perform secure authentication for both multi-factor and single-factor scenarios. The FIDO2-provided high-level architecture is show below. This is important to consider because this can provide an additional level of detail regarding the integration mechanism between Trusona and the Hybrid IAM Reference Architecture.

Figure 7: FIDO2 Application Architecture

What is key to note is that the original Authentication Service pattern remains relevant, as the only important distinction between the two patterns is associated with the chosen vendor’s solution being indicated and integrated into the pattern (i.e., the Trusona Proxy Front End, Back End and Data Store). When these components are inserted into the pattern, the resultant architecture becomes “alive” with the specific vendor solution.

This tenet should hold true for all IAM services and capabilities, as we’ll show in the next section addressing hybrid privileged access management (PAM) integration.

Hybrid PAM Service Pattern

In the template below, we’ve now illustrated the IAM capabilities required for a typical organization’s Privileged Access Management, removing all other IAM capabilities that are not directly supporting the PAM service. Note that this representation includes a typical ‘user story’ in the form of “As an Application Administrator, I want to…”. User stories help keep the focus on the capabilities necessary to support it and we highly recommend you work through your key user stories.

Figure 8: Typical PAM Capabilities Map

Note that this is intended to provide a sense for how to apply the Reference Architecture to specific capabilities and to give a sense for typical relative timing. In our example, we have determined that the IAM-related capabilities necessary to support the hybrid PAM Service for a large organization can be color-coded as follows:

• Rose – requires significant investment over next 2 years. This typical organization does not currently support these IAM capabilities. An example is JIT PAM (Just In Time access).
• Orange – requires investment over next 2 years. The organization either currently does not support these IAM capabilities or they may require additional investment and deployment in order to achieve a requisite level of functionality. For example, most organizations currently support some form of MFA, but additional investments will generally be required.
• Grey – indicates capabilities that the organization IAM has in place in some capacity, although it could be likely that some augmentation may be required to improve functionality and ubiquity to fully meet the organization’s requirements. An example here is Federation/SSO which may be relatively mature in many organizations – but could be enhanced over the next few years.

PAM tools traditionally provide an additional layer of security in support of administrative and other high-risk access. The policies maintained in the PAM control service dynamically evaluate the risk of a given operation based on a variety of environmental and risk factors and filter access if risk exceeds a defined threshold. This extends from the internal network to external connections. However, note that other ‘user bases’ including non-administrative end users accessing regulated or secret/sensitive information need to be included in the expanding PAM footprint.

With this in mind, the Reference Architecture pattern below illustrates ‘what good looks like’ for a given organization- again, with a vendor-neutral approach. This pattern should be indicative of what the enterprise wants (and needs) in order to understand how to begin sourcing the pieces of the architecture either on-prem or in-cloud.

Figure 9: Example PAM Reference Architecture Pattern

This pattern supports the use case in which an application programmatically ‘checks out’ the service account credentials from the PAM service, eliminating the need for setting up hard coded credentials for the service account and guaranteeing that the service account credentials are continuously recycled. The overall PAM environment should be viewed as the gatekeeper to privileged operations. Also, even though not static, PAM still needs to Authorize as to who can access and make requests via JIT PAM. Thus far we have discussed the nature of privileged access management, its various approaches and anticipated market trends.

Similar to the previous hybrid IAM example, we’ll now look at CyberArk – perhaps the leading PAM vendor (at least by market share) and see how their offering maps to our pattern. CyberArk provides centralized, tamper-proof audit records for all privileged access activities, with personal accountability for any access or usage of shared privileged accounts.

The CyberArk PAM solution is intended to provide a ‘safe haven’ for the organization where all administrative passwords can be securely archived, transferred and shared by authorized users, such as IT staff, on-call administrators, and local administrators in remote locations. CyberArk encompasses multiple security layers, including firewall, VPN, authentication, access control, encryption, and more. The PAM interface is accessed and managed through a Windows Client, a Web interface, or a variety of APIs.

As can be seen below, the CyberArk PAM solution components map cleanly to the future state, vendor-neutral hybrid IAM Reference Architecture pattern.

Figure 10: Vendor Specific PAM Pattern

As shown in Figure 10, CyberArk provides a number of on-prem and in-cloud capabilities, described below:

1. The Vault – the secure repository that holds the data and is responsible for securing the data at rest and ensuring authenticated and controlled access must be further deployed to securely store administrative credentials for accessing all cloud-based resources used by the enterprise.
2. The Password Vault Web Access Interface – this web interface for requesting, accessing and managing privileged passwords throughout the enterprise needs to expand to include cloud-based administrative accounts – whether human or machine administrators.
3. PrivateArk Administrative Interfaces – this tool is useful for extending PAM capabilities beyond the on-premises realm and will become more crucial as the work-from-home culture continues.
4. The Central Policy Manager – this utility may be expanded to address cloud-based administration privilege management and security.
5. Privileged Session Manager – enables organizations to secure, control and monitor privileged access to network devices. This utility may be expanded to address cloud-based administration privilege management and security.
6. Privileged Session Manager for SSH – same as above including administrator access using the SSH (Secure Shell) protocol. This utility can be expanded to address cloud-based administration privilege management and security.
7. Privileged Session Manager for Web – provides proxy-based session isolation for secure access for SaaS/IaaS/PaaS administrators and privileged business users. Key features of this component also include enabling native access to cloud applications and transparent user experience, providing a risk-based approach to monitoring user activities within cloud applications. This utility may be expanded to address cloud-based administration privilege management and security.
8. On-Demand Privileges Manager (ODPM) – enables organizations to secure, control and monitor privileged access to UNIX commands by using Vaulting technology to allow end users to perform super-user tasks with their own personal account, while maintaining the least-privilege concept. This utility can be expanded to address cloud-based administration privilege management and security.
9. Privileged Threat Analytics (PTA) – continuously monitors the use of privileged accounts that are managed in the CyberArk platform, as well as accounts that are not yet managed by CyberArk, and looks for indications of abuse or misuse of the CyberArk platform. It also looks for attackers who compromise privileged accounts by running sophisticated attacks, such as Golden Ticket. This utility may be expanded to address cloud-based administration privilege management and security.
10. The Password Upload Utility – uploads multiple password objects to the Vault. This utility may be expanded to address cloud-based administration privilege management and security.
11. SDK Interfaces – eliminates the need to store application passwords embedded in applications, scripts or configuration files, and allows these highly sensitive passwords to be centrally stored, logged and managed within the Vault. The Application Password SDK provides a variety of APIs, including Java, .Net, COM, CLI and C/C++.
12. Administrative APIs – CyberArk Vault’s Command Line Interface (PACLI), enables users to access PAM from any location using automatic scripts, in a command line environment. This utility can be expanded to address cloud-based administration privilege management and security.

As can be seen, on-prem and in-cloud privileged access management can be integrated across the IAM Reference Architecture, and the resulting capabilities can dramatically improve the enterprise security posture when implemented. Now, let’s consider identity data integration in hybrid environments, and area of focus that has bedeviled many IAM and Security Architects.

Hybrid Identity Data Integration Pattern

Identity Data Integration is an important IAM capability that provides the means for the enterprise’s applications locate, describe and manage resources on a “network”. Most IAM systems authenticate resources based on their identity in a directory infrastructure such as Active Directory/Azure AD, as well as authorize access to systems based on the resources’ identity attributes such as roles or group membership (e.g., AD/Azure AD). Given that this data is pretty much sprawled across multiple on-prem and in-cloud repositories, a robust approach to relying and using this information during run-time is exceedingly important today.

An important objective for most enterprise IAM environments is to better standardize how coarse- and fine-grained authorization is performed by funneling all IAM data access through what TechVision Research refers to as an Identity Data Service. Identity data services provide applications secure access to identity data to meet operational needs such as authentication and authorization while protecting sensitive identity information.

The necessary components and features in an identity data services deployment include an identity data services interface, a directory management and audit interface, directory access protocols such as REST endpoints (APIs), Lightweight Directory Access Protocol (LDAP), Web Services (WS), Java Database Connectivity (JDBC), and Structured Query Language (SQL), virtualization services (such as virtual directories), synchronization services (such as meta-directories), and directory services.

For this set of core identity data service capabilities, a strong vendor we’ll describe here is Radiant Logic. The company, founded in 2000, created the first virtualized identity directory, which has been deployed successfully around the globe. Their solution is an intelligent identity data platform that acts as a broker between applications and identity stores that does not rely on simple replication or traditional batch synchronization. Instead, the platform virtualizes data silos to build a unified version of identity. A persistent data cache with automatic, event-driven refresh enables speed, scalability, and integrity in environments with high volume, data distribution and complexity.

The platform is based on Radiant Logic’s Identity Data Fabric architecture, which includes a federated identity engine and universal directory, single sign-on enablement, global synchronization across legacy and cloud applications, and an insight and reports interface showing a user’s global profile across multiple authoritative sources.

Figure 11: Radiant Logic RadiantOne Identity Data Fabric

The Radiant Logic RadiantOne platform integrates identities across any number of authoritative data sources, including directories, databases, and web services, into what the company calls “unified views.” Using the RadiantOne platform as a vendor specific example, the IAM Reference Architecture pattern for Identity Data Services is depicted below, with various run-time data integration and consumption services and components that can be enabled via this method.

Figure 12: Vendor Specific Identity Data Services Pattern

The role of the API Gateway (e.g., Apigee) is illustrated here to underscore its position as the ‘front door’ to the IAM APIs and the primary underlying identity data access service enabled via the Radiant Logic Identity Data Fabric (i.e., RadiantOne). It provides the ability to map common or disparate identity sources into a unified view and to provide authentication, authorization and federation support. In the pattern illustrated above, this acts as the single common abstraction layer that interfaces with Microsoft Active Directory, Azure AD, GCP, AWS, InTune mobile device registry, SAP, Mainframe security systems and ADP/Vantage – as key examples.

Now we have seen how a relatively generic IAM Reference Architecture can be successfully expanded to incorporate specific vendor’s cloud-based service offerings. In summary, this exercise can be especially useful for Enterprise Architects and Security leaders to understand much more clearly how their IAM infrastructure can migrate from on-prem to in-cloud with a multitude of hybrid approaches.

In the next section, we’ll briefly review and discuss IAM and Security Governance – an oft-forgotten craft that can make or break any IT strategy.

Risk Management and IAM Governance Is Foundational to Deployment Success

In our recent TechVision Research document titled “Integrated IT Governance Programs for the Digital Enterprise”, we discuss in detail how protection of information assets is necessary to establish and maintain trust between the enterprise and its customers, partners and oversight bodies, maintain compliance with the law, and protect the reputation of the organization.

In TechVision’s view, IT risk management is about availability, access, accuracy and agility as well as security. Any risk management plan must be based on the realization that risk cannot be eliminated, only mitigated, and must apply the available resources to reduce risk to a level acceptable to senior management. Specifically:

• Organizational strategy considerations are critical in determining the relative value of a risk and mitigation costs.
• Leaders must be consulted in both the prioritization of risk and the best method or combination of methods for mitigation. IT must contribute as well, since not all risks are apparent to non-IT leaders.
• Once the risks are understood and a consensus on how to manage them is reached, risk management is based on the three disciplines of:
  1. a well-structured foundation of IT assets,
  2. a well-designed and executed risk governance process
  3. a risk-aware culture

Therefore, a consistent Governance, Risk and Compliance Program represents table-stakes and individual organizations and their service providers must maintain effective Risk Management programs appropriate for their operational complexity. As we have said, appropriate risk identification and mitigation requires integrating people, process and technology.

An organization establishes and maintains truly effective IT governance and risk management when it continuously integrates processes, people, and technology to mitigate risks based on recent risk assessments and the organization’s risk tolerance levels. Nobody can define your organization’s risk tolerance levels for you, though regulatory pressure will certainly provide much input.

Governance of the IAM infrastructure is crucial because this is where the business meets the people, processes and technologies that support it. Organizations often struggle with creating, sustaining, and completing IAM initiatives. They tend to reuse the same program management techniques that were effective for non-IAM initiatives, only to discover such practices yield unsatisfactory results for IAM. A successful IAM program demands adoption of a formal program management model that emphasizes consensus-based vision from a broad range of stakeholders – including business leaders.

In many ways, IAM is no different from any other large business process engineering effort. Today, many large organizations’ IAM environments are primarily viewed as an IT responsibility. However, delivering technology is not the most significant challenge; fully understanding business needs and changing participants’ behavior are greater challenges. As the ensuing age of Zero Trust begins to materialize, the IAM program must be managed and viewed as a business program, not simply an IT – or even security project.

A well-organized IAM program provides the necessary structure for all IAM services in a way that addresses the challenges of coordinating technology projects that require identity-related services, ensuring alignment with business needs and providing oversight of ongoing operational activities.

Figure 13: IAM Governance Activity Cycle

Governance of the IAM program is important to ensure:

• Alignment of IAM investments with business priorities
• Effective IAM policies, standards, and processes
• Harmonization of IAM activities and communication across multiple functional areas

Technology deployment without appropriate governance simply cannot succeed. Therefore, TechVision recommends that enterprises immediately begin engaging in the following activities:

• Establish an IAM Steering Committee (if you don’t already have one)
• Engage an executive sponsor for the IAM program
• Articulate the purpose and authorities of the steering committee, preferably via a formal charter
• Engage decision-making IAM stakeholders to participate in an IAM steering committee
• Conduct periodic meetings (monthly if possible), with a focus on decision-making rather than information sharing since information-sharing forums tend to lose focus and participation over time
• Charge working groups as needed to provide input to the steering committee. Many of the same people are likely to be required for multiple working groups, so care must be taken to avoid over-extending individuals by running too many working groups simultaneously
• Record all meeting minutes and distribute to stakeholders through a formalized communication channel (at minimum, email distribution lists)
• Publish IAM policies and standards that encompass all regions globally.
• Build IAM requirements into the standard set of security requirements for projects, contracts, and procurements
• Train project managers and IT procurement specialists in implementing new IAM-related checkpoints
• Develop methods to ensure policies and standards are followed. Develop methods to track and record exceptions that assign residual risk ownership to the appropriate business stakeholder(s)
• Review current contracts and agreements where identity data or access to corporate resources is involved to assess whether IAM requirements are clearly and appropriately addressed. Establish a project to implement remedial actions as necessary.

Hopefully, it is apparent that much “people and process” needs to be thoughtfully involved in the development of a hybrid IAM strategy. If not, technological interests will supersede sound business logic.

Begin Deployment and Measure Progress

You can see that there is a logical progression of steps necessary to implement hybrid IAM properly. With requisite Reference Architecture pattern(s) identified, the IAM-related capabilities necessary to support the patterns are identified (and where deficient- being addressed), and a vendor solution can be intelligently identified and procured. There are far too many horror stories that tell of teams that ‘picked a vendor and deployed’ in the absence of this pre-work. In these sad tales, the IAM solution deployment typically becomes almost completely vendor-driven, based on what the vendor or Systems Integrator feels they can provide easiest and most profitably. Careers have been derailed by not doing this pre-work.

Your own organization’s deployment roadmap will depend on a number of factors specific to you:

• Business and functional requirements
• Risk levels germane to important information assets
• The existence and maturity of IAM capabilities that will need to support hybrid environment

While there may be finer-grained inputs driving the vendor selection and deployment roadmap, these three factors will lead the way. Using your vendor-solution mapped patterns as a visual cue, you can more readily decide which IDaaS solution(s) to deploy where and for what purpose.

Summary

We hope you have found this report useful. TechVision Research feels that hybrid IAM is one of the most critical elements of an enterprise security posture and is becoming increasingly important. This report, perhaps more than another other published paper, leverages TechVision’s decades of consulting work with large organizations. While most organizations are migrating to cloud-based services, the reality is that most are not fully there and we must architect, manage, govern and secure this hybrid IAM world. This paper describes tools and approaches to do so.

From a security perspective, hackers and thieves focus on less-than-stellar integration of on-prem and in-cloud IT functions because that is the way to your data. No matter how far along you are (or aren’t) in IAM deployment, don’t delay developing a Reference Architecture for IAM, which includes documented business and technical requirements, a comprehensive, defensible set of patterns mapped to existing and required capabilities and vendor solution capabilities that encapsulate on-prem and in-cloud capabilities. With these elements all addressed, you will be able to select the appropriate vendors and deploy the solutions to fit your IAM environment and address specific information protection risks.

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 leading global identity management/security 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.