Okta SSO Configuration

Praetorian Guard Platform Single Sign-On (SSO) with Okta

This guide sets up single sign-on between Okta and the Praetorian Guard Platform (PGP). You verify your domain, create an Okta application, then add it as a provider in PGP. You need three values from Okta:

• Client ID
• Client Secret
• Issuer URL

Domain Verification

The first step is to verify ownership of your domain by adding a DNS TXT record. Access your domain's DNS settings or management interface where you'll need to add a TXT record. The record has the format chariot=<verification-id>, where <verification-id> is your account's verification ID. The Add SSO Provider dialog on Settings → Organization shows the exact value to copy.

Add the TXT record at the root of your domain. For example, for YourDomain.com, add it at the root level (@) with the value from the Add SSO Provider dialog.

Once set, your DNS TXT record might look something like this:

To verify that your record has been published, you can run the command dig +short TXT YourDomain.com if on a Mac or nslookup -type=TXT YourDomain.com if using Windows, and look for your record in the output.

Creating and Configuring the Okta Application

Begin by logging into your Okta admin dashboard at login.okta.com. Navigate to the Applications section and create a new app integration. When configuring the application, select "OIDC - OpenID Connect" as your sign-in method and "Web Application" as your application type.

Click Next at the bottom.

Name your application "PGP" and configure the redirect URIs. The sign-in redirect URI should be set to https://sso.guard.praetorian.com/oauth2/idpresponse, and the sign-out redirect URI should be https://guard.praetorian.com/login. Remember to configure access for any users who will need to access PGP via SSO - this can be done under Assignments.

Optional Okta Tile Configuration

To let users open PGP from an Okta tile:

1. Under General > General Settings, click Edit.
2. Under General > Login, set:
   • Login initiated by: Either Okta or App.
   • Application visibility: enable “Display application icon to users”.
   • Login flow: “Redirect to app to initiate login (OIDC Compliant)”.
   • Initiate login URI: https://guard.praetorian.com/sso/{YOUR_DOMAIN}, replacing {YOUR_DOMAIN} with your SSO domain, for example https://guard.praetorian.com/sso/example.com.
3. Click Save.

Integrating with PGP

1. Sign in to PGP at https://guard.praetorian.com/login with your existing credentials.
2. Go to Settings → Organization.
3. In the Single Sign-On section, click Add Provider. If a provider already exists, click Add Another Provider.
4. In Add SSO Provider, fill in:
   • Domain: your email domain, for example acme.com.
   • Client ID and Secret: from the Client Credentials section of your Okta application.
   • Issuer URL: your Okta base URL, for example https://yourorg.okta.com.
   • Default Role for SSO Users and Role Claim Name (Optional): see User Provisioning and Role Assignment.
5. Click Integrate.

Your users can now sign in to PGP with Okta.

User Provisioning and Role Assignment

Once SSO is configured, all users are managed through your Okta instance. New users do not need to be provisioned in PGP ahead of time — an account is created automatically the first time an Okta user signs in.

During SSO setup, choose how roles are assigned. If the Add SSO Provider dialog shows no role fields, every SSO user is given the Admin role.

• Default role — Every SSO user is granted the same role on first sign-in. After sign-in, the role for an individual user can be adjusted under Settings > User Management. We recommend setting the Default Role to Read Only so that any user whose role claim is missing or invalid lands in the least-privileged state.
• Role claim — Map an Okta role claim to PGP's three roles: Read Only, Analyst, and Admin. When a user is provisioned in Okta with one of those roles, they inherit the corresponding role in PGP on sign-in.

When configuring a role claim, the following details apply:

• Token type — PGP enforces RBAC from the ID token only. In Okta, the claim must be added with Include in token type: ID Token. Access-token claims are not inspected.
• Claim name — You may pick any claim name you like (for example, app_role). Enter the same name as the Role Claim Name in PGP.
• Claim format — The value must be a single string. Array-valued claims are silently ignored, even if the array contains an otherwise valid value.
• Accepted values — Exactly admin, analyst, or readonly (lowercase, case-sensitive). Any other value is logged as invalid and falls back to the Default Role.
• Mapping location — Role mapping is configured only in Okta (with a custom claim, group-membership expression, or similar). PGP has only the Role Claim Name and Default Role for SSO Users fields, with no separate role-mapping screen.

For detailed step-by-step examples (including a group-membership expression and a per-user profile attribute), see Role-Based Access Controls (RBAC).

Post-Setup Information

Once the setup is complete, users sign in with Sign in with SSO on the PGP login page.

You can remove the DNS TXT record after setup, but add it back before you change the SSO configuration, for example with Rotate Credentials on the provider.

If you need help, contact support@praetorian.com.