1. Implementing An Extensible Role-Based Security Module in a Java Web Development Framework Joe Hesse Technology Director, UCSF Memory and Aging Center Dept. of Neurology Memory and Aging Center June 17, 2009 UCCSC 2009, June 17, 2009 2:45-3:45PM

2. Talk 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)

3. Our Environment Clinical 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)

4. Requirement 1: Restrict / Allow Access to 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

5. Application 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] Patientlava.crms.people.patient.patient Change Password lava.core.home.prefs.changePassword User Listlava.core.admin.auth.authUsers

6. lava.crms.people.patient.patient

7. lava.core.home.prefs.changePassword

8. lava.core.admin.auth.authUsers

9. Role 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

10. ER Diagram - Role Based Security Model

11. Permission Assignment to Roles

12. Authorization 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.

13. Authorization Check Sequence Diagram

14. Authorization Cache Sequence Diagram

15. Authorization Check Code

16. 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 }

17. isPermitted() 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.

18. Default deny override example…

19. Requirement 2: Filter Data Access 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.

20. Patient / 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.

21. Patient - Project ER Diagram

22. CRMS 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

23. CRMS User Role Assignments

24. Crms 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

25. CRMS Auth Checking Code

26. Data 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

27. CRMS Filter Definitions Project in (Select Project from ProjectUnit Where Project in (:projectList)) PIDN in (select PIDN from EnrollmentStatus where Project in (:projectList))

28. Hibernate Query Code

29. CrmsAuthUser Filters Code