Skip to content
  • There are no suggestions because the search field is empty.

Okta for Single Sign On (SSO)

If your organization uses Okta for identity management, you can integrate it so that users log in to AlisQI via their Okta credentials (no separate AlisQI passwords). This article provides a step-by-step configuration guide.

Single sign-on (SSO) is an authentication method that allows users to log in with one set of credentials (in this case via Okta) and access multiple applications (including AlisQI) seamlessly.

In this setup, Okta acts as the Identity Provider (IdP) and AlisQI is the Service Provider (SP). We use SAML 2.0 as the protocol.

Before enabling SSO, all users in AlisQI must have valid email addresses that exactly match their Okta user profiles. Once SSO is enabled, local username/password logins are disabled.

 

 

Introduction

We support SSO based on SAML 2.0. If your organization uses Okta for identity management, you can integrate it so that users log in to AlisQI via their Okta credentials (no separate AlisQI passwords).

SSO improves security (centralized access control) and usability (users don’t need to remember another password).

Terminology

  • Identity Provider (IdP): The identity system (Okta) that authenticates a user.

  • Service Provider (SP): The application (AlisQI) that consumes the authentication assertion.

  • Assertion / SAML Response: The document Okta sends to AlisQI confirming a login.

  • Metadata: An XML file or endpoint that describes endpoints, certificates, entity IDs etc.

Prerequisites

  • An administrator account in your Okta tenant with permissions to create and manage SAML applications.

  • Matching email addresses between Okta user profiles and AlisQI user accounts.

  • A secure certificate for signing SAML assertions (Okta generates this by default).

  • If you have multiple Okta environments (test, prod), ensure consistency of configuration.

Download AlisQI (SP) Metadata

In your AlisQI application settings, click the “Download SP Metadata” button. This provides you with an XML file (e.g. alisqi-sp-metadata.xml).

Keep this file handy — you will upload it into Okta.

Configure Okta

Create a new Okta application (SAML)

  1. Log in to your Okta Admin Console.

  2. Navigate to Applications → Applications.

  3. Click Create App Integration (or “Add Application”).

  4. For Platform, choose Web.

  5. For Sign-on method, select SAML 2.0.

  6. Click Next.

Configure the SAML settings

You will be presented with a form to configure SAML details.

Okta Setting Value / Note
Single sign on URL / ACS (Assertion Consumer Service) URL This value comes from the AlisQI metadata (from the downloaded file).
Audience URI / SP Entity ID Also from the AlisQI metadata.
Default RelayState Leave blank.
Name ID format EmailAddress 
Application username Okta user.email (or the Okta attribute storing the user’s email)
Signature / Signing algorithm Typically SHA-256 (Okta default)
Response / Assertion signing Both “Signed Assertion” (and “Signed Response” if required)
Assertion encryption Off
Okta will provide you with IdP metadata url. You’ll need to send that to AlisQI.

 

Assign users or groups in Okta

  1. In the application you just created, go to the Assignments tab.

  2. Assign either individual users or groups that should have access to AlisQI.

  3. Ensure that all intended AlisQI users are assigned.

Send Okta metadata to AlisQI

From within Okta:

  • Locate the Identity Provider metadata (either under Sign OnIdentity Provider metadata or by downloading the IdP metadata XML).

  • Copy the metadata URL.

  • Send that metadata url to AlisQI support. They will configure the AlisQI SSO and use that metadata to configure the SP → IdP trust.

Troubleshooting

Testing

  1. Try to access AlisQI via its usual login page. It should redirect you to Okta for authentication.

  2. Log in with a user assigned to the Okta application.

  3. After successful login, you should be redirected back into AlisQI, logged in.

  4. Attempt with a user not assigned in Okta — they should be denied access.

Common issues & fixes

Issue Possible cause Solution
“No match on NameID / Subject in assertion” The NameID in SAML assertion does not match the user’s email in AlisQI Ensure Okta user.email or correct attribute is set as NameID
“Invalid signature” Certificate mismatch between Okta and AlisQI Ensure Okta’s signing certificate is the one referenced in the metadata AlisQI uses
Users can’t log in User in Okta not assigned to the app Assign the user or group
Mismatched emails The email in Okta differs from the email in AlisQI Fix email values on either side to match exactly