Security - WormBase/db-prototypes GitHub Wiki
The pseudoace security model is a work in progress. Incomplete bits should be noted below.
The current code exports an HTTP interface which is used both directly by curators, and by scripts. The security model is intended to meet the needs of both. One complication is that, being an HTTP-based service, we need to protect the sessions of web-based users from Cross-site request forgery attacks. However, we don't want to impose unnecessary complications on script-ish clients.
To work around this, we segregate client types by authentication mechanism:
- Web-based users are expected to authenticate with OAuth2 (currently using Google as the provider since this allows us to use wormbase.org accounts -- switching to another provider would be easy, though).
- Scripts are expected to authenticate with HTTPS client certificates.
The expectation is that all traffic should be encrypted (HTTPS), although this isn't currently enforced (change this once we have properly-signed SSL certificates).
Implementation
The authentication system is implemented with friend and friend-oauth2. There is a custom friend workflow in the web.ssl namespace for authentication using SSL client certs.
web.anti-forgery contains a slightly-modified version of the standard ring-anti-forgery middleware, which trusts any request that is accompanied by a client certificate.
It should be possible to add additional friend authentication workflows to the stack in the usual manner, but remember to consider interactions with the anti-CSRF layer.
Database support
Users are identified by entities in the main database (would be reasonably straightforward to switch to using a secondary DB for users if required). The following attributes are allowed.
:user/name (string) ;; Human-readable name token for user/password login systems
:user/email (string) ;; E-mail address for OAuth2-based login
:user/x500-cn (string) ;; CN of an SSL client certificate than can be used for login
:user/bcrypt-passwd (string) ;; bcrypt-encoded password (deprecated)
:user/wbperson (ref) ;; reference to a Person entity
The :user/wbperson attribute is currently also treated as a "this user has curation rights".
See also User account management.
Roles (TBD???)
Friend supports roles. These could be stored in the database in the same was they were for namedb, but currently aren't used in the main curation system.
Creating certificates
TODO: Running on privileged ports.
At some point, it would be nice to run the system on port 443 to get non-horrible URLs (also, not 100% sure signed certificates for HTTPS on non-standard ports will work properly). At this point, just using an in-process Jetty HTTP/HTTPS connector might not cut it any more. We almost certainly don't want to go down the path of having the TrACe backend process running as root!
Options look like:
Use a front end server (Apache httpd? nginx?) to terminate the public connections, forward requests to a TrACe HTTP server running on a private port.
This means that Apache would be checking the client certificates (and certifificates would have to be stored somewhere Apache can see them!). We'd need to pass certificate validation and distinguished-name information to the backend in headers. Apache config to do this is here. We'd also need some support in the backend (probably some simple ring middleware) to retrieve the SSL data from the headers.
mod_jk
There's a dedicated protocol (AJP) for communication between a front end server (usually Apache) and the Tomcat servlet container. This has some dedicated mechanisms for forwarding SSL information, so might be neater than using HTTP. But don't have any direct experience (and would require using Tomcat rather than Jetty).
Port forwarding
This might be the simplest option, if there aren't any administrative objections.
Just use iptables to route port 443 and 80 traffic to high-numbered ports Jetty docs. In this case, we can go on using Jetty to terminate the SSL connections, so no further complications.