Implementing An Extensible Role-Based Security Module in a Java Web Development Framework

Joe Hesse Technology Director, UCSF Memory and Aging Center

Dept. of NeurologyMemory and Aging Center

June 17, 2009

UCCSC 2009, June 17, 2009 2:45-3:45PM

Talk OverviewTalk Overview

• Framework security code that is reusable– Needs to work for different types of applications

– Present the core framework structures and how they have been extended to support our Clinical Research Data Management system.

• Authorization (not authentication)– What can the user do (not who the user is)

Our EnvironmentOur EnvironmentClinical research: neurodegeneration (Alzheimer’s)

– Multiple projects with different protocols that share the same participants

– Projects with multiple sites (across institutions)

– Multi-disciplinary approaches / assessments

• imaging, pathology, genetics, neurology, cognitive science

• Different data models and business workflow (e.g. clinical vs. laboratory)

– Requirement to integrate data

• Use central / common databases where possible

• Use common development platform

– Highly regulated environment for security and patient confidentiality (HIPAA, IRB/CHR)

Requirement 1: Restrict / Allow Access Requirement 1: Restrict / Allow Access to Application Functionalityto Application Functionality

• User requests to access and/or perform application functionality need to be validated against configurable “rights” assignments

• Initial Design Questions:

– How is application functionality structured

– How are users and user “rights” structured

– How are authorization checks performed

Application Functionality StructureApplication Functionality Structure

• Applications are composed of “actions”

• Actions are organized into meaningful “modules” and “sections”

• Each action has a specific workflow (e.g. entity CRUD flow: create, read, update, delete)

[Format] [instance].[scope].[module].[section].[target]

Patient lava.crms.people.patient.patient

Change Password

lava.core.home.prefs.changePassword

User List lava.core.admin.auth.authUsers

lava.crms.people.patient.patientlava.crms.people.patient.patient

lava.core.home.prefs.changePasswordlava.core.home.prefs.changePassword

lava.core.admin.auth.authUserslava.core.admin.auth.authUsers

Role Based Security ModelRole Based Security Model

• User is defined for each user of the system

• Users are assigned to one or more Groups

• Groups (or users) are assigned Roles

• Roles are assigned Permissions on Actions

ER Diagram - Role Based ER Diagram - Role Based Security ModelSecurity Model

Permission Assignment to RolesPermission Assignment to Roles

Authorization CheckingAuthorization Checking

• Every action request is checked for authorization by the controller layer

– Action type defines what requests are checked (e.g. view, edit, delete, add for entity actions).

– Simple refreshes of screens, filtering or paging of lists do not require authorization check.

• Results of the authorization checks are cached for quicker lookup on repeated actions

• Using a delegate pattern to abstract application specific authorization code from the core framework.

Authorization Check Sequence DiagramAuthorization Check Sequence Diagram

Authorization Cache Sequence DiagramAuthorization Cache Sequence Diagram

Authorization Check CodeAuthorization Check Code

Role Cache Initialization Psuedo-code:Role Cache Initialization Psuedo-code:

initialize(actions , permissions ){

rolePermissions = {re-group permissions by role}

defaultPermissions = {extract permissions for Default Role}

for each Action {

Events = { get authorization events for the action type}

for each event {

add key to cache for [action-event]

for each role {

record in cache whether role is authorized

for [action/event] Uses isPermitted() routine

}

}

}

isPermitted() algorithmisPermitted() algorithm

isPermitted(action, defaultPermissions, rolePermissions)

1) if any role permission denies the action then not permitted

2) if any role permission permits the action then

a) if the role permission is NOT “overridden” by a default denying permission then permitted.

3) if any default permission denies the action then not permitted.

4) if any default permission allows the action then permitted.

5) otherwise… not permitted.

Default deny override example…Default deny override example…

Requirement 2: Filter Data Access Requirement 2: Filter Data Access Based on needs of the Application Based on needs of the Application

• Restrict access to actions backed by entities that the user is not authorized to access

– Handles when user is authorized to access the action, but not the specific data requested at runtime

– e.g. opening the patient info screen for a patient the user is not authorized to view

• Restrict the data displayed on list screens

– Hibernate Filtering

– User is authorized to access the listing action, but only a subset of the data in the database.

Patient / Project AuthorizationPatient / Project Authorization

• Every patient record is associated with at least one project.

• Authorization structures extended to support assigning roles to users in the context of specific research projects

• Base Entity Java Interface/Class extended to support patient and project authorization

• Hibernate Persistence Layer filtering for project and patient access verification.

Patient - Project ER DiagramPatient - Project ER Diagram

CRMS Authorization ExtensionsCRMS Authorization Extensions

• CrmsAuthUserRole

– Added Project / Unit properties to model.

– Wildcards (“*”) allow role assignment to “all” projects

• CrmsAuthUser

– Added Project / Patient Access Lists (used by data filters) and properties

• CrmsAuthorizationDelegate

– Extends authorizationCheck() routine to make authorization check in the context of a specific project.

• CrmsAuthorizationContext

– Passed to authorization checks for crms actions

– wraps the project/unit properties used for auth checks

CRMS User Role AssignmentsCRMS User Role Assignments

Crms Entity ExtensionsCrms Entity Extensions

• All model objects in the framework implement the LavaEntity interface. Crms model objects are derived from the CrmsEntity base class:

– getPatientAuth() & getPatient()

• True if the the entity is associated with a specific patient

• If true, the entity must return the patient through getPatient()

• e.g. visit is for a single patient

– getProjectAuth() & getProject()

• True if the the entity is associated with a specific project

• If true, the entity must return the project through getProject()

• e.g. enrollment status record is for a specific project

CRMS Auth Checking CodeCRMS Auth Checking Code

Data Filtering: Hibernate FiltersData Filtering: Hibernate Filters

• Hibernate persistence layer “writes” all the SQL based on mapping files that link tables and columns to classes and attributes.

• Hibernate has a filter mechanism that allows the developer to write a piece of SQL that gets added to the where clause when enabled

• Filter can be turned on/off and parameterized programmatically

CRMS Filter DefinitionsCRMS Filter Definitions<filter-def name="projectAuth">

<filter-param name="projectList” type="string"/>

Project in (Select Project from ProjectUnit Where Project in (:projectList))

</filter-def>

<filter-def name="patientAuth">

<filter-param name="projectList" type="string"/>

PIDN in (select PIDN from EnrollmentStatus where Project in (:projectList))

</filter-def>

Hibernate Query CodeHibernate Query Code

CrmsAuthUser Filters CodeCrmsAuthUser Filters Code