This page last changed on Aug 10, 2011 by bbranan.

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 three DuraCloud web applications (/duradmin, /durastore, and /duraservice) 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]
    
      ###
      # require https for 'durastore' & 'duraservice' for external requests
      ###
    
      RewriteCond %{REQUEST_URI} ^(/durastore|/duraservice)
      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:

Store REST Methods
Action Role
Initialize Stores ROLE_ROOT
Initialize Security Users ROLE_ROOT
Get Stores ROLE_USER
Get Spaces ROLE_ANONYMOUS if space 'open', else ROLE_USER
Get Space ROLE_ANONYMOUS if space 'open', else ROLE_USER
Get Space Properties ROLE_ANONYMOUS if space 'open', else ROLE_USER
Create Space ROLE_USER
Set Space Properties ROLE_USER
Delete Space ROLE_USER
Get Content ROLE_ANONYMOUS if space 'open', else ROLE_USER
Get Content Properties ROLE_ANONYMOUS if space 'open', else ROLE_USER
Store Content ROLE_USER
Set Content Properties ROLE_USER
Delete Content ROLE_USER
Service REST Methods
Action Role
Initialize Services ROLE_ROOT
Initialize Security Users ROLE_ROOT
Get Services ROLE_USER
Get Service ROLE_USER
Get Deployed Service ROLE_USER
Get Deployed Service Properties ROLE_USER
Deploy Service ROLE_USER
Update Service Configuration ROLE_USER
UnDeploy Service ROLE_USER
Report UI REST Methods
Action Role
Initialize DuraReport Application ROLE_ROOT
Initialize Security Users ROLE_ROOT
Get Latest Storage Report ROLE_USER
Get Storage Report List ROLE_USER
Get Storage Report ROLE_USER
Get Storage Report Info ROLE_USER
Start Storage Report ROLE_USER
Cancel Storage Report ROLE_USER
Schedule Storage Report ROLE_USER
Cancel Storage Report Schedule ROLE_USER
Get Deployed Services Report ROLE_USER
Get Completed Services Report ROLE_USER
Get Completed Services Report List ROLE_USER
Get Services Report ROLE_USER
Administrative UI REST Methods
Action Role
Initialize DurAdmin Application ROLE_ROOT
Initialize Security Users ROLE_ROOT

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
    • owner 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.

Document generated by Confluence on Dec 14, 2011 18:53