OKTA - Single Sign-on (SSO)
This guide outlines the technical requirements for integrating OKTA as an Identity Provider (IdP) for Xima Software applications. This integration enables secure, centralized user management and Single Sign-On (SSO) capabilities
Prerequisites
Before beginning the integration, please ensure the following requirements are met:
- Administrative Access: The customer must have administrative privileges within their own OKTA tenant.
- Customer-Managed Solution: The customer is responsible for the internal configuration and maintenance of their OKTA environment. Xima Software personnel cannot access or manage the customer's OKTA instance.
- Protocol Selection: The organization must determine which authentication protocol (SAML 2.0 or OIDC) aligns with their internal security policies.
Authentication Options
Administrators may choose between two primary authentication protocols: SAML 2.0 or OIDC/OAuth.
Option 1: SAML 2.0 (Enterprise Standard)
SAML 2.0 is the recommended protocol for strict corporate environments and systems requiring XML-based assertions.
| Item Name | Provided By | Description |
|---|---|---|
| ACS URL | Xima Software | The Assertion Consumer Service URL; the endpoint where Xima receives the XML POST from OKTA. |
| SP Entity ID | Xima Software | The unique identifier for the application (often the base URL or ACS URL). |
| NameID Format | Xima Software | The expected username format (standardized as EmailAddress). |
| IdP SSO URL | Customer | The specific OKTA URL where the application redirects users for login. |
| IdP Issuer ID | Customer | The unique entity ID for the organization's OKTA instance. |
| X.509 Certificate | Customer | The public key certificate used to verify that the XML response is authentic. |
Pro Tip: Configuration efficiency can be improved by generating a Metadata XML file from the Xima application and importing it directly into OKTA to auto-populate these fields.
Option 2: OIDC / OAuth (Modern Standard)
OpenID Connect (OIDC) is the modern standard, ideal for web-based applications and mobile platforms.
| Item Name | Provided By | Description |
|---|---|---|
| Redirect URI | Xima Software | The exact URL where OKTA sends the user after a successful authentication. |
| Logout Redirect URI | Xima Software | (Optional) The destination for the user after logging out. |
| Client ID | Customer | The public identifier for the application within the OKTA system. |
| Client Secret | Customer | A private security key. This must be treated as a sensitive credential. |
| Issuer URL | Customer | The base URL for the OIDC authorization server (e.g., https://company.okta.com). |
Pro Tip: Once the Issuer URL is established, additional configuration details (endpoints, scopes, and keys) can be located by appending
/.well-known/openid-configurationto the URL.
Integration Workflow
The following steps must be completed in order to establish a secure connection between Xima Software and OKTA.
SAML 2.0 Integration Sequence
- Provisioning (Xima): Xima Software provides the Service Provider (SP) Metadata (ACS URL and Entity ID) to the Customer.
- App Creation (Customer): The Customer creates a new SAML 2.0 App Integration within their OKTA Admin Console using Xima’s metadata.
- Handshake (Customer): The Customer exports the Identity Provider (IdP) Metadata (or the SSO URL, Issuer ID, and X.509 Certificate) and sends it to Xima Software.
- Finalization (Xima): Xima Software uploads the Customer’s IdP metadata into the application backend to complete the link.
- Validation (Joint): Both parties verify a successful login via a test user account.
OIDC / OAuth Integration Sequence
- Provisioning (Xima): Xima Software provides the Login Redirect URI to the Customer.
- App Creation (Customer): The Customer creates an OIDC - Web Application integration in their OKTA Admin Console.
- Handshake (Customer): The Customer copies the Client ID, Client Secret, and Issuer URL and securely provides them to Xima Software.
- Finalization (Xima): Xima Software configures the OIDC client settings in the application environment using the Customer’s credentials.
- Validation (Joint): Both parties verify that the application correctly redirects to OKTA and returns a valid token.
Updated 2 days ago