Configuration
      Back to home
      1. Knowledge Base
      2. Installation and System Setup
      3. Configuration

      SSO Configuration with Okta

      This document provides information about the step-by-step process for configuring SSO with OKTA.

      OvalEdge

      OvalEdge is a data catalog that creates a comprehensive catalog for all an organization's data sources. It is a web-based application that provides role-based access to various users.

      OvalEdge supports a variety of authentication mechanisms like plain old Username and Password, OKTA, and Active Directory. 

      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. You can 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): This is 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 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.

      Configuring OKTA SSO

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

      1. Login to OKTA. In Applications, click on the Create a New App Integration. 
      2. Select SAML 2.0 from the list of available options and click on the Next button. 
      3. Give the App name as OvalEdge and upload the OvalEdge logo which is optional. 

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

        1. Now configure the SAML Settings.
        2. Single Sign-on URL: This should be the application URL of your load balancer followed by {context}/saml/SSO 

          Example: https://testing.ovaledge.cloud/{context}/saml/SSO

          Note: It should be SSL enabled. 
        3. Receipt URL and Destination URL: This should be the Load Balancer DNS or Domain URL with HTTPS 

          Example: https://testing.ovaledge.cloud/

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

          Example: https://testing.ovaledge.cloud/{context}/saml/metadata

        Mapping of OKTA fields to OvalEdge

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

          Note: Please ensure that there is no typo
          1. userId
          2. firstName
          3. lastName
          4. email
        3. Also, map the roles that will match against the OKTA GroupName values and OvalEdge Manage Roles.

          Note: This Prefix must be configured in the OvalEdge Configuration as saml.role.prefix value.
        4. 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.
        5. To maintain group management in the OKTA, click on Add Group and enter Name and Group Description. 
        6. The groups that were created are displayed below. 

          Note: 

          1. A Prefix must be added before the group name when adding Groups in OKTA.
          2. 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.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

        The only suffix will be created in the OvalEdge application.

        Note: The permissions for these roles will be managed in OvalEdge. However, user/ role management will be done in OKTA. You can use your naming convention, but you have to configure it in OvalEdge. 

        Adding people to the OKTA

        We can add users by providing the following information:

        Assign the user to roles

        Roles can be assigned to the users as shown below:

        The application username can be changed using the edit icon.

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

        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>

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

        1. samlHTTPMetadataProvider: <IdP Metadata URL>
        2. entityBaseURL: https://<domain> 

        Save the oasis.properties file and re-start the OvalEdge App. 

        Testing the Roles 

        Testing the Roles with REMOTE and HYBRID SAML Type

        1. With Hybrid, The Directory Users would get the role from the OvalEdge Application.
        2. With Remote, The Directory Users would get the role from OKTA.

        Note: For the first time, Users logged in with 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: 

        Now, you have connected your OKTA with the Ovaledge application.