Deep Dive Articles
      Back to home
      1. Knowledge Base
      2. Access Management
      3. Deep Dive Articles

      OvalEdge Object Security

      Overview

      OvalEdge provides a comprehensive data governance solution, with a wide range of security features to ensure the protection and controlled access to data objects. 

      This article will explore various aspects of OvalEdge's measures to implement security on a high level and various Data Objects like, Connectors, Databases & Schemas, Tables, Table Columns, File/Folder Security, Report Groups, Reports, Domains, Story Zone, Dashboards, DAG Tag Work Flow, Governance Roles, Applications, APIs and API Attributes. 

      Additionally, we will explore how OvalEdge's Application Security empowers Administrators to manage user access to various modules, and sub-modules that OvalEdge offers.

      Security on Objects in OvalEdge

      • Role Based Access Control (RBAC): Most organizations have predefined Roles, to establish the scope and responsibilities that have to be taken up by all the individuals who are part of that role, to simplify and reduce the redundancy of defining the scope for each individual.OvalEdge Administrators will create Roles and define Security by using authorized Roles to access various data objects.
      • User-Based Access Control (UBAC): OvalEdge supports User creation and defining Security using authorized users to access various data objects.
      • Using Governance Roles: Various organizations generally hire certain specialists to implement Governance. These are Roles like Steward (A domain specific Subject Matter expert), Custodian (A technical expert, who assists in data curation), and Owner (An individual who has the ultimate authority over specific Data assets). With OvalEdge, Governance roles can maintain the quality and integrity of the cataloged objects. OvalEdge Teams can also be assigned a Governance role.

      License Types and Access Permissions

      There are two types of User Licenses offered by OvalEdge. They are known as Viewer and Author. Depending on the User License type, the associated Roles will have certain Metadata and Data permissions.

      • Viewer License: This license type is catered for a typical Business User in an organization, such as a Business Analyst, who can read, browse, and search the Metadata that is curated and make certain decisions to ease their day-to-day business activities. With the Viewer license type, a user cannot perform certain actions (like updating or modifying metadata) and hence does not have access to certain modules and sub-modules of OvalEdge (like Administration module and Security sub-module).
      • Author License: The Author license type is catered for certain Management and Administrative roles, who are primarily responsible for curating the Metadata and deciding what specific access has to be given for certain users & roles.

      Metadata Permissions

      OvalEdge offers two different types of Metadata Permissions, which can be defined on Roles that are eventually associated with various Users. They are:

      • Meta-Read Only (MR): With Meta Read only, the associated roles can just read and consume the Metadata that is curated, and make certain suggestions to change the Metadata if they feel so. With the Viewer license type, one can only have Meta Read permission.
      • Meta Read-Write (MW): With Meta Read-Write the associated roles can not only Read the metadata curated but also have the option of making any changes to that curated metadata. With the Author license type, a role can have any of the Metadata permissions.

      Data Permissions

      OvalEdge offers four different types of Data Permissions, which can be defined on Roles that are eventually associated with various Users. They are:

      • Data No Access (DN): If Data No Access is defined on a user/role, then it restricts any form of Data to be accessed by that particular role.
      • Data Preview (DP): With Data Preview, OvalEdge grants the user/role to only View the Data (which is a preview of the sample data count that has been configured in profiler settings of the connector) in the Data tab of Tables (which hits a live call to the source data), and the ability to see the profiled information
      • Data Read (DR): In addition to Data Preview, with Data Read, OvalEdge’s Query sheet and Governed Data Query (GDQ) can be accessed, to view and run queries (like Select), and with Data Read, one can also download the data.
      • Data Write (DW): In addition to capabilities offered by Data Read, a user/role with Data Write can write queries to Insert, Update, or Delete data.

      Users, Roles & Teams Creation

      In OvalEdge, users and roles are added or created through a System Configurable Admin role called “Users & Roles Administrator” and it is configured by modifying the key value “oe.user&role.admin” available in the System Settings > Users & Roles tab. 

      Roles Creation

      The following ways can be used to create roles.

      • Administration > Users & Roles Management > Roles Tab 
      • Advanced Tools > Load Metadata from Files 
      • Advanced Tools > OvalEdge APIs, An advanced tool of OvalEdge (Method: POST API: /api/security/role/add) 
      • Roles created and present in Active Directories (like Okta, Azure AD)

      Users creation

      The following ways can be used to create users.

      • Administration > Users & Roles Management > Users Tab 
      • Advanced Tools > Load Metadata from Files 
      • Advanced Tools > OvalEdge APIs, An advanced tool of OvalEdge (Method: POST API: /api/user/add) 
      • Users created and present in Active Directories (like Okta, Azure AD)

      Teams creation

      The following ways can be used to create Teams.

      • Administration > Users & Roles Management > Users Tab 
      • Groups or Teams created and present in Active Directories (like Okta, Azure AD)

      OvalEdge Security

      The Security module in OvalEdge can be accessed through Administration, only certain OvalEdge defined Administrator roles get to view data objects and sub-modules and define various kinds of access permissions on them. For a role to be any of the Administrator roles in OvalEdge, an Author License type is mandatory.

      Connector Security

      Using connectors developed by OvalEdge, a connection is established between OvalEdge and the source system to perform various actions like crawling metadata, profiling data, crawling and enforcing various policies of the source system, and managing access permissions. 

      Once a Connector is Saved/Validated/Crawled, the Security & Governance Admin (SGA) defined during a Connector creation can view the list of all the Connectors in the Connectors Security tab, for those the role is an SGA. The role is an Admin for the specific connector and hence will have the highest possible permissions by default, i.e., Metadata Read-Write (MW), & Data Write (DW). 

      Along with SGA, the OE_ADMIN (“ovaledge.role.admin”) gets the Metadata Read-Write (MW), & Data Write (DW) permissions pre-applied on all the Connectors. 

      Editing a specific Connector’s details or performing actions like Crawling, Profiling, Crawl and Profile, or Scheduling a Crawl, Crawl and Profile, or Deleting a connector can be done by the Administrator role, “Integration Admin” (Defined during connector creation).

      The following actions can be performed from a Connectors Security page:

        • Defining and Updating Permissions to Roles & Users on Connectors
          • Add/Modify/Delete permissions inline: SGA and OE_ADMIN alone for an individual role and user through the edit icon (which opens up an Update Permission window) can Add/Modify/Delete Metadata and Data access permissions on a Connector. 
          • Add/Modify/Delete permissions using 9-Dots: SGA and OE_ADMIN alone on Single or Multiple connectors can Add/Modify/Delete Metadata and Data access permissions.  
            • Add Role Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular role on this connector. The Meta and data permissions defined are dependent on the license type.
            • Add User Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular user on this connector. The Meta and data permissions can be defined depending on the license type.
            • Cascade to Hierarchy (Permissions): If an organization believes the permissions defined at a Connector level can be passed on to all the Data Objects present in that connector, OvalEdge's Cascade to Hierarchy feature can be utilized. SGA and OE_ADMIN can Add/Modify/Delete permissions of all data objects on this connector by checking this checkbox.
            • Define Admin: SGA and OE_ADMIN can define a Role as Admin, which will eventually make this role, SGA for this connector and provide the highest Meta and Data permissions.
        • Defining and Updating Governance Roles on Connectors:
          • Connector Creator: Defines the mandatory Governance roles during the connector creation.
          • Update Governance Roles inline: SGA and OE_ADMIN alone can Update the Governance Roles on an individual connector.
          • Update Governance Roles through 9-Dots: SGA and OE_ADMIN alone on individual connectors or multiple connectors update the Governance roles through 9 dots.
          • Cascade to Hierarchy (Governance Roles): SGA and OE_ADMIN alone through 9-Dots, update Governance Roles, and cascade the same on all data objects of the connector.
      • Delete Roles Access individually or in bulk: SGA and OE_ADMIN alone can delete access permissions defined to Roles on an individual connector or multiple connectors through 9-Dots.

      Database & Schema Security

      For the Databases and Schemas that are Connected/Validated/Crawled, the Administrator role can  View and Perform certain actions through the Database Security tab. The following actions can be performed from a Databases Security page:

        • Defining and Updating Permissions to Roles & Users on Databases:
          • Add/Modify/Delete permissions inline: SGA and OE_ADMIN alone for an individual role and user through the edit icon (which opens up an Update Permission window) can Add/Modify/Delete Metadata and Data access permissions on a Database. 
          • Add/Modify/Delete permissions through 9-Dots: SGA and OE_ADMIN alone on Single or Multiple databases can Add/Modify/Delete Metadata and Data access permissions.  
            • Add Role Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular role on this database. The Meta and data permissions that can be defined depend on the license type.
            • Add User Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular user on this database. The Meta and data permissions can be defined depending on the license type.
            • Reflect Changes to Table: If an organization feels, the permissions defined at a Database level can be passed on to all the Tables present in that database, OvalEdge's Reflect Changes to Table feature can be utilized. SGA and OE_ADMIN can Add/Modify/Delete permissions of all tables on this database by checking this checkbox.
            • Define Admin: SGA and OE_ADMIN can define a Role as Admin, which will eventually make this role, SGA for that database, and eventually the connector and provide the highest Meta and Data permissions.
        • Defining and Updating Governance Roles on Databases:
          • Connector Creator: Defines the mandatory Governance roles during the connector creation.
          • Update Governance Roles inline: SGA and OE_ADMIN alone can Update the Governance Roles on an individual database.
          • Update Governance Roles through 9-Dots: SGA and OE_ADMIN alone on an individual database or multiple databases update the Governance roles through 9-Dots.
          • Cascade to Hierarchy (Governance Roles): SGA and OE_ADMIN alone through 9 dots, update Governance Roles, and cascade the same on all tables and table columns of the database.
      • Delete Roles Access individually or in bulk: SGA and OE_ADMIN alone can delete access permissions defined to Roles on an individual database or multiple databases through 9-Dots.

      Table Security

      For the Tables that are Crawled, the Administrator role can view and perform certain actions through the Tables Security tab.

        • Defining and Updating Permissions to Roles & Users on Tables:
          • Add/Modify/Delete permissions inline: SGA and OE_ADMIN alone for an individual role and user through the edit icon (which opens up an Update Permission window) can Add/Modify/Delete Metadata and Data access permissions on a table. 
          • Add/Modify/Delete permissions through 9-Dots: SGA and OE_ADMIN alone on Single or Multiple tables can Add/Modify/Delete Metadata and Data access permissions.  
            • Add Role Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular role on this table. The Meta and data permissions that can be defined depend on the license type.
            • Add User Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular user on this table. The Meta and data permissions that can be defined depend on the license type.
            • Reflect Changes to Table: If an organization feels, the permissions defined at a Table level can be passed on to a specific Table present in that database, OvalEdge's Reflect Changes to Table feature can be utilized. SGA and OE_ADMIN can Add/Modify/Delete permissions of a specific table by checking this checkbox.
            • Define Admin: SGA and OE_ADMIN can define a Role as Admin, which will eventually make this role, SGA for that table, and eventually the connector and provide the highest Meta and Data permissions.
        • Defining and Updating Governance Roles on Tables:
          • Connector Creator: Defines the mandatory Governance roles during the connector creation.
          • Update Governance Roles inline: SGA and default Role Admin alone can Update the Governance Roles on an individual table.
          • Update Governance Roles through 9-Dots: SGA and default Role Admin alone on an individual database or multiple tables update the Governance roles through 9 dots.
          • Cascade to Hierarchy (Governance Roles): SGA and default Role Admin alone through 9 dots, update Governance Roles, and cascade the same on all table columns of the table.
      • Delete Roles Access individually or in bulk: SGA and OE_ADMIN alone can delete access permissions defined to Roles on an individual database or multiple tables through 9 dots.
      • Column Security Checkbox: SGA and OE_ADMIN alone can check the Column security checkbox and enforce policies on Table columns.
      • Row Access Policy: If a Row Access Policy is defined on the particular table (through which an organization can decide if Access to certain rows of the Table should be limited)       

      Table Column Security

      For the Table Columns that are Crawled, the Administrator role can view and perform certain actions through the Table Columns Security tab.

      • View and Access the list of Tables Columns that are Crawled:
        • For Table columns, the Access permissions defined at the individual Table level will reflect all the Table Columns of that Table.
      • Defining and Updating Governance Roles on Table Columns:
        • Update Governance Roles inline: SGA and OE_ADMIN alone can Update the Governance Roles on an individual table column.
        • Update Governance Roles through 9-Dots: SGA and OE_ADMIN alone on an individual table column or multiple columns can update the Governance roles through 9 dots.
      • Mask a Column: If an organization is aware of certain sensitive data present in any of the Table columns like Personal Identifiable Information (Social Security Number, Phone Number) or Protected Health Information (Patient’s Insurance Details, Laboratory Results), they can utilize OvalEdge’s Masking feature, to safeguard such information, being exposed to unauthorized individuals.

              Note: SGA & OE_ADMIN alone can define a masking policy on a column.

      • Mandatory Fields to create a Policy: Policy name (should be unique with no spaces), Policy Scheme (Mask all characters, Show first 4 characters, etc).
      • Optional Fields: Allowed or the Authorized Roles and Users who are exempted from this policy.
      • Policy once assigned can be seen under the Masking Policy column for the respective Table column.
      • Masking a Column using Business Glossary: A table column can be also masked, using Terms that are created in the Business Glossary. A User/Role with Meta-Write permission on a Term (Domain) can check the Masked checkbox, define the masking policy type, and later associate the specific Table column/columns and mask it. We can create a masking policy on a term, only when the term is in Draft state. Once a Term with a masking policy is associated with a Column/Columns, in the Table Columns tab of Security, the respective Column/Columns would be masked and the Column Security checkbox would be enabled.
      • Restrict Column: If an organization feels certain Table columns should be completely restricted and only certain Roles should be provided access to view them, this can be done by checking the Restrict Column checkbox in the Table Column Security tab. This can be done by SGA and OE_ADMIN alone.

      Folder/File Security

      Once a Connection is established with a File System type Connector, the default security will be applied to the root folder of the connection, and the same access security will be applied to all the child folders under it. That is, the SGA and OE_ADMIN would have the highest Meta and Data permissions. Once access security is changed on a child folder, the access would be replicated on the subsequent sub-child folders present. The access security defined on a Folder would be applied to all the Files associated with them.


      For separate security to be applied on a child folder, the Administrator would need to click “Add New Folder” can be selected, and the specific Datalake and path of the folder can be entered. The corresponding role or user’s metadata and data access can be provided, this action must be done by either the SGA or OE_ADMIN.

      • Defining and Updating Permissions to Roles & Users on the Folder.
      • Defining and Updating Governance Roles on Folder.
      • Update Permissions and Governance Roles through 9-Dots:
        • Access permissions and governance roles can be updated through 9 dots as well by SGA and OE_ADMIN alone.
      • Delete Roles Access individually or in bulk: SGA and OE_ADMIN alone can delete access permissions defined to Roles on an individual folder or multiple folder paths through 9-Dots.

      Report Group Security

      Report Groups can be created based on the type of Report they are, and the Connector type. Security can be implemented on such Report groups from the Report Groups security tab of OvalEdge security, to facilitate various Access Permissions and Governance that have to exist on them.

        • Creating and Updating a Report Group: 
          • SGA and OE_ADMIN alone can create and update a Report Group.
          • Mandatory fields to create a Report group are Report Group type, Report Group’s Name, Report Group’s description, and selecting the appropriate Connector.
        • Defining and Updating Permissions to Roles & Users on Report Groups:
          • Add/Modify/Delete permissions inline: SGA and OE_ADMIN alone for an individual role and user through the edit icon (which opens up an Update Permission window) can Add/Modify/Delete Metadata and Data access permissions on a report group. 
          • Add/Modify/Delete permissions through 9-Dots: SGA and OE_ADMIN alone on Single or Multiple report groups can Add/Modify/Delete Metadata and Data access permissions.  
            • Add Role Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular role on this table. The Meta and data permissions that can be defined depend on the license type.
            • Add User Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular user on this table. The Meta and data permissions that can be defined depend on the license type.
            • Reflect Changes to Reports: The Security Access defined on a Report group, can be passed on to the Reports part of this Report Group, by checking this checkbox. This can be done by particular SGA and default Role Admin alone. 
            • Define Admin: SGA and OE_ADMIN can define a Role as Admin, which will eventually make this role, SGA for that table, and eventually the connector and provide the highest Meta and Data permissions.
        • Defining and Updating Governance Roles on Report Groups:
          • Connector Creator: Defines the mandatory Governance roles during the connector creation.
          • Update Governance Roles inline: SGA and OE_ADMIN alone can Update the Governance Roles on an individual report group.
          • Update Governance Roles 9-Dots: SGA and OE_ADMIN alone on an individual report group or multiple report groups update the Governance roles through 9 dots.
          • Cascade to Hierarchy(Governance Roles): SGA and OE_ADMIN alone through 9 dots, update Governance Roles, and cascade the same on all reports of the report group.
      • Delete Roles Access individually or in bulk: SGA and OE_ADMIN alone can delete access permissions defined to Roles on an individual report group or multiple report groups through 9 dots.
      • Delete an existing Report Group/Report Groups: SGA and OE_ADMIN alone can delete existing individual or multiple report groups.

      Report Security

      Reports that are crawled from various Report type Connectors appear here, with predefined highest Meta and Data permissions defined on SGA and default Role Admin.

      • Defining and Updating Permissions to Roles & Users on Reports:
        • Add/Modify/Delete permissions inline: SGA and OE_ADMIN alone for an individual role and user through the edit icon (which opens up an Update Permission window) can Add/Modify/Delete Metadata and Data access permissions on a Report. 
        • Add/Modify/Delete permissions through 9-Dots: SGA and OE_ADMIN alone on Single or Multiple reports can Add/Modify/Delete Metadata and Data access permissions.  
          • Add Role Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular role in this report. The Meta and data permissions that can be defined depend on the license type.
          • Add User Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular user on this report. The Meta and data permissions can be defined depending on the license type.
          • Define Admin: SGA and OE_ADMINcan define a Role as Admin, which will eventually make this role, SGA for that report and eventually the connector and provide the highest Meta and Data permissions.
      • Defining and Updating Governance Roles on Reports:
        • Connector Creator: Defines the mandatory Governance roles during the connector creation.
        • Update Governance Roles inline: SGA and OE_ADMIN alone can Update the Governance Roles on an individual report.
        • Update Governance Roles 9-Dots: SGA and OE_ADMIN alone on an individual report or multiple reports update the Governance roles through 9-Dots.
      • Delete Roles Access individually or in bulk: SGA and OE_ADMIN alone can delete access permissions defined to Roles on an individual report or multiple reports through 9 dots.
      • Delete an existing Report/Reports: SGA and OE_ADMIN alone can delete existing individual or multiple reports

      Domain Security

      An organization may contain multiple domains, like a Finance Domain, a Logistics Domain, or a Marketing Domain. Using OvalEdge’s comprehensive access management framework, Administors can decide who should get to Create a domain in OvalEdge, who can update and manage that domain, and who can delete a domain in OvalEdge.

      Creating a new domain can be done by an Administrator role alone called “Domain Creator”, which can be configured in the System settings with the following config: “ovaledge.domain.creator”. A Domain Creator defines Security and Governance Administrator and Governance roles for that domain.

      Once a domain is created, SGA and OE_ADMIN alone can perform the following actions through 9-Dots:

      • Add to My Watchlist: Only SGA of corresponding domains and OE_Admin can add a domain to My Watchlist through Security. But a role with even read access on a domain, can add a domain to the corresponding user’s My Watchlist, and receive notifications for the corresponding Metadata change selected.
      • Remove from My Watchlist: Only SGA of corresponding domains and OE_Admin can remove a domain from My Watchlist through security. But a role with even read access on a domain can remove a domain from the corresponding user’s My Watchlist if needed.
        • Update Access Permissions of Roles and Users (Meta and Data): Through inline or through 9-dots, only SGA of corresponding domains and OE_Admin can add/edit/delete roles and users' meta and data access.
        • Update Governance Roles (On individual domains or multiple domains):  Through inline or through 9-dots, only SGA of corresponding domains and OE_Admin can add/edit/delete the governance roles of a domain.
        • Delete Roles Access Permissions of Roles (Individual or multiple roles):  Through 9-dots, only SGA of corresponding domains and OE_Admin, in bulk remove access of various roles on those domains.
      • Configure Classification: Only SGA of corresponding domains and OE_Admin can configure classifications on a domain
      • Configure Categories: Only SGA of corresponding domains and OE_Admin can configure categories of a domain.
      • Default Data Association Preferences: Only SGA of corresponding domains and OE_Admin through 9-dots, can define the default data association preferences through checkboxes provided, which are, Copy Title to Catalog, Copy Business Description to Catalog, Masked, Restricted, Show Classification in Catalog, which eventually reflect in all the Terms of that corresponding domain.

      Story Zone Security

      Data Stories in OvalEdge serve to create, modify, and organize business knowledge within OvalEdge. Information can be neatly documented and made available for data discovery and reuse within an organization. Data stories are grouped under specific entities known as Story Zones. Administrators can use Story Zone’s security tab to create a Story zone, and Add/Modify/Delete the Access permissions of roles and users, who are part of that story zone.

      • Creating a Story Zone - Done by System Configured Admin Role (“ovaledge.role.admin”) and OE_Admin. The story zone created would be reflected in the Data Stories module.
      • Defining and Updating Permissions to Roles & Users on Story Zone:
        • Add/Modify/Delete permissions inline: SGA and OE_ADMIN alone for an individual role and user through the edit icon (which opens up a shutter) can Add/Modify/Delete Metadata and Data access permissions on a story zone. 
        • Add/Modify/Delete permissions 9-Dots: SGA and OE_ADMIN alone on Single or Multiple tables can Add/Modify/Delete Metadata and Data access permissions.
          • Add Role Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular role on this story zone. The Meta and data permissions that can be defined depend on the license type.
          • Add User Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular user on this story zone. The Meta and data permissions that can be defined depend on the license type.
          • Define Admin: OE_ADMIN and Admin Role (“ovaledge.role.admin”) alone can define a Role as Admin, which will eventually give the role/user the highest Meta and Data Permissions on that story zone.
      • Delete Roles Access individually or in bulk: SGA and OE_ADMIN alone can delete access permissions defined to Roles on an individual story zone or multiple story zones through 9 dots.
      • Delete an existing Story Zone: SGA and OE_ADMIN can delete a story zone, which will delete (if any) all the stories that are part of that story zone.

      Dashboard Security

      Creation and Managing access of Dashboards in OvalEdge can be done through the Dashboards tab in the Security module, and this can be done by the System Configured Admin Role (“ovaledge.role.admin”) and OE_Admin. 

      Different Dashboard Types:

      • System Dashboard: These Dashboards appear only when an Advanced job is run by a System Configured Admin Role (“ovaledge.role.admin”). The advanced job name (“Enable system dashboards”).
      • Favorite Dashboard: Out of the box personalized dashboard, available and visible exclusively for the specific user that has logged in.
      • Custom Dashboard: Apart from System Dashboards and out of the box dashboards that are available, Admin Role (“ovaledge.role.admin”) and OE_Admin can create Custom Dashboards.

      • Defining and Updating access permissions to Roles & Users on dashboards:
        • Add/Modify/Delete permissions inline: OE_ADMIN and Admin Role (“ovaledge.role.admin”) alone for an individual role and the user through the edit icon (which opens up a shutter) can Add/Modify/Delete Metadata and Data access permissions on applicable dashboards. 
        • Add/Modify/Delete permissions 9-Dots: OE_ADMIN and Admin Role (“ovaledge.role.admin”) alone on Single or Multiple applicable dashboards can Add/Modify/Delete Metadata and Data access permissions.
          • Add Role Access: OE_ADMIN and Admin Role (“ovaledge.role.admin”) alone can define the Meta and Data Permissions of a particular role on this dashboard. The Meta and data permissions that can be defined depend on the license type.
          • Add User Access: OE_ADMIN and Admin Role (“ovaledge.role.admin”) alone can define the Meta and Data Permissions of a particular user on this dashboard. The Meta and data permissions that can be defined depend on the license type.
          • Define Admin: OE_ADMIN and Admin Role (“ovaledge.role.admin”) alone can define a Role as Admin, which will eventually give the role/user the highest Meta and Data Permissions on that dashboard.
      • Delete Roles Access individually or in bulk: OE_ADMIN and Admin Role (“ovaledge.role.admin”) alone can delete access permissions defined to Roles on an individual dashboard or multiple applicable dashboards through 9-Dots.
      • Delete an existing Dashboard: OE_ADMIN and Admin Role (“ovaledge.role.admin”) alone can delete a dashboard.

      Data Asset Group (DAG) Tag Security

      OvalEdge Tags are used to organize data objects for better management and discovery. To apply security on tagged data a user would create and apply a DAG Tag. DAG Tags can be used to apply a new set of Governance stakeholders (Steward, Custodian, Owner) and Security Access on data objects, which overrides the ones defined initially on them.

      • Creating a DAG is performed by System Configured Role Admin (“ovaledge.role.admin”) and OE_Admin and they can:
        • Add/Modify/Delete permissions inline: SGA and OE_ADMIN alone for an individual role and user through edit icon(which opens up a shutter) can Add/Modify/Delete Metadata and Data access permissions on a DAG Tag. 
        • Add/Modify/Delete permissions 9-Dots: OE_ADMIN alone on Single or Multiple tables can Add/Modify/Delete Metadata and Data access permissions.
          • Add Role Access: OE_ADMIN alone can define the Meta and Data Permissions of a particular role on this DAG Tag. The Meta and data permissions that can be defined depend on the license type.
          • Add User Access: OE_ADMIN alone can define the Meta and Data Permissions of a particular user on this DAG Tag. The Meta and data permissions that can be defined depend on the license type.
          • Define Admin: OE_ADMIN alone can define a Role as Admin, which will eventually give the role/user the highest Meta and Data Permissions on that DAG Tag.
      • Manage Security: 
        • OE_ADMIN alone can check or uncheck this checkbox. If checked, and if DAG is assigned on a Data object, Security defined on the Data object will be replaced with Security defined on DAG, which is Authorized Roles and Users Access permissions on DAG.
      • Deleting a DAG:
        • OE_ADMIN alone can delete a DAG Tag. Once a DAG Tag is deleted, on the associated data objects, the default Access permissions and governance roles would be updated.

      Workflow Security

      Approval Workflow routes a service request to one or more individual users or roles or a team for approval or rejection. This process allows the organization to review the requests in a controlled and structured manner, ensuring that appropriate levels of oversight and governance are maintained. 

      Role Admin (“ovaledge.role.admin”) and OE_Admin alone can create and define custom workflows based on request types and the object types to be associated with a service request template which allows them to have more control over the service requests raised.

      The OE_ADMIN can perform the following additional actions in the Governance Roles Tab:

      • Creating an Approval Workflow
      • Declaring the Approvers and Service Level Agreement (SLA)
      • Deleting a Workflow

      Governance Role Security

      OvalEdge has three main Data Governance Roles defined which are Owner, Steward, and Custodian. These are users in an organization primarily used to manage data objects and ensure compliance with regulations and policies. 

      • OE_ADMIN (“ovaledge.role.admin”) alone can define what these Governance roles can be known by, that is by defining a Label for them and additional governance roles (Governance Role 4, Governance Role 5, and Governance Role 6) and descriptions of these roles to meet the standards and preferences of the respective organization. 

      • The OE_ADMIN can perform the following additional actions in the Governance Roles Tab:
        • View/Update the Governance Role’s Labels
        • View/Update the Governance Role’s Description
        • Enable/Disable optional Governance roles from the Approval Workflow
        • Decide to Allow/Do not allow to Display of the optional Governance Roles in the Data Catalog
        • Decide to Allow/Do not allow to Display of the optional Governance Roles in the Business Glossary

      APIs

      API is a set of rules and protocols that allow different software applications to communicate and interact with each other, enabling data exchange and functionality integration. For the APIs that are Crawled by OvalEdge, the appropriate Administrator role can view and perform certain actions through the APIs Security tab. The following actions can be performed from the APIs Security page.

        • Defining and Updating Permissions to Roles & Users on APIs:
          • Add/Modify/Delete permissions inline: SGA and OE_ADMIN alone for an individual role and user through the edit icon (which opens up an Update Permission window) can Add/Modify/Delete Metadata and Data access permissions on an API. 
          • Add/Modify/Delete permissions 9-Dots: SGA and OE_ADMIN alone on Single or Multiple APIs can Add/Modify/Delete Metadata and Data access permissions.  
            • Add Role Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular role on this API. The Meta and data permissions that can be defined depend on the license type.
            • Add User Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular user on this API. The Meta and data permissions can be defined depending on the license type.
            • Define Admin: SGA and OE_ADMIN can define a Role as Admin, which will eventually make this role, SGA for that API, and eventually provide the highest Meta and Data permissions.
        • Defining and Updating Governance Roles on APIs:
          • Connector Creator: Defines the mandatory Governance roles during the connector creation.
          • Update Governance Roles inline: SGA and OE_ADMIN alone can Update the Governance Roles on an individual API.
          • Update Governance Roles 9-Dots: SGA and OE_ADMIN alone on an individual database or multiple APIs update the Governance roles through 9-Dots.
          • Cascade to Hierarchy(Governance Roles): SGA and OE_ADMIN alone through 9-Dots, update Governance Roles and cascade the same on all attributes of the API.
      • Delete Roles Access individually or in bulk: SGA and OE_ADMIN alone can delete access permissions defined to Roles on an individual API or multiple APIs through 9-Dots.

      API Attributes

      An API attribute is a piece of data that is associated with an API resource. API resources are the objects that are exposed by an API, such as a product, a customer, or an order. The following actions can be performed from the API attributes Security page.

      • Defining and Updating Permissions to Roles & Users on API attributes:
        • Add/Modify/Delete permissions inline: SGA and OE_ADMIN alone for an individual role and user through the edit icon (which opens up an Update Permission window) can Add/Modify/Delete Metadata and Data access permissions on an API attribute. 
        • Add/Modify/Delete permissions 9-Dots: SGA and OE_ADMIN alone on Single or Multiple API attributes can Add/Modify/Delete Metadata and Data access permissions.  
          • Add Role Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular role on this API attribute. The Meta and data permissions that can be defined depend on the license type.
          • Add User Access: SGA and OE_ADMIN can define the Meta and Data Permissions of a particular user on this API attribute. The Meta and data permissions can be defined depending on the license type.
          • Define Admin: SGA and OE_ADMIN can define a Role as Admin, which will eventually make this role, SGA for that API attribute, and eventually provide the highest Meta and Data permissions.
      • Defining and Updating Governance Roles on API attributes:
        • Connector Creator: Defines the mandatory Governance roles during the connector creation.
        • Update Governance Roles inline: SGA and OE_ADMIN alone can Update the Governance Roles on an individual API attribute.
        • Update Governance Roles 9-Dots: SGA and OE_ADMIN alone on an individual database or multiple API attributes update the Governance roles through 9-Dots.

      Application Security

      OvalEdge's Application Security feature empowers OE_ADMIN or Role Admin (“ovaledge.role.admin”) to specify the precise access rights of individual users in the application. It ensures that only authorized users can access and interact with the modules and features they require. This is helpful in scenarios where certain individuals of an organization may not be totally aware of all the information that is shown and accessible in a module, and using Application Security of OvalEdge, organizations can choose to allow or not allow such sub-modules or tabs being shown to specific individuals. For example, a person working in Business Intelligence may keenly depend on Report and Report Column tabs of Data Catalog, but not need to know about APIs, Databases tabs. In this manner, using Application Security, on such specific paths 

      There are two ways to achieve this:

      • License-based Permissions: This method offers a broad level of access control where, Access of Users with Viewers license type can be configured by default admin role defined to specific applications. 

      Organizations can enable or disable the “Access for Viewers” toggle, using which they can allow or hide all Viewer license based users from specific tabs or sub-modules or modules of OvalEdge.

      • Role-based Permissions: This approach provides a more precise level of access control where different roles may have different levels of access to the application's modules based on their role.

      Organizations can enable the “Add Role Based Access” toggle, and define the Authorized Roles, using which they can allow or hide specific tabs or sub-modules or modules of OvalEdge from the specific Roles.

      • Example scenario of how this can be useful: Let’s say, there is a person working in the Business Intelligence domain in an organization, and mostly utilizes Reports tab of Data Catalog to ease themselves with their day-to-day activities. But for such an individual, it may not be beneficial to view the Tables tab of Data Catalog, and may lead to unnecessary confusions. In such scenarios, organizations can decide to hide this tab to be shown to this individual. And in this similar manner, organizations can decide to hide/display certain tabs, sub-modules, modules from a group of individuals with similar work profile (using license based control), or from specific roles (using role based access control)

      Only the default admin (“ovaledge.role.admin”) can define and maintain the Application Security with the following:

      • Add Role Based Access
      • Remove Role Based Access 
      • Enable Access for Viewers
      • Disable Access for Viewers 
      • Reset Permission 

      Additionally, if any particular Application Security has been defined and access to certain modules and sub-modules has been limited to specific people and if one wishes all this to be reset, this can also be set to default through “Reset Permission” in 9-Dots