DuraCloud Security

Overview

The security approach is divided into two distinct spheres of responsibility

1. Channel security (encryption)
2. Application security (AuthN / AuthZ)

The configuration of any given user compute instance will consist of an Apache HttpServer layered on top of Tomcat.

1. Apache HttpServer
   • All requests will come through Apache on port 443 (https) of the instance
   • The requests will internally be unencrypted, where encryption exists, and redirected to tomcat as open text
2. Tomcat
   • A defined set of resource endpoints will require AuthN and AuthZ
   • Spring-security is being leveraged to wire AuthN and AuthZ across relevant resources

Channel Security Implementation

1. Apache HttpServer is configured to require all requests to the four DuraCloud web applications (/duradmin, /durastore, /duraservice, and /duraboss) go over https.
2. Below are the https enforcement rules configured in Apache

     ###
     # ensure 'duradmin' uses https
     ###
   
     RewriteCond %{REQUEST_URI} /duradmin
     RewriteCond %{SERVER_PORT} !^443$
     RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [R=301,L]
   
     ###
     # try to require https for 'durastore', 'duraservice', & 'duraboss' for
     # external requests
     ###
   
     RewriteCond %{REQUEST_URI} ^(/durastore|/duraservice|/duraboss)
     RewriteCond %{SERVER_PORT} !^443$
     RewriteCond %{SERVER_NAME} !^localhost$
     RewriteCond %{SERVER_NAME} !^127.0.0.1$
     RewriteCond %{REMOTE_HOST} !^127.0.0.1$
     RewriteCond ${local-ip-map:%{REMOTE_HOST}} !^localhost$
     RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [R=301,L]
   

Application Security Implementation

The basic AuthN flow is as follows

1. User requests secured resource
2. If credentials not in request
   • response 401
3. Spring AuthenticationProvider performs AuthN
   1. AuthProvider asks UserDetailsService for GrantedAuthorities for given Principal
   2. notes
      1. DuraCloud provides custom UserDetailsService implementation to return UserDetails of requesting Principal
      2. AbstractSecurityInterceptor permanently caches user AuthN decisions by default
4. Authentication object and "configuration attributes" are passed to AccessDecisionManager for AuthZ

Security Servlet Filters

DuraCloud leverages Spring's mechanism for wiring AuthN/Z into an application across servlet url patterns.
The following access rules are placed across the durastore and duraservice REST-APIs:

Roles

The fixed set of users/roles listed below are provided in DuraCloud. Each role in the list below represents a super set of the privileges of those above it.

1. ROLE_ANONYMOUS
   • no username/password
2. ROLE_USER
   • user created by DuraCloud-account admin
3. ROLE_ADMIN
   • administrator of DuraCloud-account
4. ROLE_SYSTEM
   • internal user for delegation requests
5. ROLE_ROOT
   • DuraSpace personnel

User Management

1. In order for the administrator of a DuraCloud account to manage new users, an initial user with ROLE_ADMIN privileges is provided at start-up:
   • username: admin
   • password: changeme

Note: Ultimately, the management of users will take place through the DuraCloud.org website (where users initially create accounts).
User management is exposed in Duradmin in the upper-righthand corner of the console, but the usernames/passwords edited here are not persisted.
This means that when the application is migrated to the next release, those details will need to be re-entered/re-created.