Important Decision Factors for Vendor Selection
IDaaS or Software
Organizations must decide whether operational management of access management solutions is core to their business, or whether the functionality can be outsourced. Setting aside vendors' variable abilities to meet different functional requirements, organizations that choose to manage access management solutions themselves tend to have the requisite staff expertise to manage the products and believe that they will retain these staff. Organizations that purchase access management software are more likely to have legacy applications that don't support standards-based SSO. They may be difficult to convert to standards-based SSO, and products from traditional software-based access managers can better support proprietary application integration techniques.
Software buyers also tend to be risk-averse with regard to having a third party manage their authentication and authorization services and hold personal information. There are also jurisdictional regulations and political concerns that may limit adoption of services that cannot host data exclusively within a jurisdiction, or that are operated by foreign companies.
IDaaS delivery was not widely available and able to meet broad use case needs until recently. The access management market got its start around the turn of the millennium, so there is a tremendous installed base of software. However, Gartner is seeing a clear and strong overall trend toward IDaaS adoption globally, with North America leading the demand. This trend is due to maturing IDaaS offerings; frequent, easy-to-consume functional upgrades; a lack of skills to manage traditional software solutions; increased buyer comfort with IDaaS; and significant marketing and sales initiatives from established vendors, notably Microsoft.
Buyers that choose IDaaS tend to be more focused on rapid time to value and do not view operational management of IAM functionality to be core to the business. IDaaS vendors in the IDaaS market began selling solutions predominantly to SMBs that had less ability to manage IAM. However, the average size of organizations purchasing IDaaS has risen. IDaaS is often used by midsize and large enterprises as an augmentation of existing IAM software implementations. IDaaS and software can be bridged together to deliver hybrid use cases (see "How to Choose Between On-Premises and IDaaS Delivery Models for Identity and Access Management").
Use Cases and Target System Support
Our evaluation of vendors' products and services in this Magic Quadrant included consideration of how well vendors can meet the need to support common use cases and target system architectures.
The primary driver for new access management purchases has been the need for workforce users to access SaaS applications. B2C is second, and different topologies for B2B and workforce users accessing internal systems (i.e., B2E) is third. All vendors covered in this Magic Quadrant can support these use cases. However, IDaaS delivery models tend to be superior for their SaaS enablement. Vendors create and maintain connections to SaaS vendors, so buyers don't have to. Gartner clients are more often interested in an IDaaS model for B2C needs. Gartner has observed an inquiry pattern in which clients are replacing homegrown IAM capabilities for their consumer-facing applications and are looking for rapid time to value. They often do not feel as strongly that consumer identities must be held on-premises.
Target system enablement is an area of vendor differentiation. Traditional access management software vendors had to develop federation, proxy and agent architectures into their products to support web applications with diverse authentication architectures. All access management vendors, regardless of their delivery models, support standards-based federation, with SAML support ubiquitous and OpenID Connect support maturing. Differentiation is most often found in vendors' abilities to directly support applications that require reverse proxy and HTTP header-style authentication. There are also commercial applications that can't easily support externalized access management, and they are integrated into access management tools with "agents" or "integration kits."
Traditional access management software vendors tend to support these tricky scenarios; however, support from pure IDaaS vendors is maturing. For example, Okta does not deliver the proxy or agent style of application enablement. Rather, it chooses to integrate with organizations' existing access management tools from its cloud service, or it partners for this functionality. Microsoft can also provide access management for customers' applications using federation or reverse proxy. However, it relies on Ping Identity's Ping Access product for applications that are architected to transmit proprietary information in HTTP headers for authentication and authorization. Clients that need support for legacy web applications should focus their vendor evaluations and proofs of concept on ensuring that access management tool vendors can support all target applications.
As organizations expose services through APIs, the need to protect the APIs and services behind them grows. API protection has long been the domain of the API gateway — a component of "full life cycle API management" products and services (see "Magic Quadrant for Full Life Cycle API Management"). API gateways are placed between calling services or applications and the target API. These tools provide a number of functions, including token and protocol translation, authentication, authorization, threat detection, data privacy, traffic and quality of service management, and service routing.
In some customer environments, API gateways are integrated with access managers because access management tools handle users' sessions and API gateways generally do not. This combination of tools allows a web application to offload user authentication, SSO and session management to the access management tool. If the application needs to call an API (e.g., to complete a transaction), the request — along with user attributes and security tokens — is sent to the API gateway to be parsed and evaluated to allow/disallow API access.
The access management market is evolving to handle some API gateway functions within the access management product. For example, Ping Identity and ForgeRock have functionality in their toolsets to perform some basic API authentication, authorization and traffic throttling. Okta has introduced an API access management service component. However, most buying organizations will continue to use a mixture of access management and full-featured API gateways, because of the additional value and functionality the gateways provide.
Gartner recommends that organizations, particularly those with numerous applications and diverse application architectures take a systematic approach to taking inventory of those applications, their use cases and architectures. The result of this exercise should put IAM leaders in a better position to evaluate alternative offerings to meet needs (see"How to Make the Right Choices for Access Management and Single Sign-On").
IoT and Access Management
Access management tools must increasingly support a variety of devices as source and target endpoints. The proliferation of devices, especially smart devices, has provided challenges to access management vendors, as well as opportunities. One of the first challenges was to support new application architectures including native mobile applications, single-page apps and hybrid apps. Access management vendors have done that by supporting OAuth and OIDC, as well as providing proprietary SDKs and APIs in their access management services. The opportunity that comes with the device proliferation challenge is that vendors have begun to use device context as input to render access decisions. This presents an additional capability to deter bad actors.
Most access managements can now deal with basic use cases that require managing access to support the relationships among people, their smart devices and the target resources that must be accessed. However, the incorporation of constrained devices and interactions with device intermediaries, such as gateways and controllers, remains a niche pursuit. ForgeRock has an edge gateway designed to integrate downstream devices and controllers with its platform. We expect more access management vendors to enable products and services with the protocols and policy decision capabilities to support IoT more broadly during the next three years.
User Authentication, Contextual and Adaptive Access
All access management tools have the coarse-grained foundational capabilities to require "step up" authentication when users have a specific set of attribute values associated with them and when accessing specific target systems. For example, if the user is a finance group member in the underpinning directory used by the access manager, then the access management system can allow only those users access to the application and force the user to reauthenticate. Otherwise, it can authenticate with something stronger than a password when accessing the finance system. These were and remain important capabilities. However, by themselves, they're not enough in today's climate of increased online fraud and malicious access.
Capabilities that had their genesis in the financial services industry have seeped into vendors' access management products and services — first as stand-alone products and then becoming more common as features in base products. For example, products from Oracle and CA Technologies have had "adaptive" and "advanced" authentication capabilities and were sold separately from the base access management tool. Now, most AM vendors can use contextual information, such as date and time; endpoint information, such as browser and software characteristics; and IP address or real geolocation as input to access decisions.
Buyers of access management products from vendors that also sell and integrate EMM products can expect more device context to be used in access decisions. For example, is the device registered, jailbroken or rooted? Does it contain a device certificate? Does it have the latest security patches? Centrify, IBM and Microsoft are examples of vendors in this Magic Quadrant that leverage these types of context derived from integration with their own EMM products portfolios in access decisions. Other vendors, such as Ping Identity and Okta, partner and integrate with EMM vendors' products, such as AirWatch and MobileIron, to provide this functionality.
SecureAuth has features that can detect the fraudulent porting of phone numbers to another carrier and device, thereby inhibiting impersonation and subsequent fraud. Microsoft has incorporated third-party data and its own data from myriad attack attempts on its services. It is using this data to provide analytics and reporting to Azure administrators on security threats, as well as elevate trust or deny access to Azure services. Buyers of access management products should expect more contextual and adaptive access features to become commonly available and more intelligent during the next three years (see "Take a New Approach to Establishing and Sustaining Trust in Digital Identities").
Security Concerns With IDaaS Delivery and Target Systems That Support Only Password Authentication
Password vaulting and forwarding is a feature set that access management vendors offer to their customers to support target applications that do not support federated SSO standards. Common, widely used SaaS applications support federation, which transmits security tokens (not passwords) to target systems. Federated architectures also imply that an access management tool or service is between the user and the application and can, therefore, implement MFA, and adaptive access control, as part of the sign-on sequence. However, the long tail of smaller SaaS application vendors does not support federation. It is common for access management buyers to want to leverage password vaulting and forwarding to give their users the convenience of SSO for most or all of their apps.
Access management vendors encrypt password data at rest; however, attackers can circumvent controls that protect encrypted data. Gartner recommends against the use of password vault and forward functionality provided by access management vendors — especially vendors delivering with IDaaS — due to this potential loss of the "keys to the kingdom." Standards-based federation should be used instead, whenever possible.
However, for the remaining password-based apps, many organizations will find the pressure to provide users convenience through password vaulting and forwarding unbearable. The use of additional authentication methods and adaptive access mitigates some types of attacks that leverage endpoint device and network vulnerabilities, but they do not help if the centrally held password data is compromised. Unfortunately, passwords are a weak form of authentication. Organizations choosing to allow SSO using password authentication are accepting the risks of potential password compromise. Gartner recommends that organizations push their application vendors to support standards-based federation as an alternative to password authentication only. These organizations should also maintain and test procedures for resetting users' accounts and passwords, should a breach occur (see "IDaaS Security Will Never Be Perfect — Buyers Must Mitigate Risk").