Authentication and Authorization

Owned by ScottS
Last updated: May 03, 2012 by muhammad siddique

OpenRegistry currently uses Spring Security to provide authentication and authorization capabilities. Out of the box, its configured to utilize the Jasig Central Authentication Service for authentication of the web UI and RESTful API. In both instances, a set of database users and associated roles are configured(schema for oracle database and sample dml is provided below). Sample authorization configuration for coarse grain access is provided using spring expression language SpEL. Fine grain access control can be implemented using spring security tag library and security trimming mechanism.

Location of Files

The authentication and authorization information is located in the OPEN_REGISTRY/WEB-INF/securityContext.xml file. Deployers who wish to completely swap the configuration may replace that file (or OVERLAY it if using the Maven2 WAR Overlay method).

Replacing Database Schema for Role Persistence

Spring Security's out of the box implementation "JdbcDaoImpl" of "UserDetailsService" is configured. "UserDetailsService" is what Spring Security utilizes to convert the provided authenticated username to a user that Spring Security understands. This is referenced by the  Bean Id: jdbcUserService

Current configuration utilizes the schema that is provided below , deployers who wish to use their own schema need to provide 'usersByUsernameQuery' and 'groupAuthoritiesByUsernameQuery' queries to jdbcUserService.

RESTful API Authentication

Open registry utilizes CAS for authenticating web UI users as well as REStful API clients. While WEB UI clients are directed to CAS loging page (standard CAS) ,RESTful api clients authentication happens in two phase.

  1. REST client first need  to get ticket from CAS server by providing username,password and the service url (essently service URL of open registry) either by invoking heavy weight SOAP service or REST call to CAS server.
  2. The client then need to pass username='cas_stateless' and password ='ticket got from CAS in step 1 to open registry.

Authorization on Service Layer

Security Trimming

Implementation of the Open registry may want to restrict the search results based on authorized principal's granted authority. This is must be done at service layer. Necessary configuration has been made in the security context to create spring security aop proxies to apply the pre/post filtration/authorization on the service layer. Security trimming is done by the following annotation in the default person service
@PostFilter("hasPermission(filterObject, 'read')")
Default Implementation of permission evaluation has been provided in the class org.openregistry.core.service.security.auth.DefaultPermissionEvaluator
That returns true i.e. doesn't apply security criteria on the service layer.

PreAuthorization

Implementation of the Open registry may want to restrict the adding of the person based on the authorized principal's granted authority and the data.Reauthorization on the service layer has been done using the following annotation
@PreAuthorize("hasPermission(#sorRole, 'admin')")
Default implementation that doesn't apply any pre authorization criteria has been provided in class PermissionEvaluator

Schema for Role Persistence 

Data model for authorization is now part of open registry core data model.