Security

Security in XDAT is based on three aspects: Users, Roles, and Element Security settings.   Users represent individuals who have permission to access the data managed by XDAT and have abilities to perform certain actions in XDAT.  Roles are collections of Actions which can be performed in XDAT.  Element Security settings represent individual schema elements (root level data types) and governs how they are secured and what possible actions can be performed on them.  The exact structure of these elements is defined in the security schema (security.xsd).

Element Security Settings

In order for a element to be accessible in XDAT for browsing, searching, or securing it must have a defined xdat:ElementSecurity element.  This element has several attributes which govern how the element is secured.

Attribute Name	Purpose
secondary_password	Governs whether or not a user must supply a secondary password to access this data.
secure_ip	Governs whether or not a user can only access the data from a specific IP Address.
secure	Governs whether or not this element is secured. (If it is not secured, then it is accessible to any user).
browse	Governs whether or not this element is browseable (or searchable) for users.  (If yes then it will appear in search forms and browse listings)
sequence	Governs the order in which this element will appear in listings relative to other Elements.

In addition to defining these specific settings, the xdat:ElementSecurity also defines what key fields should be used to define access to the secured element (primary_security_fields) and what actions a user is allowed to perform on the secured element.
           
Primary Security Fields

Primary security fields define what the core fields in an element are which can be used to govern access to the element’s data.  For example, if I have an element called Experiment which has a field called Investigator which has a field called ID (Experiment.Investigator.ID), I can use that Investigator ID to govern who has access to the data based on the value of the ID.  Hence a site manager can define Experiment.Investigator.ID as a primary security field.  Then in a user’s element access settings the site manager can define the Investigator IDs which this user has access to.  For example, I could define that User1 has access to Experiments where the Experiment.Investigator.ID is 1, 2, or 5.  The User Element Access settings, allow the adiminstrator to give users permission to create, read, update, delete and activate data based on the primary security fields. 

If no primary security fields are defined in the Element Security Settings then all of the element’s data will be available to a user with basic access to the element (governed in the user’s element access settings).

Element Actions

The element actions defined in the xdat:element_security describe the actions which can be performed on this element.  They are used to create HTML Hyperlinks to link to features/actions for a given element (for example, in a report screen on the right in the actions box).  Element Actions have three properties: element_action_name (uniquely identifies the action and will be used in naming conventions), display_name (displayed text used in Hyperlinks), and sequence (governs the ordering of the actions in relation to other actions.  The created Hyperlinks will link to Velocity screens.  It will use the element_action_name to find the appropriate Velocity screen to link to.  First, it will look for a screen for that specific element action using a combination of the default text (XDATScreen_), the element_action_name, and the element’s sql name.  If that screen is not found, it will look for a generic screen using just the default text (XDATScreen_) and the element_action_name.  For example, for an action called ‘edit’ on an element with a sql name of xnat_experimentData, XDAT would look for a screen called XDATScreen_edit_xnat_experimentData.vm.  If this was not found, it would look for a Screen called XDATScreen_edit.vm.  If that is not found, it will throw an error, because every action must have a corresponding Velocity Screen.

The commonly used element actions are ‘xml’, ‘edit’, and ‘activate’.  These actions have some pre-set functionality within XDAT and should be used, if they are appropriate.

How do I allow an element to be viewed from the web?

In order for a Schema element to be viewed from the website (through Browsing and Searching), the element must have a xnat:element_security setup.  This xnat:element_security dictates the security features of the given schema element.  The element_security can be created from the Admin page using the ‘Data Types’ link (above the Data Types (Element Security) listing).

If the element_security’s ‘secure’ property is set to true, then each user will have to have defined permissions for that element in order to view it.

How do I secure access to data?

In order to secure access to a particular element’s data, the element_security’s ‘secure’ property must be set to true and primary security field(s) must be defined for the element.  This will allow user’s to have defined permissions for accessing the element.  The property and its primary security fields can be defined in the element_security’s edit page.

Users

Top

A User has assigned roles and defined element access settings.  The assigned roles reference defined Roles and govern what website-level actions a user can and cannot perform.  The element access settings reference defined Element Security settings and govern which elements a user can access, what security settings are particular to that access (secondary passwords or specific IP addresses) and what subset of the element’s data a user can access (permissions).  See Element Security Settings for more info.

Pre-Defined Roles

XNAT has several pre-defined roles which are used to manage basic security and site access.

• SiteUser: The SiteUser role is the most basic role.  It gives the user the options of searching data, browsing data, and changing passwords.
• Administrator:  The Administrator role allows a user to access the ‘Administration’ section of the website.  Only Administrators can edit user permissions.
• Bossman:  The Bossman is the only role which allows Administrators to approve user permission changes.
• DataManager:  The DataManager is preset to allow a user to add subjects or MR Sessions.

 

How do I add a User?

The easiest way to add a new user for XDAT is to access the administration features of the website.  Adding a user on the website consists of two steps; adding the user and setting up their permissions.

To add a user:

From the administration page, click the New User link (above the user listing). 

Add the basic user information.  Once this form has been submitted the user has been added.  However, this user will not have any abilities or permissions until the following step is performed.

To change the user’s permissions:

From the User report page, click the Change Permissions link.  The subsequent page allows you to select the website Roles which this user can have and define security permissions for any Elements which have defined primary security fields.  Once, the user’s permissions are stored, you will need to Reload the Element Security settings of the website (using the HTML link on the Admin page).

How do I govern the abilities of my users?

The abilities of a user can be closely managed through a combination of website Roles and element access permissions.  The administrator can define website roles or use preexisting ones to govern what actions a user can perform.  The element access permissions can be defined to govern which elements the user can access and what subsets of the data can be accessed.

Site Branding

Top

The main site logo is titled logo.jpg.  It is located in PROJECT_NAME/src/images.  It can be replaced with a customized logo (of the same name).  Or the direct image reference can be changed in the DefaultTop.vm and NoMenuTop.vm templates located in PROJECT_NAME/src/xdat-templates/navigations.

The site name is specified in the security data type.  It is an attribute of the xdat:security element called ‘system’.  It can be changed in the security.xml or directly in the database table xdat_security. 

Logging

Top

XNAT uses Apache Log4j to manage its application logging.  XNAT allows for two different logging specification sets (command prompt vs. web application).  The log4j settings are defined in the log4j.properties files located in deployments/PROJECT_NAME/ and deployments/PROJECT_NAME/conf.  The deployments/PROJECT_NAME/log4j.properties manages logging from the command prompt tools.  The deployments/PROJECT_NAME/conf/log4j.properties manages logging from the web application.

The setup script configures the deployments/PROJECT_NAME/log4j.properties file to create two logs (xdat.log & sql.log).  The xdat.log contains any system output from the XDAT processes.  Sql.log can contain all of the sql statements made from XDAT.  The specifications of how to create logs and manage the level of logging can be changed by changing the log4j file. 

The setup script configures the webapp logger (deployments/PROJECT_NAME/conf/log4j.properties) to produce the two standard logs (xdat.log & sql.log) and a third log (access.log).  The access log records every page that is visited by any user of the webapp.

For more information, consult the Log4j website.