AcademyCustomer Portal

OKTA

This article outlines the configuration steps for setting up OKTA Single Sign-On integration with OvalEdge using the SAML 2.0 authentication protocol. It includes supporting details about OvalEdge, OKTA, SAML 2.0 components, authentication flow, configuration steps, and validation instructions.

Purpose

The purpose of this article is to provide clear information about the configuration, mapping, connection, and validation steps required to set up OKTA SSO for OvalEdge using SAML 2.0.

Prerequisites and Dependencies

  • Access to the OKTA administrator console

  • Access to OvalEdge administrator configuration

  • SSL-enabled application URL

  • Load balancer DNS or domain URL

  • SAML 2.0 supported authentication

  • Ability to modify the oasis.properties file

  • IdP metadata URL from OKTA

Environment Details

Component
Details

Application

OvalEdge

Identity Provider

OKTA

Authentication Protocol

SAML 2.0

Configuration File

oasis.properties

Required Parameters

samlHTTPMetadataProvider, entityBaseURL

Introduction to OvalEdge, Okta, and SAML 2.0

OvalEdge

OvalEdge is a web-based application that provides a centralized catalog of an organization’s data sources and enforces role-based access controls. It supports Username and Password, OKTA, and Active Directory for authentication.

OKTA

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

Key features of Okta include:

  • 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. Use Okta for authentication only or for both authentication and authorization in the OvalEdge application.

SAML 2.0

Security Assertion Markup Language (SAML) is an open standard that lets Identity Providers (IdPs) send login credentials to service providers (SPs). It allows users to log in to multiple websites using a single set of credentials.

SAML 2.0 Terminologies

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

  • Assertion Consumer Services (ACS): The target resource within the SP to which the IdP sends the SAML 2.0 response assertion.

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

  • Identity Provider (IdP): A trusted entity providing authentication services to the SP on behalf of the user principal.

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

  • SAML 2.0 Request: An assertion that the SP passes to the IdP to request that a user be authenticated.

  • SAML 2.0 Response: An assertion that the IdP passes to the SP for an authenticated user.

  • Service Provider: The web application that the user wants to access.

SAML 2.0 Authentication

  • In the first step of SAML 2.0 Authentication, the user tries to access the application/ web service (Service Provider). The service provider verifies if the user is already authenticated within the system.

  • If the user is already authenticated, content can be made available directly to the user. Otherwise, the service provider starts the authentication process if the user is not authenticated.

  • The service provider determines the identity provider and redirects user requests to that provider, i.e., single sign-on service.

  • In the third step of SAML 2.0 authentication, the user's browser sends an authentication request to the SSO service.

  • The SSO service returns a request that includes the authentication information the service provider needs in a SAML 2.0 Response parameter.

  • The SAML 2.0 Response parameter is passed on to the service provider.

  • The service provider processes this response, allows the user to log in, and informs the user where the requested resource is.

  • Users can now request the resources they want.

  • The resource is finally returned.

Configure Okta SSO

Create the Okta Application

The OvalEdge needs to be configured for OKTA integration using SAML 2.0 authentication.

  1. Log in to OKTA. In Applications, click on Create a New App Integration.

  2. Select SAML 2.0 from the list of available options and click on the Next button.

  1. Give the App name as OvalEdge and upload the OvalEdge logo, which is optional.

The OvalEdge log can be downloaded from the website www.ovaledge.com.

  1. Now, configure the SAML Settings.

  1. Single Sign-on URL: This should be the application URL of the load balancer, followed by {context}/saml/SSO Example: https://xxx.xxxxxx.xxxx/{context}/saml/SSO

It must be SSL-enabled.

  1. Receipt URL and Destination URL: This should be the Load Balancer DNS or Domain URL with HTTPS Example: https://xxxxx.xxxxxx.xxxx/

  2. Audience URI (SP Entity ID): If the 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. Example: https://xxxxx.xxxxx.xxxx/{context}/saml/metadata

Mapping of OKTA fields to OvalEdge

  1. Use the following name and value to map the attributes shown in the screenshot below.

    1. userId

    2. firstName

    3. lastName

    4. email

  1. Also, map the roles that will match against the OKTA GroupName values and OvalEdge Manage Roles.

  1. This Prefix must be configured in the OvalEdge Configuration as saml.role.prefix value.

  1. Under "Are you a customer or a partner?", select "I’m an Okta customer adding an internal app", then click the Finish button to complete the configuration.

  1. To maintain group management in the OKTA, click on Add Group and enter Name and Group Description.

  1. The groups that were created are displayed below.

  • A Prefix must be added before the group name when adding Groups in OKTA.

  • If the user is not assigned to any of the groups, then the user will get the OE_PUBLIC role by default.

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.

For Example, the Manage roles in the OKTA group and OvalEdge application are given below:

OKTA GROUP
OvalEdge Application

Okta.OvalEdge.xxx

xxx

Okta.OvalEdge.OE_ADMIN

OE_ADMIN

Okta.OvalEdge.OE_PUBLIC

OE_PUBLIC

Okta.OvalEdge.OE_xxxxx

OE_xxxxx

The only suffix will be created in the OvalEdge application.

The permissions for these roles will be managed in OvalEdge. However, user/ role management will be done in OKTA. Use a naming convention, but it must be configured in OvalEdge.

Adding people to the OKTA

  1. Add users by providing the following information:

Assign the user to roles

  1. Roles can be assigned to the users as shown below:

  1. The application username can be changed using the edit icon.

  1. Capture the Identity Provider metadata URL from the OKTA portal, as mentioned in the screenshot below.

  1. Click on View IdP metadata, and the XML file is displayed. Copy the URL from the browser and mention it in the samlHTTPMetadataProvider: <IdP Metadata URL>

  2. Open the oasis.properties file and add the following variables, respectively

    1. samlHTTPMetadataProvider: <IdP Metadata URL>

    2. entityBaseURL: https://<domain>

  3. Save the oasis.properties file and restart the OvalEdge App.

  1. Edit the setenv.sh file in the Tomcat bin folder, and update the security type parameter from db to saml:

Update -DOVALEDGE_SECURITY_TYPE=db to -DOVALEDGE_SECURITY_TYPE=saml.

Testing the Roles

Testing the Roles with REMOTE and HYBRID SAML Type

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

  2. 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.

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

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

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

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

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

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

PreviousMicrosoft Active DirectoryNextOneLogin

Last updated

Was this helpful?