Okta SAML Integration Guide

Suggest an edit

Prerequisites

  • Administrator access to the Okta Admin Console
  • A SplitSecure Identity Provider created and approved
  • A separate browser or browser profile with SplitSecure configured (for testing)

There are many ways to configure Okta as a service provider with SplitSecure, but we have found the approach below to work particularly well. This guide walks through our recommended configuration: you will create a dedicated admin user in a non-existent domain (e.g., @splitsecure.mycompany.com), configure an external SAML Identity Provider that only authenticates users in that domain, and set up automatic account linking — all without JIT provisioning.

Okta User Setup#

Create a dedicated Okta user that will authenticate exclusively through SplitSecure. By placing this user under a non-existent domain (e.g., splitsecure.mycompany.com), you ensure they can never authenticate with an Okta password — all authentication is handled by SplitSecure’s authorization and vote process.

1 Create a Dedicated SplitSecure Admin User#

  1. Sign in to the Okta Admin Console
  2. Go to Directory → People
  3. Click Add Person
  4. Fill in the following:
Field Value Notes
First name SplitSecure
Last name Admin
Username [email protected] Use a non-existent domain dedicated to SplitSecure
Primary email [email protected] Same as username
I will set password Do not check Leave unchecked — no password is needed
  1. Click Save

2 Grant Administrator Privileges#

  1. In the Okta Admin Console, go to Security → Administrators
  2. Click Add Administrator
  3. In the Grant administrator role to field, search for [email protected] and select the user
  4. Select Super Administrator (or your preferred admin role)
  5. Click Save

Identity Provider Configuration#

1 Create a New Identity Provider#

  1. Go to Security → Identity Providers
  2. Click Add Identity Provider
  3. Select SAML 2.0 IdP and click Next
  4. Enter a descriptive name (e.g., “SplitSecure”)

2 Configure General Settings#

Authentication Settings#

Field Value Notes
IdP Usage SSO only
Claims Yes Honors AMR (Authentication Methods References) claims from SplitSecure
Account matching with Persistent Name ID Yes

Account Matching#

Field Value Notes
IdP username idpuser.subjectNameId
Filter ^[^@]+@splitsecure\.mycompany\.com$ Only allows users in the @splitsecure.mycompany.com domain
Match against Okta Username or Email
Account link policy Yes Automatically links IdP assertions to matching Okta accounts
Auto-link filters None
If no match is found Redirect to Okta sign-in page JIT provisioning is disabled — users must be pre-created in Okta

SAML Protocol Settings#

Field Value Notes
IdP Issuer URI Copy from SplitSecure IdP Details → “SAML IdP Entity ID” Found in SplitSecure: External Services → SAML2 Identity Providers → [Your IdP] → Details
IdP Single Sign-On URL https://companion.aws.splitsecure.com/saml2/sp/login
IdP Signature Certificate (Upload certificate file) Download from SplitSecure: External Services → SAML2 Identity Providers → [Your IdP] → Details → Download Certificate
Request Binding HTTP REDIRECT
Application context No
Request Signature Yes
Response Signature Verification Assertion
Response Signature Algorithm SHA-256
Okta Assertion Consumer Service URL Trust-specific
Max Clock Skew 2 Minutes
  1. Click Finish

3 Configure Routing Rule#

Create a routing rule so Okta redirects users in the @splitsecure.mycompany.com domain to SplitSecure for authentication.

  1. Go to Security → Identity Providers → Routing Rules
  2. Click Add Routing Rule
  3. Configure the rule:
Field Value Notes
Rule name SplitSecure Authentication
User’s IP is Anywhere Restrict to specific IP ranges if desired
User is accessing Any application
User matches Regex on login
Filter ^[^@]+@splitsecure\.mycompany\.com$ Same regex as the IdP filter — match your chosen domain
Use this identity provider SplitSecure (the IdP you created above)
  1. Click Create Rule
  2. Click Activate when prompted

Authentication Policy#

Add an authentication rule to the existing Okta Admin Console policy that requires two factor types with hardware-protected credentials. This rule is scoped to your SplitSecure admin user (or group) so it does not affect other Okta users.

1 Create a Group for SplitSecure Admins (Optional)#

If you plan to create multiple SplitSecure admin users with different permission sets, create a group to manage them collectively.

  1. Go to Directory → Groups
  2. Click Add Group
  3. Enter a name (e.g., “SplitSecure Admins”) and a description
  4. Click Save
  5. Click on the newly created group, then click Assign people
  6. Search for [email protected], click + to add, then click Save

2 Add a Rule to the Okta Admin Console Policy#

  1. Go to Security → Authentication Policies
  2. Click on the Okta Admin Console policy
  3. Click Add Rule
  4. Enter a rule name (e.g., “SplitSecure MFA”)
  5. Configure the rule:

IF conditions#

Field Value Notes
User’s type is Any user type
User’s group membership includes SplitSecure Admins (if you created the group in Step 1) Or select Any group and pick the specific user below
User is The specific SplitSecure admin user (if no group) Only needed if you did not create a group

THEN access and authentication#

Field Value Notes
User must authenticate with Any 2 factor types Requires two distinct authentication factors
Possession factor constraints
— Phishing resistant Unchecked Leave unchecked — enabling this triggers Okta Verify enrollment
— Hardware protected Checked Satisfied by SplitSecure’s hwk AMR claim
— Require user interaction CheckedAny interaction Satisfied by SplitSecure’s user AMR claim
Authentication methods Allow any method that can be used to meet the requirement
  1. Click Save

SplitSecure’s authorization and vote process sends the following AMR (Authentication Methods References) claims in the SAML assertion, which Okta honors because Claims is set to Yes in the Identity Provider configuration:

AMR Claim Meaning
mfa Multi-factor authentication
user User interaction occurred
hwk Hardware key was used
mca Multi-channel authentication

SplitSecure Configuration#

1 Download Okta SAML Metadata#

  1. In the Okta Admin Console, navigate to Security → Identity Providers
  2. Locate your IdP and click Actions → Configure Identity Provider
  3. In the Summary card, click Download metadata and save the XML file

2 Create the Okta External Service#

  1. In SplitSecure, navigate to External Services → New External Service → Okta
  2. Enter a name for your service
  3. Select the IdP you configured Okta with during the Identity Provider configuration step
  4. Upload the metadata file downloaded in Step 1
  5. Click Create

Test Authentication#

1 Test Authentication (IdP-Initiated)#

  1. In SplitSecure, navigate to External Services
  2. Locate your Okta service and click Authenticate
  3. Enter [email protected] and click Request Access
  4. Complete the SplitSecure authorization and vote process
  5. After approval, you should be logged in to Okta as the SplitSecure Admin user

2 Test Authentication (SP-Initiated)#

  1. Open the Okta sign-in page for your organization
  2. Enter [email protected] as the username
  3. The routing rule should redirect you to SplitSecure (no password prompt)
  4. Complete the SplitSecure authorization and vote process
  5. After approval, you should be redirected back to Okta and logged in

Troubleshooting#

Issue Possible Cause Solution
Authentication fails immediately Mismatched IdP Issuer URI Verify the Entity ID matches exactly between Okta and SplitSecure
Certificate errors Expired or incorrect certificate Re-download the certificate from SplitSecure and re-upload to Okta
User not redirected to SplitSecure Routing rule not active or misconfigured Verify the routing rule is active and the regex matches the user’s email
“User not found” after IdP response User not pre-created in Okta Create the user first — JIT is disabled, users must exist before authentication
User not linked after authentication Account link policy not set to Yes In the IdP settings, verify Account link policy is set to Yes
Password prompt appears Routing rule not matching Ensure the routing rule regex matches the user’s login
AMR claims not honored Claims set to No In the IdP Authentication Settings, set Claims to Yes
Okta Verify enrollment prompted Phishing resistant checked Uncheck “Phishing resistant” in the authentication policy rule
Clock skew errors Time synchronization issues Increase the Max Clock Skew value or sync server clocks

External Resources#