OKTA

This article provides a step-by-step process for configuring Single Sign-On (SSO) with Okta for the OvalEdge platform.

OvalEdge is a data catalog that builds a comprehensive catalog of all organizational data sources. It is a web-based application that provides role-based access to users.

OvalEdge supports multiple authentication mechanisms, including:

• Username and Password

• Okta

• Active Directory

Okta

Okta is a cloud-based identity management service that also integrates with on-premises applications. It allows organizations to centrally control employee access to applications and devices.

Key Features of Okta

• User provisioning

• Single Sign-On (SSO)

• Integration with Active Directory (AD) and LDAP

• Centralized user de-provisioning

• Multi-Factor Authentication (MFA)

• Mobile identity management

• Flexible security policies

OvalEdge uses the SAML 2.0 protocol with Okta for single sign-on. Okta can be configured for authentication only or for both authentication and authorization in OvalEdge.

SAML 2.0

Security Assertion Markup Language (SAML) is an open standard that allows identity providers (IdPs) to send login credentials securely to service providers (SPs). With SAML, users can log in to multiple applications using a single set of credentials.

Key Terminologies

• Assertion: XML passed between the service provider and the identity provider.

• Assertion Consumer Service (ACS): The target resource within the SP where the IdP sends the SAML response.

• Attribute: Unique information about a user passed within an assertion.

• Identity Provider (IdP): A trusted entity that provides authentication services to the SP.

• Issuer: A unique string that must match between IdP and SP.

• SAML Request: An assertion sent from the SP to the IdP to request authentication.

• SAML Response: An assertion sent from the IdP to the SP confirming authentication.

• Service Provider (SP): The application or service the user wants to access.

Authentication Flow

• The user attempts to access the service provider (OvalEdge).

• The SP checks if the user is already authenticated.

  • If yes → grants access.

  • If no → redirects to the IdP for authentication.

• The user’s browser sends an authentication request to the IdP (Okta).

• The IdP authenticates the user and returns a SAML Response to the SP.

• The SP validates the response, logs the user in, and provides access to requested resources.

Configure Okta SSO

Create the Okta Application

• Log in to Okta Admin Console.

• Navigate to Applications > Create a New App Integration.

• Select SAML 2.0 and click Next.

  
• Enter the following:

  • App Name: OvalEdge

    
  • Logo: Optional, downloadable from www.ovaledge.com.

Configuring SAML Settings

• Single Sign-On URL https://<load-balancer-domain>/<context>/saml/SSO (must be SSL-enabled)

• Recipient URL / Destination URL https://<load-balancer-domain>/

• Audience URI (SP Entity ID) If your application URL includes a context or port number, make sure to include them. Otherwise, just use the base application URL followed by {context}/saml/metadata . https://<load-balancer-domain>/<context>/saml/metadata

Attribute Mapping

Map the following attributes in Okta → OvalEdge:

• userId

• firstName

• lastName

• email

Also, map roles based on Okta GroupName values to OvalEdge Managed Roles.

📌 Configure the prefix in OvalEdge configuration as: saml.role.prefix=<PrefixValue>

When prompted, select “I’m an Okta customer adding an internal app” and click Finish.

Group Management in Okta

• Navigate to Groups > Add Group.

• Enter a Group Name and Description.

  
• The groups that were created are displayed below.

  

Apply a Prefix before the group name (required).

⚠️ If a user is not assigned to any group, they will default to the OE_PUBLIC role.

Role Management

The most preferred way of role management is to manage users and roles in OKTA. In the OE Application, create the following: Manage roles by mapping to OKTA Groups.

Okta.OvalEdge.CSM	CSM
Okta.OvalEdge.OE_ADMIN	OE_ADMIN
Okta.OvalEdge.OE_PUBLIC	OE_PUBLIC
Okta.OvalEdge.OE_STEWARD	OE_STEWARD
Okta.OvalEdge.OE_OWNER	OE_OWNER

• Only the suffix is created in OvalEdge.

• Permissions are managed in OvalEdge, while role/user mapping is controlled in Okta.

• Custom naming conventions can be used but must match the configuration in OvalEdge.

Adding Users in Okta

• Add a new user by providing profile details.

  
• Assign roles by adding the user to appropriate Okta groups.

  
• Application usernames can be modified using the edit icon.

  

Configuring OvalEdge

• Capture the Identity Provider metadata URL from the OKTA portal,

  
• Click on View IdP Metadata, and the XML file is displayed.

• Copy the URL from the browser and mention it in the samlHTTPMetadataProvider:

• In oasis.properties, configure the following:

samlHTTPMetadataProvider=<IdP Metadata URL>
entityBaseURL=https://<domain>

• Save changes and restart the OvalEdge application.

  

Testing Roles

Testing the Roles with REMOTE and HYBRID SAML Type.

• With Hybrid, the Users would get the role from the OvalEdge Application.

• With Remote, the Users would get the role from OKTA.

For the first time, Users logged in with the Admin Role can go to Configuration and specify the Job Parameter.

OvalEdge SAML Type as HYBRID

• In the OvalEdge Configuration page, update the reload of the configurations.

  
• Note: If the New User logs in with the domain, they will get the initial role as OE_PUBLIC, as the roles are coming in through the application.

For REMOTE SAML Type

• Change the OvalEdge SAML Type to REMOTE from HYBRID in the “Configuration” through Admin User and Click on “Reload the Configuration”.

  
• Admin users can customize the Roles using the Administration > Users and Roles > Roles.

  
• After adding the roles, it would appear for logged-in users in Users and Roles Management, as shown below:

  
• Okta is successfully integrated with OvalEdge using SAML 2.0-based SSO.

---

Copyright © 2025, OvalEdge LLC, Peachtree Corners, GA, USA.