# 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.
3. Give the App name as OvalEdge and upload the OvalEdge logo, which is optional.
{% hint style="info" %}
The OvalEdge log can be downloaded from the website [www.ovaledge.com](http://www.ovaledge.com).
{% endhint %}
4. Now, configure the SAML Settings.
5. **Single Sign-on URL**: This should be the application URL of the load balancer, followed by {context}/saml/SSO
\
**Example**:
{% hint style="info" %}
It must be SSL-enabled.
{% endhint %}
6. **Receipt URL and Destination URL**: This should be the Load Balancer DNS or Domain URL with HTTPS
\
**Example**:
7. **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**:
### 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
2. Also, map the roles that will match against the **OKTA GroupName** values and **OvalEdge Manage Roles**.
3. 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.
{% hint style="info" %}
* 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.
{% endhint %}
## 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.
{% hint style="info" %}
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.
{% endhint %}
### Adding people to the OKTA
1. Add users by providing the following information:
