Configuring OIDC for SSH and Aporeto control plane users
Before you begin
Ensure that you have the company account administrator credentials.
Familiarize yourself with the following sequence, particularly the bolded URLs. Hover over the numbers for additional details.
Once the user obtains an Aporeto token containing the claims from the identity provider, they can use it to access:
- Aporeto control plane
- Aporeto web interface
- Remote hosts via secure shell (SSH)
Aporeto checks the policy you've defined against the claims in the Aporeto token to determine whether to allow the user access.
Adding Aporeto to the identity provider
While OIDC is a standard, each identity provider provides a different web interface. This section guides you through the setup at a high level.
Many identity providers orient their offerings towards developers. Good news! With Aporeto, you won't need to write any code to integrate with the identity provider.
Web application: Identity providers often support a variety of application types. If prompted, select web application.
Callback URLs: Supply the identity provider with the following whitelist of callback URLs. Identity providers sometimes refer to these as redirect URIs.
Client ID and client secret: The identity provider supplies a client ID and a client secret value. These values allow Aporeto to communicate with the identity provider. Store these values in a safe place. You'll need them in subsequent procedures.
Scopes: If requested, identify the scopes you will request. Though Aporeto sends the desired scopes in its request, some identity providers may keep their own list.
Confirming the identity provider's discovery endpoint
Most identity providers offer a discovery endpoint, although this is optional in the specification. Aporeto requires the discovery endpoint. Confirm that your identity provider supports it as follows.
Obtain the identity provider's URL. Your identity provider should make this value easy to obtain, but we provide some tips below.
Okta: the base URL is the same as the path in your browser when you access your account, without the
-adminstring. For example, if I access my Okta account at
https://dev-289699-admin.okta.com, my base URL is
/oauth2/defaultto the end. Example:
Azure Active Directory: append your tenant ID to
https://sts.windows.net/. For example, if your tenant ID is
cd629cb5-2826-4126-82fd-3f2df5f5bc7b, the URL is
Set an environment variable containing the identity provider's URL. An example follows. Replace
<identity-provider-url>with the identity provider's URL before issuing the command.
Confirm that your identity provider supports the discovery endpoint by issuing the following command.
It should return the JSON details of the OIDC configuration.
If you don't have curl installed, try replacing
wgetin the above command.
Adding the identity provider to Aporeto
Click the Create button to add a new identity provider.
Type the name of the identity provider in the Name field.
In the Endpoint field, add the identity provider's URL.
Paste the client secret in the Client Secret field and the client ID in the Client ID field.
Type the requested scopes in the Scopes field, pressing ENTER after each one. At a minimum, you must have
oidc. If the identity provider supports refresh tokens and you would like to enable this feature, also include the
To set this as the default identity provider, select Use this provider as the default.
If this is the only identity provider, we recommend setting it as the default. Otherwise, users will have to manually specify the value you typed in the Name field. It is case sensitive.
To add claims to the Aporeto token that identify the user, type the name of the claim in the Subjects field and press ENTER. You can enter more than one. For example, to include the first and last name of the user, type
given_namepress ENTER, and then type
family_nameand press ENTER. Let's imagine the user is named Bob Holden. The Aporeto token contains the following claim
Creating an API authorization policy
Open the App page.
Switch to the namespace that you want to give the user access to.
Expand Namespace Settings, click Authorizations, and click the Create button.
Type a name for the policy.
If you want the user to have access to namespaces beneath the current, select Propagate to child namespaces.
If you do not want this policy to be visible in the child namespaces, select Hide propagation to child namespaces.
@auth:realm=oidcin the Subject field and press ENTER. Then type the tag expression that defines which users should be allowed to access the resource. For example, if you wanted to accept a user with the email address
firstname.lastname@example.org, you would type
If you do not want to accept logins from anywhere, just from one or more subnets, specify the subnet or subnets in the List of authorized subnets field.
Select the roles that the user should have.
Congratulations! The user should now be able to click Sign in with OIDC to access the Aporeto web interface and use
apoctl auth oidcto log into