Skip to main content
Version: 3.2

Security Groups

note

This page describes security group and user management behavior for Cherwell (CSM) deployments. Authorization for other source systems works differently and is not covered here.

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 respected only when you explicitly turn them on for the data source. By default, a user who has rights to see a record can see every field on it - see Field-Level Visibility below.

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.

Field-Level Visibility​

Cortex can also honor the View right that a user's security group holds on each individual field of a business object. This is opt-in, per data source, and off by default.

Field-level visibility is available from Cortex 3.2.1 onwards.

To turn it on:

  1. Open Admin → Data Sources and edit the Cherwell data source.
  2. Open the Field-Level Visibility tab.
  3. Check Enforce field-level visibility from security group View rights.

With it enabled:

  • A field the user's security group does not grant View on is shown as a blank value in results grids.
  • The form control for a hidden field is not displayed at all on record forms.
  • When a field has no explicit right of its own, the default right configured on that field list is used.

Because this changes what existing users see, review your Cherwell field rights and check a few records as a restricted user before enabling it in production.

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.