Authenticating users with OIDC
Integration with an OIDC identity provider gives your users single sign-on access to applications protected by Microsegmentation.
Microsegmentation uses the OIDC authorization code flow with a confidential client, as described in the OIDC 1.0 specification.
You can use scopes to request basic information about the user from the identity provider. If the user consents to the requested scopes, the identity provider returns the information to Microsegmentation as claims in an ID token. The claims in the ID token allow you to control which users can gain access.
All identity providers should support the following list of scopes and claims.
profilescope requests the following claims:
addressscope requests the
phonescope requests the following claims:
Each identity provider supports additional scopes and claims. Refer to the documentation of the identity provider to learn more. Request only scopes that return claims as string, array, or boolean values. Microsegmentation ignores other types of claim values.
The OIDC sequence requires a browser and is not suitable for authenticating applications.
Before you begin
Before beginning the configuration, ensure the following.
Microsegmentation recognizes the web application as a processing unit. Open the Network Security section of the Prisma Cloud web interface, select App Dependency Map in the side navigation menu, navigate to the namespace of the web application, and make sure you see it.
Review the tags of the processing unit representing the web application and locate one that identifies it uniquely.
Familiarize yourself with the following sequence, particularly the bolded URLs. Hover over the numbers for additional details.
In the examples below, we use:
- Google’s Hipster Shop, secured according to the instructions in Securing a Kubernetes namespace, and assigned the domain
- A user with the email
Adding your app 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 Microsegmentation, 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 URL: Sometimes referred to as a login redirect URI. Append
aporeto/oidc/callbackto the fully qualified domain name of your web application. For example, if users reach the application at
http://microseg-website.com, the callback URL would be
- A domain name is required.
You should obtain a domain name if you do not have one already.
If you cannot obtain a domain name, you can try appending
.nip.ioto its public IP address. However, these services can be flaky and increase the chance of errors. Example:
- Prefix the domain name with
httpseven if the application does not currently use TLS. The enforcer will manage the encryption.
- If you’ve exposed the application on a port other than 443, specify the port.
- A domain name is required. You should obtain a domain name if you do not have one already. If you cannot obtain a domain name, you can try appending
Scopes: Though the enforcer sends the desired scopes in its request, some identity providers may ask you to identify the scopes during the configuration. If requested, supply the scopes to the identity providers.
Once you have added your application to the identity provider, it should give you a client ID and a client secret.
Paste these values into
CLIENT_SECRET environment variables.
export CLIENT_ID="0oannpib3fQEeUWzD4x6" echo $CLIENT_ID export CLIENT_SECRET="qcnc1ZFABmwmFwFZD_BAffNRFUn5aYQhvrx4XsxU" echo $CLIENT_SECRET
Confirming the identity provider’s discovery endpoint
The OIDC specification does not require a discovery endpoint but Microsegmentation does. Most identity providers offer one. Confirm that your identity provider supports it as follows.
Obtain the identity provider’s address. Your identity provider should make this value easy to obtain, but we provide some tips below.
Provider Example Discussion Auth0
– Azure Active Directory
Append your tenant ID to
All clients use the same path. 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
/oauth2to the base URL. Then append the ID of your authorization server. If you have an Okta developer account, the ID is probably
IDP_URLenvironment variable containing the identity provider’s URL. An example follows.
Set an environment variable containing just the domain name of the identity provider. An example follows.
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
Identifying your web application
In the Network Security section of the Prisma Cloud web interface, navigate to the namespace of the processing unit that represents the web application. Take a few moments to review its metadata. Determine the tag that you’d like to use to identify it.
PU_TAGenvironment variable containing the Microsegmentation tag that identifies the web application. In the following example, we use the tag we used in the Hipster Shop tutorial.
Allowing the web application to initiate connections with the identity provider
ENFORCER_NSenvironment variable containing the Microsegmentation namespace of the enforcer for your application. This will be a grandchild-level namespace, either the namespace of your cluster or your host.
Use the following command to create an external network representing your identity provider.
cat <<EOF | apoctl api create externalnetwork -n $ENFORCER_NS -f - name: idp entries: - $IDP_DOMAIN associatedTags: - externalnetwork:name=idp propagate: true EOF
Use the following command to create a network ruleset allowing your application to connect to the identity provider.
cat <<EOF | apoctl api create networkrulesetpolicy -n $ENFORCER_NS -f - name: allow-app-to-idp subject: - - \$identity=processingunit - "$PU_TAG" outgoingRules: - action: Allow object: - - externalnetwork:name=idp protocolPorts: - tcp/443 propagate: true EOF
The enforcer must be able to reach the identity provider’s discovery endpoint. SSH into the enforcer host or one of the cluster nodes and execute the commands from the previous section.
export IDP_URL=<identity-provider-url> curl $IDP_URL/.well-known/openid-configuration
It should return the details of your OIDC configuration in JSON form.
Defining the HTTP resource
Next, we need to create an HTTP resource spec describing the kinds of requests your app will accept and the claims that must be in the user’s token.
Determine how you want to identify the users that should be allowed to access your app. You request information about the user from the identity provider (scope) and it returns that information as a claim. The claim becomes a Microsegmentation tag.
Identity provider Scope requested Example claim value Microsegmentation tag all
Microsegmentation supports logical expressions, allowing you to use multiple tags to identify users.
USER_TAGenvironment variable containing the Microsegmentation tag that identifies the allowed users.
export USER_TAG="email@example.com" echo $USER_TAG
Use the following command to create an HTTP resource spec that restricts access to the specified user. This spec allows
GETrequests to any resource in your web application (
/*). You can optionally add additional methods or allow access only to certain endpoints.
cat <<EOF | apoctl api create httpresourcespec -n $ENFORCER_NS -f - name: nginx endpoints: - URI: /* methods: - GET public: false allowedScopes: - - $USER_TAG associatedTags: - httpresourcespec:name=private-app propagate: true EOF
Defining the service
USER_PORTenvironment variable to store the port used to access the web application. We recommend using
443. Otherwise, users will have to manually specify the port when they access your app.
If your web application is running in Kubernetes, ensure that the
portin its service definition has the value
443. You can open the service for editing via
kubectl edit services <your-service-name>and modify the
APP_PORTenvironment variable containing the port that your web application is listening on. In Linux service deployments this is simply the port of the process. In container deployments this is the internal port of the container. If your web application is running in Kubernetes, this corresponds to the
targetPortin its service definition.
APP_DOMAINenvironment variable containing the domain name that people use to access your web application.
APP_URLenvironment variable containing the full URL of your web application.
Next, create a service definition. In the following example, we use
nameof the service definition and we also add a Microsegmentation tag
service:name=private-app. We request the
openidscopes. You should change these values to fit your circumstances.
cat <<EOF | apoctl api create service -n $ENFORCER_NS -f - name: private-app authorizationType: OIDC OIDCClientID: $CLIENT_ID OIDCClientSecret: $CLIENT_SECRET OIDCProviderURL: $IDP_URL OIDCCallbackURL: $APP_URL OIDCScopes: - email - openid hosts: - $APP_DOMAIN port: $APP_PORT exposedPort: $USER_PORT selectors: - - $PU_TAG - \$identity=processingunit associatedTags: - service:name=nginx type: HTTP exposedAPIs: - - httpresourcespec:name=private-app propagate: true EOF
If the identity provider supports refresh tokens and you would like to enable this feature, add the
Logging in as a user to verify
Open a new browser tab or private window.
Type the path to the application. Example:
Click through the warnings to accept the certificate from the enforcer.
The OIDC provider should pop up a browser window or tab requesting your login credentials.
After authenticating to the OIDC provider, you should see the welcome page of the application.
Open the Network Security section of the Prisma Cloud web interface, select App Dependency Map in the side navigation menu, and navigate to the namespace of the web application.
Click to view the details of the successful flows, as shown below.
apoctl to collect logs from the enforcer.
See Troubleshooting enforcer.