Access Keys:
Skip to content (Access Key - 0)

CSM

Managing Instance Level Security Filters


"Instance Level Security is a feature provided by CSM to allow filtering of the instances of data directly at the database level by creating filter criteria and linking those criteria with allowed values from CSM tables." (excerpt from the caCORE CSM v4.2 Programmer's Guide)

Instance Level Security Filters are considered to be beta level functionality for the 1.3 CSM Service release. For the 1.3 release, using these security filters is not recommended for production level software and users may discover some issues using instance level filters. Future releases will address these issues and make instance level filters more production ready.

Table of Contents

Overview


CSM administrators can provision security filters for instances of domain classes. The API then filters query results based on the specified access policy. There are several ways to create instance level security filters: Direct Instance Level Security or Cross Dependant Instance Level Security.

Direct Instance Level Security is a case where security for a particular instance is dependent only upon itself. There is no relationship or association with any other objects. A user or group has access to an object based on one of it's attribute values. For example, a user may be granted access to patient objects based on the patient id value.

With Cross Dependant Instance Level Security, security for a particular instance is dependent on another object. A user or group is given access to an instance based on to another, higher-level object. This type of security configuration is useful in cases where it is easier to configure high level objects and allow lower level objects to inherit the configuration. For instance, assume there are clinical encounter objects associated with patient objects. It would be possible to limit a user or group's access to the encounter objects by limiting access to the patient objects instead. Thus, the user or group would only be able to view the encounter objects that are associated with patient objects they have access to.

For more information on these and other topics related to instance level security filters, please refer to Chapter 5 of the caCORE CSM v4.2 Programmer's Guide.

Administrative Access


In order to manage CSM applications and resources, you must be logged into a grid account that is configured to be a CSM administrator. During the installation process, it was recommended that at least one grid identity be added as a CSM administrator. If your account was not configured to be a CSM administrator, review step 7 of the Installation Guide.

If you have added your grid account as a CSM administrator but you are experiencing an error similar to the one pictured to the right, make sure that you specified the correct grid account in the Credential select box of the Application Access Control interface.

Display existing security filters


The currently existing security filters can be displayed in the search results box located on the left side of the interface of the Instance Level tab. Click the Load button to display all security filters.

To view details related to a security filter, click on its name from the search results box to highlight it. The fields in the Security Filter Information box will be populated with data relevant to the selected security filter.

Notice in the screenshot that security filter is associated with the Participant Class Name and the Filter Chain is set up to only point to the Participant - self. The Target Class is specified as Participant - self and the Target Class Attribute is socialSecurityNumber.

Creating instance level security via domain model


To create a new security filter using a domain model, click the create via domain model button. This will launch the Domain Model File Browser interface. Enter the path to the domain model file in the Domain Model File field, or search for the file using the Browse button.

Notice in the screenshot that the domain model file specified is caTissue_Suite_1.1_DomainModel.xml. Next, click the Verify button to run a validity check on the file. If there are any problems with the domain model file, an error message will be displayed. If there are no problems, the Next button will be enabled and "Verified" will appear in the lower right hand corner of the interface.

Click the Next button to continue. This will launch the Instance Level Security interface. Select the class that should be associated with the filter using the Class Name select box. Selecting a class name will populate the filter chain select box located immediately below the Filter Chain box. Select a value from the filter chain select box and click the add filter button. This will add a filter chain entry in the Filter Chain box. Notice that the add filter button will now be disabled. If you wish to change your choice, you can click the remove last filter button to remove the filter chain entry added. This will re-enable the add filter button and a different selection can be made. The Target Class Attribute select box will be populated with the attributes associated with the class name if the filter chain specified as self. For example, in the screenshot the filter chain is ParticipantMedicalIdentifier - self so the Target Class Attribute select box will be populated. If I had chosen one of the other filter chain options such as site - Site, the attribute select box will be empty. You may only specify a Target Class Attribute for self filters. In this example, it is a self filter so I am able to choose medicalRecordNumber as the Target Class Attribute.

Lastly, it is possible to enter a Target Class Alias and Target Class Attribute Alias. Enter values for these input boxes and click the create button. The security filter will be created and the form fields will be cleared. You may create another security filter or close the Instance Level Security interface by clicking done. After the interface closes, click the load button in the Instance Level tab to display the newly created security filter.

It is also possible to create a security filter via application jars using the create via application jars button. However, this is beta functionality and may not work properly in the 1.3 release. If you experience issues creating a filter via application jars, you may need to try again in the future using the 1.3.1+ release.

Removing a security filter


To remove an existing filter, first display the filters by clicking the Load button in the bottom left hand corner of the interface. Click on the name of the filter to highlight it and right click on it to display the Remove Filter menu. Click Remove Filter to delete the security filter.

Use caution with this feature! Clicking Remove Filter does not prompt for confirmation and cannot be undone.
Last edited by
Keith Gasper (744 days ago)
Adaptavist Theme Builder Powered by Atlassian Confluence