pomerium/docs/docs
Bobby DeSimone dc12947241
all: refactor handler logic
- all: prefer `FormValues` to `ParseForm` with subsequent `Form.Get`s
- all: refactor authentication stack to be checked by middleware, and accessible via request context.
- all: replace http.ServeMux with gorilla/mux’s router
- all: replace custom CSRF checks with gorilla/csrf middleware
- authenticate: extract callback path as constant.
- internal/config: implement stringer interface for policy
- internal/cryptutil: add helper func `NewBase64Key`
- internal/cryptutil: rename `GenerateKey` to `NewKey`
- internal/cryptutil: rename `GenerateRandomString` to `NewRandomStringN`
- internal/middleware: removed alice in favor of gorilla/mux
- internal/sessions: remove unused `ValidateRedirectURI` and `ValidateClientSecret`
- internal/sessions: replace custom CSRF with gorilla/csrf fork that supports custom handler protection
- internal/urlutil: add `SignedRedirectURL` to create hmac'd URLs
- internal/urlutil: add `ValidateURL` helper to parse URL options
- internal/urlutil: add `GetAbsoluteURL` which takes a request and returns its absolute URL.
- proxy: remove holdover state verification checks; we no longer are setting sessions in any proxy routes so we don’t need them.
- proxy: replace un-named http.ServeMux with named domain routes.

Signed-off-by: Bobby DeSimone <bobbydesimone@gmail.com>
2019-09-16 18:01:14 -07:00
..
identity-providers docs: update site ui 2019-08-03 22:28:18 -07:00
quick-start authenticate: make service http only 2019-09-04 16:27:08 -07:00
reference all: refactor handler logic 2019-09-16 18:01:14 -07:00
background.md typo 2019-08-03 22:29:40 -07:00
CHANGELOG.md all: refactor handler logic 2019-09-16 18:01:14 -07:00
readme.md Remove duplicated text (#287) 2019-08-31 16:54:23 -07:00
releases.md release: v0.3.0 2019-09-01 10:29:26 -07:00
upgrading.md release: v0.3.0 2019-09-01 10:29:26 -07:00

title lang sidebarDepth meta
Overview en-US 0
name content
keywords pomerium overview identity-access-proxy beyondcorp zero-trust reverse-proxy ztn zero-trust-networks

Overview

What is Pomerium?

Pomerium is an identity-aware proxy that enables secure access to internal applications. Pomerium provides a standardized interface to add access control to applications regardless of whether the application itself has authorization or authentication baked-in. Pomerium gateways both internal and external requests, and can be used in situations where you'd typically reach for a VPN.

Pomerium can be used to:

  • provide a single-sign-on gateway to internal applications.
  • enforce dynamic access policy based on context, identity, and device state.
  • aggregate access logs and telemetry data.
  • a VPN alternative.

Architecture

System Level

Pomerium sits between end users and services which require strong authentication. After verifying identity with your IDP, Pomerium uses a configurable policy to decide how to route your user's request and if they are authorized to the service.

pomerium architecture diagram

Component Level

Pomerium is composed of 3 logical components:

  • Proxy Service
    • All user traffic flows through the proxy
    • Initiates authentication flow to Authentication service as needed
    • Verifies all requests with Authentication service
    • Processes policy to determine external/internal route mappings
  • Authentication Service
    • Handles authentication flow to your IDP as needed
    • Handles identity verification after initial Authentication
  • Authorization Service
    • Processes policy to determine permissions for each service
    • Handles authorization check for all user sessions

In production deployments, it is recommended that you deploy each component separately. This allows you to limit external attack surface, as well as scale and manage the services independently.

In test deployments, all three components may run from a single binary and configuration.

pomerium architecture diagram

Authentication Flow

Pomerium's internal and external component interactions during full authentication from a fresh user are diagramed below.

After initial authentication to provide a session token, only the authorization interactions occur.

pomerium architecture diagram

In action

To make this a bit more concrete, see the following short video which demonstrates:

  1. An unauthorized user authenticating with their corporate single-sign-on provider (in this case Google)
  2. The unauthorized user being blocked from a protected resource.
  3. The unauthorized user signing out from their session.
  4. An authorized user authenticating with their corporate single-sign-on provider.
  5. Pomerium delegating and grating access to the requested resource.
  6. The authorized user inspecting their user details including group membership.