Skip to main content

Identity and Access Management (IAM)

What is identity and access management?​

Identity and access management (IAM) is the process of verifying a user’s identity and determining what resources they can access. By enforcing an IAM policy within your organization, you can control what permissions a user has, where they can access resources from, and when.

This degree of fine-grained access control is key to implementing a zero-trust security framework within your organization. Learn how Pomerium helps organizations adopt zero trust starting with IAM.

If you're unfamiliar with IAM, review the following core concepts below:

OAuth 2.0 and Open ID Connect (OIDC)​

OAuth 2.0 is an authorization protocol that defines how a user can grant an application limited access to their resources without exchanging details like their username or password. Instead, the application uses an authorization grant to request access to the user's resources from a resource server.

Open ID Connect (OIDC) is an authentication protocol built on top of OAuth 2.0. In the case of OIDC, an authorization server verifies the identity of the user and stores that information in an ID token (JWT). The ID token contains identity-related data in the form of claims, and the ID token is passed from the server to the application.

Together, these protocols offer a secure and scalable method for organizations to authenticate and authorize users.

Identity provider (IdP)​

An identity provider (IdP) is a service, like Google or Okta, that stores digital identities (information about a user). When an application needs to verify a user’s identity (OIDC) or request resources on behalf of a user (OAuth 2.0), it speaks to the IdP first. This way, the user only needs to authenticate against the IdP, not the application they want to access.

In the case of Pomerium, the proxy service routes requests to upstream applications and relies on other Pomerium services, like the authentication and authorization services, to handle identity verification with your IdP and to process policy to make access control decisions.

How Pomerium handles authentication and authorization​

Two core concepts within IAM are authentication vs. authorization:

  • Authentication (AuthN) verifies your identity (Are you who you say you are?)
  • Authorization (AuthZ) determines if you’re allowed to do what you’re trying to do (Do you have permission to access the resource?)

Pomerium provides a standardized interface to add access control, regardless if an application itself has authorization or authentication baked in. This allows developers to focus on their app's functionality, not reinventing access control.

Authentication (AuthN)​

Pomerium provides authentication through your existing IdP and supports all major single sign-on (SSO) providers, including Okta, Google, Azure AD, AuthO, Ping, and GitHub.

Authorization (AuthZ)​

Pomerium handles authorization with its high-level, declarative Pomerium Policy Language (PPL). You can configure an authorization policy using PPL to enforce attribute-based access control (ABAC), role-based access control (RBAC), or any other governance policy controls.

Pomerium can make holistic policy and authorization decisions using external data and request context factors such as user groups, roles, time, day, location, and vulnerability status.

Zero-trust access​

Pomerium enables zero-trust access. This means trust flows from identity, device state, and context – not network connection.

With Pomerium:

  • Requests are continuously re-evaluated on a per-request basis
  • Authorization is context- and identity-aware: You can use Pomerium to integrate data from any source into authorization policy decisions
  • Trust flows from user and device identity, meaning you can authenticate, authorize, and encrypt communication between every user, device, and application

Audit logs​

Pomerium provides detailed audit logs for all activity in your environment. This enables you to quickly detect anomalies to mitigate bad actors and revoke access.

Users and groups​​

Pomerium populates users and groups from your IdP. This data is cached to prevent hitting API rate-limits, ensure policy enforcement performance, and provide look-ahead support when adding users or groups to Namespaces and Policies.

Non-domain users​​

You may encounter a situation where you may want to add users that are not directly associated with your corporate IdP service. For example, if you have a corporate Google Workspace account and want to add a contractor with a Gmail account, you would have two options:

  • Create a group within your IdP directly with the non-domain users in it. This group can be found and added to Namespaces and Policies.

  • Manually add the user's unique ID. Identify the ID from a user's Session Details page, or the Sessions page in Pomerium Enterprise. A user can see their session ID by navigating to the special /.pomerium URL endpoint from any Pomerium-managed route. The unique ID is listed as Sub under User Details:

    The User Details page, showing the "sub" data