Skip to main content

Security

By default, Cortex uses Cherwell's security groups to control access to Business Objects and specific records. Specifically, the features of security groups that are evaluated are:

  • READ access to each Business Object
  • Custom filters (e.g. for records that were created by or on behalf of the current user)

Of note, field-level permissions are not respected; if you have rights to see the record, you have rights to see all the fields.

More details

The process Cortex uses to determine authorization and security is as follows:

  1. The user authenticates via your configured authentication scheme.
  2. Cortex receives a series of "claims" (information about the user, e.g. username and email address)
  3. Cortex looks up the username or email address (depending on configuration) in the Cherwell data to determine which security group the user is part of.
  4. Based on this security group, access to specific business objects is granted or denied.

Adding and updating users

By default, all users who (a) had access to Cherwell (and therefore have the necessary records in the Cherwell data for the above flow) and (b) are allowed to log in via your SSO provider will have access to Cortex, but there might be some scenarios where that's not exactly what you want:

User leaves the organization

Disable the user's access in your SSO provider.

User is still at your organization, but should no longer have access to Cherwell data

Revoke permissions to the application at your SSO provider, if possible. Otherwise, enable Cortex's User Management features below and set the user's Security Group to "Anonymous Browser".

New user should have access to Cherwell data

Enable Cortex's User Management features below and add the user to Cortex manually.

Existing user should have different permissions

Enable Cortex's User Management features below. If the user has logged in, they'll show up as a row that can be edited. Otherwise, add them manually with the desired configuration.

Enabling Cortex's User Management feature

warning

Cortex will never require write access to any Cherwell data. However, the configuration below piggybacks off the same SQL connection for the read/write data necessary for user management.

The following instructions are fairly technical and require familiarity with SQL Server Administration.

note

If you set up Cortex with a read/write user, this is already set up and you don't need to do anything else. However, if you decide later to use a read-only user, you will have to follow Step 2 below.

Starting with version 1.5, Cortex can store security-related data in a separate "schema" from the Cherwell data, using the authentication-related data in Cherwell as the initial values. This allows the same user Cortex uses to access the historical, read-only data to also have read/write access to the Cortex-specific tables.

SQL Commands are provided, but the same steps can be done through SSMS.

  1. Create the "cortex" schema in the same database with your Cherwell data.
    create schema cortex;
  2. Grant the database user read/write permissions to the schema
    grant control on schema ::cortex to [the_cortex_sql_user];
  3. Restart Cortex. Cortex automatically creates the other tables it needs to handle authorization.