Overview
The security approach is divided into two distinct spheres of responsibility
- Channel security (encryption)
- Application security (AuthN / AuthZ)
The configuration of any given user compute instance will consist of an Apache HttpServer layered on top of Tomcat.
- 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
- 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
- Apache HttpServer is configured to require all requests to the three DuraCloud web applications (/duradmin, /durastore, and /duraservice) go over https.
- 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
- User requests secured resource
- If credentials not in request
- response 401
- Spring AuthenticationProvider performs AuthN
- AuthProvider asks UserDetailsService for GrantedAuthorities for given Principal
- notes
- DuraCloud provides custom UserDetailsService implementation to return UserDetails of requesting Principal
- AbstractSecurityInterceptor permanently caches user AuthN decisions by default
- 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:
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 |
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 |
Action |
Role |
---|---|
Initialize DuraBoss Application |
ROLE_ROOT |
Initialize Security Users |
ROLE_ROOT |
Get Latest Storage Report |
ROLE_ADMIN |
Get Storage Report List |
ROLE_ADMIN |
Get Storage Report |
ROLE_ADMIN |
Get Storage Report Info |
ROLE_ADMIN |
Start Storage Report |
ROLE_ADMIN |
Cancel Storage Report |
ROLE_ADMIN |
Schedule Storage Report |
ROLE_ADMIN |
Cancel Storage Report Schedule |
ROLE_ADMIN |
Get Deployed Services Report |
ROLE_ADMIN |
Get Completed Services Report |
ROLE_ADMIN |
Get Completed Services Report List |
ROLE_ADMIN |
Get Services Report |
ROLE_ADMIN |
Get Executor Status |
ROLE_ADMIN |
Get Supported Executor Actions |
ROLE_ADMIN |
Perform an Executor Action |
ROLE_ADMIN |
Shutdown Executor |
ROLE_ADMIN |
Create Initial Audit Log |
ROLE_ADMIN |
Get Audit Logs |
ROLE_ADMIN |
Shutdown Auditor |
ROLE_ADMIN |
Get Content Manifest |
ROLE_ADMIN |
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.
- ROLE_ANONYMOUS
- no username/password
- ROLE_USER
- user created by DuraCloud-account admin
- ROLE_ADMIN
- administrator of DuraCloud-account
- ROLE_SYSTEM
- internal user for delegation requests
- ROLE_ROOT
- DuraSpace personnel
User Management
- 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.