Skip to main content
Version: Next

Security Groups

By default, Cortex uses your source system's security groups to control access to Business Objects and specific records.

The features evaluated from security groups are:

  • READ access to each Business Object
  • Custom filters (for example, records created by or on behalf of the current user)

Field-level permissions are not respected. If a user has rights to see a record, they can see all fields on it.


How Authorization Works

The process Cortex uses to determine access is:

  1. The user authenticates via your configured authentication method.
  2. Cortex receives a set of claims about the user (such as username and email address).
  3. Cortex looks up the username or email address in the source data to determine which security group the user belongs to.
  4. Based on that security group, access to specific Business Objects is granted or denied.

Managing Users

By default, any user who had access to Cherwell and is permitted to log in via your SSO provider will have access to Cortex. There are some common scenarios where you may need to adjust this.

User leaves the organization

Disable the user's access in your SSO provider.

User should no longer have access to Cherwell data

Revoke their permissions in your SSO provider if possible. If not, enable Cortex's User Management feature (see below) and set their Security Group to Anonymous Browser.

New user needs access to Cherwell data

Enable Cortex's User Management feature and add the user manually.

Existing user needs different permissions

Enable Cortex's User Management feature. If the user has logged in before, they will appear as an editable row. If not, add them manually with the desired configuration.


Enabling User Management

warning

Cortex will never require write access to your Cherwell data. However, the configuration below uses the same SQL connection for the read/write data required for user management. These steps require familiarity with SQL Server administration.

note

If you set up Cortex with a read/write SQL user, this is already configured and no further action is needed. If you later switch to a read-only user, follow Step 2 below.

Starting in version 1.5, Cortex can store security-related data in a separate schema from the Cherwell data. This allows the same SQL user that reads Cherwell data to also have read/write access to Cortex-specific tables.

These steps can also be performed through SSMS if you prefer a GUI.

  1. Create the cortex schema in the same database as your Cherwell data:

    CREATE SCHEMA cortex;
  2. Grant the Cortex SQL user read/write access to the schema:

    GRANT CONTROL ON SCHEMA ::cortex TO [the_cortex_sql_user];
  3. Restart Cortex. The application will automatically create the tables it needs.