This section explains how to configure Appgate SDP to work with OIDC identity providers (IdPs).
OAuth 2.0 is an IETF specified framework designed to support the development of authorization and authentication protocols. OpenID Connect (OIDC) is the third generation of OpenID to be based on this framework. OIDC uses the standard TLS infrastructure, which is universally implemented on most platforms as well as JSON Web Token (JWT) data structures. The earlier versions, OAuth and OAuth 2.0, are not supported by Appgate SDP.
Appgate SDP and the OIDC implementation should provide great interoperability with many IdPs.
As the Relying Party (RP), AppGate ZTNA supports single sign-on authentication using OIDC IdPs such as ADFS, Okta, and Ping. OIDC can authenticate users connecting through the Client and administrators logging in to the admin UI.
Use the Identity Providers UI to configure OIDC
Configuring your OIDC IDP
The Appgate SDP settings and those of your OIDC IdP need to be configured to work together.
Application type
OIDC supports three application types: Web Application, Single-Page Application, and Native Application. Appgate SDP is a mixed mode RP as we use both browsers and native/mobile apps. While the OIDC implementation has been optimized to work as a Single-Page Application, it can work with other application types if required. Microsoft Entra have type of Native Application called Mobile and Desktop Applications which we recommend for for the Client redirect URI; a second platform can then be added using localhost redirects under a Single-Page Application for the admin UI.
Redirect URIs
The Redirect URIs are a list of URLs where the OIDC response can be sent. The actual URI used is in the authentication request, so the same OIDC configuration can be used by the full Client, Portal, or admin UI.
User Authentication on the Client:
The Client only supports HTTP:
Redirect URI = http://localhost:29001/oidc
User Authentication to the Portal:
The Portal acts as a redirection server, forwarding the OIDC response to the requesting Client:
Redirect URI = https://myportal.com/oidc
Administrator authentication on the Admin UI:
The Controller admin/API is on port 8443:
Redirect URI = https://mycontroller.com:8443/ui/
Scope
Any IdP will have a list of supported scopes that you can view by going to https://myidp/.well-known/openid-configuration
Attributes
The group attribute is not included in the OIDC standard, so it is not always passed in the token when the user signs in. This is useful when signing users in to Appgate SDP.
Every IdP has a different way to add attributes. In MS Azure it would be done by going to Token configuration in the OIDC app and clicking + Add groups claim.
Under Edit groups claim, choose the group types and add them to the "ID token" with the format you prefer and save.
Configuring Appgate SDP
Issuer and Client ID
The Issuer and Client ID are taken from the IdP's configuration screens. In some cases you may need to look in https://myidp/.well-known/openid-configuration where these exact terms should be available.
Scope
Scopes are groups of attributes that will be provided when the user authenticates.
There are several that have been defined in the OIDC standard:
openid. Required. Contains required claims for OIDC to operate correctly.
profile. Optional. User's default profile claims such as name, family_name, etc.
email. Optional. User's email.
address. Optional. User's address.
phone. Optional. User's phone_number.
Every OIDC IdP may add their own scopes, such as 'groups' or 'offline_access'.
The list defined should be a subset of the list of supported scopes. Undefined scopes will result in an authentication failure.
Refresh token
A typical access token might have a lifetime of 60 minutes. After this time the user is required to re-authenticate. The scope offline-access will return a refresh token in the authorization exchange. This can be used locally to obtain a new access token at any time. A refresh token will have a longer lifetime, such as 100 days.
The initial access token is used by Appgate SDP to authenticate the user and then discarded. The token lifetime is therefore somewhat irrelevant. Appgate SDP uses its own claims token to define when a user is required to re-authenticate. If there is a refresh token provided by the OIDC IdP, the user will not have to interact with the browser when the Client requires a new claims token as a new access token can be generated in the background.
User claims
The OIDC standard defines a number of the standard attributes that will always be available. It is therefore possible to provide a default set of user claims mapped from the OIDC attributes. These are:
sub mapped to claim userId (from scope openid)
preferred_username mapped to claim username (from scope profile)
given_name mapped to claim firstName (from scope profile)
family_name mapped to claim lastName (from scope profile)
email mapped to claim emails(array) (from scope email)
If you have added any extra attributes such as the Azure group (see above), then do not forget to map this to a claim.