Security Enhancement for OData Queries

The focus of the security enhancement for OData queries are system integrations with Anthology Student APIs. Integrations use Commands, REST services, and OData endpoints. Previously, all OData endpoints (queries) were available to any authenticated user. If users (even API users) were authenticated, they had full access to all the queries. This enhancement secures access to OData endpoints in the Query Model in the same manner as in the Command Model APIs. If a user, outside of the Anthology Student web client UI, attempts to access a Query Model to which they have no access, the controller will respond with a status "401 Unauthorized".

The OData endpoint security enhancement takes effect with the following releases:

• Anthology Student 21.2.0

• Faculty Workload Management (FWM) 1.2.0

• Financial Aid Automation (FAA) 8.2.0

• Regulatory 12.2.0

OData Query Authorization

In prior versions of these products, once a user (or 3rd party) was authenticated in Anthology Student, all OData endpoints were available for use and all OData queries were available. Access to the Query Model was not restricted via NetSqlAzMan (NSA) in the Security Console.

The OData endpoint security enhancement establishes NSA authorization for the Query Model by adding all Query Model entities to the NSA configuration file. All query operations in NSA are contained in the new Task "All Query Operations" in the Security Console. For backward compatibility, the Task “All Query Operations” has been assigned to the CMC System Administrators Role. This task needs to be added to any other additional roles where backwards compatibility is desired. For the future, individual organizations can create custom tasks from the operations added to the model as needed and assign them to roles as required.

With this enhancement, access to queries is restricted and query operations for each entity are added. Examples of the query operations include:

• Academics.Course.Query

• Common.Student.Query

• Crm.DocumentType.Query

The naming pattern for query operations is: <Module>.<Entity>.Query

Users executing OData queries will either need a QueryToken (cookie) provided by the Anthology Student web client UI or authorization granted in NSA for specific Query Model entities requested in the query.

Note: Users logging in via the web client for Anthology Student will not be affected by this change. Access to the various areas of the application continues to be controlled via the Tasks assigned in the Security Console.

The enhancement requiring OData query authorization may impact the following audiences:

• Partners doing integrations with Anthology Student

• Clients who have already leveraged this ability in prior versions of the product

• Client implementations that use custom logic created by our Professional Services team

• Professional Services teams working on integration projects

Configure OData Query Authorization

When you begin working with Anthology Student version 21.2 or any of the other product versions above, you need to go into your Security Console and either:

• Grant everyone who needs access to this capability the Task All Query Operations. This is not the recommended approach but mirrors existing functionality.

  

  Note: The "All Query Operations" Task is not assigned to the Cmc System Administrators Role. The administrator Role (Group) already has an “All Operations” Task that includes the new query operations. This is done automatically.

  — OR —

• Build custom tasks for groups/roles and grant them access to the query operations they need. Query operations would then be added to Tasks as necessary. You can filter the operations and entities to create custom tasks. This is the recommended long term approach.

  One Task which includes all of the Operations could be added, for example, "System.Query.All" or similar. This would enable the same behavior that is currently provided for users of the Anthology Student web client UI, who currently have access to all entries in the OData Query Model.

Workflows and OData Query Authorization

Activities in Workflow Composer that use OData endpoints will fail if the APIUser does not have the necessary OData authorization. By default, the APIUser is a member of the Administrator group which has the OData authorization. However, if a client has a custom APIUser, this user will need access to the OData query operations.

All workflow activities with properties that are populated by OData queries will require OData query authorizations.

Note: The ExecuteODataQuery<> activity will fail with a "401 Unauthorized" response if the APIUser does not have access to any of the entities referenced in the query. If multiple entities are included in an OData query, the user must be authorized to ALL of the entities in order for the query to execute.

Example

A user adds a “Create Task” activity to a workflow. This activity has drop-down list for Task Template and Task Status which are populated by OData calls.

1. When the user's APIUserName in the SyRegistry table is "administrator", the drop-down lists are populated without error because as the"‘administrator" user is part of the Administrators Group.

   

   

2. When the APIUserName is a different account (user@campusmgmt.com), the CreateTask activity fails with an "Access denied" error.

   

   

3. After adding the account (user@campusmgmt.com) to the Administrators Group in the Security Console and clearing the cache in the UI to remove the cached NSA items, the CreateTask activity works again.

   Instead of adding the user account to the Administrators Group, the user account could have been granted specific access to each OData query operation.