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 DuraCloud web applications go over https.
Below are the https enforcement rules configured in Apache. The X-Forwarded-Proto header is provided by AWS Elastic Load Balancers.
RewriteEngine On RewriteCond %{HTTP:X-Forwarded-Proto} !https RewriteRule !/status https://%{SERVER_NAME}%{REQUEST_URI} [L,R]
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 |
---|---|
Get Stores | ROLE_USER |
Get Spaces | ROLE_ANONYMOUS if space ACL allows public read, else ROLE_USER |
Get Space | ROLE_ANONYMOUS if space ACL allows public read, else ROLE_USER |
Get Space Properties | ROLE_ANONYMOUS if space ACL allows public read, else ROLE_USER |
Get Space ACLs | ROLE_ANONYMOUS if space ACL allows public read, else ROLE_USER |
Create Space | ROLE_ADMIN |
Set Space Properties | ROLE_USER |
Set Space ACLs | ROLE_ADMIN |
Delete Space | ROLE_ADMIN |
Get Content | ROLE_ANONYMOUS if space ACL allows public read, else ROLE_USER |
Get Content Properties | ROLE_ANONYMOUS if space ACL allows public read, else ROLE_USER |
Store Content | ROLE_USER |
Copy Content | ROLE_USER |
Set Content Properties | ROLE_USER |
Delete Content | ROLE_USER |
Get Tasks | ROLE_ADMIN |
Perform Task | ROLE_ADMIN |
Perform Task (restore-content) | 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_ROOT
- DuraSpace personnel
User Management and Access Control
- Users are managed via the DuraCloud Management Console. In the Management Console, an account administrator has the ability to:
- Add and remove users to the DuraCloud account
- Create Groups and add users to groups in order to simplify access control
- Access Control is managed at the space level
- Within DuraCloud (via the UI or the REST API), an account administrator has the ability to define which users and groups have access to a space, as well as the type of access (read or write) that is available.