Breadcrumbs

Okta Configuration

Workflow Overview

  • This workflow describes how to configure Single Sign-On (SSO) using Okta as the Identity Provider in the EpicLink portal. The process involves a two-system setup. The configuration is completed by exchanging required values between the two systems in a structured sequence.

    • EpicLink (Service Provider / SP) – where SSO is enabled

    • Okta (Identity Provider / IdP) – where authentication is configured

  • Start SSO configuration in EpicLink by selecting Okta as the Identity Provider.

  • Copy the SP Entity ID and ACS URL from the SSO Settings screen. This will be used in the Okta Console Configuration.

  • Configure a SAML application in Okta using the copied SP details.

  • Complete the Okta setup and obtain IdP SSO URL, Entity ID, and Certificate.

  • Return to EpicLink and enter the retrieved IdP details.

  • Save and verify the configuration to enable SSO authentication.

The following sections provide a detailed, step-by-step explanation of how to configure SSO using Okta (SAML 2.0).

Step 1: Start in EpicLink - SSO Settings screen

  • Navigate to Account Management → SSO Settings in EpicLink.

  • In the SSO Configuration section, select Okta as the Identity Provider.

  • The default Protocol is SAML.

  • Note the following values under Service Provider Details. These values will be used in the Okta Configuration.

    • SP Entity ID

    • ACS URL

image-20260529-084436.png

  • The next three fields are the IdP Configuration Fields.

    • IdP SSO URL

    • IdP Entity ID

    • IdP Certificate

  • To enter the values for these fields, go to your Okta Admin Console, open your SAML application, and navigate to the Sign On tab.

  • Follow the below section to get these values or follow the Okta SAML setup guide for detailed instructions.

Step 2: Configure Okta

  • Log in to the Okta Admin Console.

  • Navigate to:

    • Applications → Applications from the left menu bar.

image-20260527-133017.png

  • Click the Create App Integration button. The Create a new app integration dialog box opens.

  • Select SAML 2.0 option.

image-20260527-133920.png

  • Click Next.

  • Configure the General Settings. Enter the App Name.

image-20260527-133628.png

  • Upload an App logo. This field is optional.

  • Select the App Visibility checkbox as per your need.

  • Click Next.

  • The Configure SAML section opens.

image-20260527-134244.png

  • Enter the ACS URL copied from EpicLink into the Single Sign-On URL field.

  • Enter the SP Entity ID copied from EpicLink into the Audience URI (SP Entity ID) field.

  • In the Name ID Format field, enter your Email Address.

  • Click Next.

  • The Feedback section opens. Complete the app configuration and click Finish.

image-20260527-143556.png

Step 3: Retrieve IdP Details from Okta

  • After completing the Okta setup, collect the following values from the Okta application.

  • Copy the Sign On URL value.

  • Copy the Issuer value.

  • Download the Signing Certificate.

    • Open in a text editor

    • Copy only the content between:

      • -----BEGIN CERTIFICATE-----

      • -----END CERTIFICATE-----

  • The information from this page has to be pasted on the SSO Settings tab in Account Management screen to complete the configuration.

image-20260527-144010.png

  • Return to the SSO Settings screen in EpicLink.

  • The values obtained from Okta configuration page has to be pasted on the SSO Settings tab in Account Management screen as mapped in the table below to complete the configuration:

Values from Okta Console

SSO Settings tab in EpicLink

  • Sign On URL

IdP SSO URL

  • Issuer

IdP Entity ID

  • Signing Certificate

IdP Certificate
image-20260527-145648.png

  • Click the Save button.

  • SSO setup is now complete. SSO authentication via Okta is enabled.

Group Role Mapping

  • The Group Role Mapping section is used to map roles defined in your Identity Provider (Okta) to access policies within the EpicLink Portal. This allows administrators to centrally manage user permissions through their Identity Provider instead of assigning permissions manually in the portal.

  • When a user signs in through SSO, the EpicLink Portal checks the user's assigned role in the Identity Provider and automatically grants the corresponding EpicLink portal permissions.

image-20260529-151921.png

For example:

Identity Provider Role in Okta

EpicLink Portal Access

Read

Read Access

Support Read

Read Access

Admin

Admin Access

Starlink Admin

Starlink Admin Access

  • This ensures that users receive the correct permissions immediately after login without requiring manual role assignment in the EpicLink Portal.

Adding a Role Mapping

  1. Click + Add Group Mapping.

  2. Select the role configured in your Identity Provider.

  3. Select the corresponding EpicLink Portal access policy.

  4. Save the mapping.

After the mapping is created, any user belonging to that Identity Provider group automatically receives the mapped EpicLink Portal permissions when they authenticate through SSO.

When should you configure this?

Configure Group Role Mapping when:

  • Different teams require different access levels.

  • User permissions are managed through Okta groups.

  • You want user access to be automatically controlled by the Identity Provider.

  • You want to eliminate manual permission management in the EpicLink Portal.

Example:
An organization has separate Okta groups for Network Administrators and Support Engineers. Administrators can be mapped to Admin Access, while Support Engineers can be mapped to Support Read Access. When users are added or removed from these Okta groups, their EpicLink Portal permissions automatically update during SSO login.

Default Policy

  • The Default Policy determines what access level is assigned to SSO users who successfully authenticate but do not have any matching Group Role Mapping configured.

image-20260529-151942.png

  • When a user signs in through SSO:

    • The system checks whether the user belongs to a mapped Identity Provider role.

    • If a matching role mapping exists, the mapped EpicLink Portal access policy is applied.

    • If no matching role mapping exists, the system applies the selected Default Policy.

  • Enable the Deny access if no group rule matches checkbox, if you want users without a mapped role to be blocked from accessing the EpicLink portal.

    • When Deny access if no group rule matches checkbox is enabled:

      • Only users with a valid Group Role Mapping can log in.

      • Users without a matching role are denied access.

    • When Deny access if no group rule matches checkbox is disabled:

      • Users without a matching role receive the permissions defined in the Default Policy.

When should you configure Default Policy?

  • Use a Default Policy when:

    • All authenticated users should receive at least basic access.

    • New users should automatically receive limited permissions until role mappings are configured.

    • You want to simplify onboarding.

Example:
Set the Default Policy to Read Access so newly onboarded users can view information immediately, even if their Okta role mapping has not yet been configured.

When should you configure Deny access checkbox?

  • Security requirements demand explicit role assignment.

  • Only approved users should access the platform.

  • You want strict access control.

Example:
A managed service provider allows access only to users assigned to specific Okta groups. Any user without a mapped role is denied access.

Inactive Account Deletion (days)

  • The Inactive Account Deletion (days) setting controls how long an SSO user account can remain inactive before it is automatically disabled within the EpicLink Portal.

image-20260529-152815.png

  • Specify the number of inactivity days.

  • If an SSO user does not log in during that period, the EpicLink Portal automatically disables the account.

  • The user remains in the Identity Provider (Okta) and is not removed from the Identity Provider.

  • An administrator can later re-enable the account if required.

Note: This setting only affects the EpicLink Portal account. It does not delete or disable the user in Okta.

When should you configure this?

Configure this setting to:

  • Reduce security risks from dormant accounts.

  • Automatically disable unused accounts.

  • Maintain compliance with internal security policies.

  • Keep user records clean and manageable.

Example:
If the value is set to 30 days, a user who does not log in for 30 consecutive days is automatically disabled in the EpicLink Portal. An administrator can later re-enable the account if access is required again.

Allow Sub-Organizations to Use this SSO

  • The Allow Sub-Organizations to Use this SSO option extends the configured SSO integration to child organizations beneath the current organization.

image-20260529-153042.png

  • By default, the SSO configuration is available only to the organization where it is configured.

  • When this option is enabled:

    • Users from subordinate organizations can also authenticate using the same SSO configuration.

    • Child organizations inherit the configured Identity Provider settings.

    • A single SSO configuration can be shared across an organizational hierarchy.

When should you configure this?

Enable this option when:

  • Multiple business units share a single Okta tenant.

  • Parent organizations centrally manage authentication.

  • You want a single SSO configuration across all subsidiaries or departments.

  • You want to avoid maintaining separate SSO configurations for each child organization.

Leave this option disabled when:

  • Each sub-organization manages its own Identity Provider.

  • Different child organizations require separate authentication configurations.

  • Access needs to be isolated between organizations.

Example:

Consider the following hierarchy:

  • ABC (Parent Organization)

    • A1 Mobility India

    • A2 Mobility US

    • A3 Mobility Europe

If SSO is configured at ABC organization:

  • Enabled: Users from A1 Mobility India, A2 Mobility US, and A3 Mobility Europe can also authenticate using the same SSO setup.

  • Disabled: Only users belonging to ABC organization can use the SSO configuration.

Limitations

  • Orbit-Only Support

    • Single Sign-On (SSO) authentication is currently supported only for Orbit Services - Orbit Browser and Orbit Mobile App.

    • SSO integration for Konnect is not currently available and is planned for a future release.

  • Organization-Wide Role Assignment

    • SSO role mappings are applied at the organization level and are inherited by all child organizations (sub-organizations).

    • For example, a user assigned an Admin role through SSO for an organization will automatically receive Admin access to that organization and all of its sub-organizations.

    • Assigning SSO permissions that are restricted to specific sites or individual sub-organizations is not supported.

    • Granular access control based on site-level or sub-organization-level restrictions cannot be enforced through SSO role mappings.