Access Management FAQ

Identity and Access Management (IAM) is a sub-discipline of data security that comprises two sets of functionalities: Identity Governance and Administration (IGA) and Access Management (AM).

IAM provides a methodic framework for granting (and requesting) access to applications (IGA), enforcing access controls (AM) and ensuring visibility into access events (AM).

IGA solutions help answer the questions, “Who should receive access, or who is ‘entitled access,’ to which application?” and “Who in practice was granted access to which application, by whom and when.” AM solutions help answer the questions, “Who accessed what and when, and how was their identity verified?”

An Identity and Access Management (IAM) solution is composed of Identity Governance and Administration (IGA) functionality and Access Management (AM) functionality. IAM provides a methodic framework for granting (and requesting) access to applications (IGA), enforcing access controls (AM) and ensuring visibility into access events (AM). Given that most organisations deploy the IGA and AM components separately of each other, these disciplines are being increasingly evaluated as distinct, standalone solution families, rather than as composite functionalities of a single IAM suite.

Access management is a functionality that enables determining whether a user has permission to access a certain resource, and enables the enforcement of the access policy that has been set up for that resource.

Access management is implemented based on access policies that are defined by IT administrators and include such information as which groups of users (e.g. Sales, R&D, HR) are allowed access to which cloud applications (e.g. Salesforce, Office 365, Jira, Taleo), as well as the set of user attributes required to access each application (e.g. trusted network, password, OTP).

The access policy can require more or less user attributes to be assessed depending on the sensitivity of a cloud application. These attributes are assessed using risk-based or context-based authentication, which is central to enforcing the different access policies defined for each cloud application. (For more details, see context-based authentication.)

Also central to cloud access management is single sign-on, which enables the use of a single username-and-password set or ‘identity’ to log in to all one’s cloud applications. (For more details, see single sign-on.)

IDaaS is IAM-as-a-Service, and is also called identity-as-a-service. IDaaS describes Identity and Access Management (IAM) solutions that offer a cloud-based as-a-service delivery model for Identity and Access Management. While IDaaS has been reviewed as a separate market in recent years, given recent market trends, going forward it will be treated as two separate disciplines – that of Access Management and IGA, whose delivery methods include on-premises installations, software or cloud-based platforms.

Identity Governance and Administration (IGA) is a set of functionalities that helps answer the questions, “Who should receive access, or who is ‘entitled access,’ to which application?” and “Who in practice was granted access to which application, by whom and when.” For example, an IGA solution may help establish that R&D staff are entitled access to certain development applications, such as GitHub, Jira and Confluence. An IGA solution can automatically provision access to these applications, based on their R&D group membership. The R&D user may also request to be provisioned access to other applications, a request which would then go through a management approval process that is supported by some IGA solutions.

Identity federation is an architecture based on a single Trusted Identity Provider (“IdP”) that governs the authentication of users, with applications relaying the authentication process to the Identity Provider each time a user attempts to access them. Applications that relay the authentication process to the Trusted Identity Provider are called Service Providers (“SPs”).

Identity federation solves the challenges and frustrations of managing credentials for numerous web apps separately, whether internal or external to an organisation, and enables administrators and users to maintain a single username-and-password set (or ‘identity’) for multiple applications and IT resources. Identity federation eliminates password fatigue, improves security and solves the problem of handling countless password rests.

Identity federation relies on federation protocols such as SAML and Open ID Connect, as well as proprietary protocols such as Microsoft’s WS-Federation.

Federated login is a function of federation protocols (e.g. such as SAML, Open ID Connect, etc.) that enables users to log in to multiple applications using their current enterprise identity. For example, instead of logging in to separate cloud applications using different username-and-password sets, or “identities,” federated login lets users log in to Office 365, Salesforce, AWS etc. with the same identity they use to log in to the corporate network in the morning, or the VPN at night.

An identity provider is a system that authenticates users that are attempting to access other unaffiliated websites (‘service providers’). Identity providers, together with service providers, comprise an identity federation architecture, in which users that attempt to access a website (or service provider), are relayed to the identity provider for authentication. The identity provider verifies the user’s authentication data (e.g. user’s cookie, device, network, OTP) and produces an “accept” or “reject” response which is then sent to the service provider. Identity providers can also request authorisation to access certain data on behalf of another unaffiliated website. Authorisation data may include the permission to access such information as email addresses from a webmail account or names of friends from a social network account.

For example, SafeNet Authentication Service acts as an identity provider when users access cloud applications as in the scenario described above.

A Security Token Service is a system that authenticates users that are attempting to access other unaffiliated websites, or 'relying parties'. Security Token Services together with relying parties comprise a Security Token Service architecture, in which users that attempt to access a website (relying party), are relayed to the Security Token Service for authentication.

Security Token Services are also called identity provider models or token-based authentication. A Security Token Service (STS) is equivalent to an identity provider, and a relying party (RP) is equivalent to a service provider. And instead of exchanging SAML assertions, these are called Security Tokens. Different names, same concept.

The Security Assertion Markup Language, or SAML (pronounced ‘sammel’) is an XML-based open standard for exchanging authentication data between unaffiliated websites, a capability that is also called identity federation or federated authentication.

Identity federation means the ability to extend users’ current enterprise identities to the cloud, enabling them to log in to their cloud applications with their current enterprise identity. Federated authentication to cloud apps with SAML allows users to log in to all their cloud applications with their current enterprise identity, so that instead of maintaining 5 or 25 username-and-password sets, they can maintain just one.

How SAML Works
When a user attempts to log in to a cloud-based application, they are redirected to a trusted Identity Provider for authentication. The identity provider collects the user’s credentials, for example, their username and one-time-password, and it returns a response to the cloud application being accessed. This response is called a SAML assertion, and the SAML assertion contains an accept or reject response.

Based on this response, the service provider, e.g. Salesforce, Office 365 or DropBox, blocks or grants access to the application.

WS-Federation Services, or WS-Fed, is Microsoft’s proprietary identity federation protocol. WS-Fed works with Microsoft’s Active Directory Federation Services, or AD FS, to extend identities stored in Active Directory to Microsoft cloud applications such as Office 365 and Azure. Like SAML, WS-Fed users an Identity Provider model. When accessing a Microsoft cloud application, the user is redirected for authentication to AD FS, based on whose response the cloud application grants or denies the user access.

OAuth (pronounced "oh-auth"), short for Open Authorization, is an open standard for federated, or ‘token-based’ authentication and authorisation between unaffiliated websites. As with other identity federation protocols, such as SAML, Open ID Connect and WS-Fed, OAuth enables logging into an application with an identity that is verified by a trusted identity provider. OAuth goes beyond federated authentication to enable users to authorise relying party websites to access certain account information such as contact names and email addresses. For example, OAuth is the protocol used by social network websites to access your webmail contacts and ask you if you’d like to invite your webmail contacts into your social networks.

OpenID Connect, like SAML, is an open standard identity federation protocol that uses an Identity Provider model. However, unlike SAML, which works using a cookie and therefore only works with applications that open in a browser (‘browser-based applications’), OpenID Connect provides a single-sign on framework that enables the implementation of single sign-on across browser-based applications, native mobile apps and desktop clients (such as rich clients and some VPNs). So while most single sign-on implementations today support only cloud and browser-based apps, as more identity providers adopt OpenID Connect, we’ll be able to authenticate just once in order to concurrently gain access to all our resources – be they desktop clients, browser-based applications or native mobile apps.

Bring Your Own Identity, or BYOI, is a term used to describe the ability of an enterprise or other organisation to support an identity that has been issued elsewhere, and enable secure access to resources using that identity.

In the identity management space, vendors and organisations are looking to enable employees and partners to user their own identity to access corporate resources. This identity could theoretically be any identity that provides a sufficient level of identity assurance – for example, government-issued identity cards, healthcare smart cards, as well as online identities, such as social identities, professional network identities and commercially-available identities such as FIDO. The enterprise and consumer worlds are merging closer together, with enterprise security teams under increasing pressure to implement the same type of authentication methods typically seen in consumer services.

An Identity Broker is a system that can support BYOI schemes by taking a user’s existing identity (or any number of existing identities), and allowing them to authenticate to unaffiliated websites using that identity. For example, an Identity Broker can support a user’s social identity or webmail identity, and allow that user to access a multitude of unaffiliated websites. Identity Brokers enable organiaations to support multiple identity providers.

Single sign-on (SSO) provides the capability to authenticate once, and be subsequently and automatically authenticated when accessing various resources. It eliminates the need to separately log in and authenticate to individual applications and systems, essentially serving as an intermediary between the user and target applications. Behind the scenes, target applications and systems still maintain their own credential stores and present sign-on prompts to the user’s system. SSO responds to those prompts and maps the credentials to a single login/password pair. (Source: Gartner)

SSO, whether in a standalone solution or a broader access management solution, can be achieved through a range of identity federation protocols. These include open-source protocols such as SAML 2.0 and Open ID Connect, proprietary protocols such as Microsoft’s WS-Federation, and other technologies such as password vaulting and reverse proxies.

A password vault, also called a password manager, is a simple way to create a single sign on (SSO) experience when a target application does not support identity federation protocols, for example, a legacy or custom application. Password vaults are systems that work by storing and encrypting the passwords of different websites. Instead of logging in to each application with a dedicated password, the user can simply authenticate with a master password (which in turn decrypts the password vault), eliminating the need to maintain disparate passwords.

Authorisation is a process that ensures that properly authenticated users can access only the resources which they are allowed to access, as defined by the owner or administrator of that resource. In the consumer world, Authorization may also refer to the process whereby a user ensures that a cloud-based application (for example, a social network) accesses only certain information from a non-affiliated website (for example, the user’s webmail account).

Authentication is a process in which a user’s identity is validated or verified based on the credentials that the user provides when logging in to an application, service, computer or digital environment. Most authentication credentials consist of something the user has, for example a username, and something the user knows, e.g. a password. If the credentials provided by the user match those that are stored by the underlying application or Identity Provider, the user is successfully authenticated and granted access.

Context-based authentication is an authentication method based on a range of supplemental information assessed at the time a person logs in to an application. The most common type of contextual information include a user’s location, time of day, IP address, type of device, URL and application reputation. Context-based authentication, also called risk-based or adaptive authentication, is central to the world of SSO and access management where the objective is to make the authentication journey as transparent and painless as possible.

By assessing a user’s login attributes, be they contextual (device, role, location) or behavior based (e.g. typing speed, page view sequence), single sign-on and access management solutions can continuously match the level of authentication required from the user with the access policy defined for each application. In this way, authentication is applied granularly – in the smoothest way possible – through an application’s access policy, rather than as a blanket, uniform rule for all enterprise resources.

Continuous authentication is a form of authentication that takes place continuously, each time a user accesses a new application or resource, in contrast to one-time or binary authentication, which provides a one-off yes/no decision that is only valid for a single login to a single application.

With a token, a password or a fingerprint – authentication is basically a yes / no decision: The system validates a user’s identity and either allows or denies them access to an application.

But thanks to newer technologies, such as context-based authentication or behavioral biometrics (for example, browsing pattern, typing pattern and other physical traits), authentication can become a more continuous process. By assessing a range of attributes such as IP address, mobile parameters, known device, operating system etcetera, contextual or risk based authentication can continuously verify a person’s identity each time they log into an application. In fact, it can do so without the user even knowing.

Contextual authentication offers many frictionless ways of verifying a person’s identity. And this is what allows balancing user convenience with the ability to apply granular access controls to numerous cloud applications. And this is why the concept of continuous authentication – which is based on context-based authentication – is a foundation of cloud access management.