Separate security module for authentication in non-Diamond deployments

[mwinokan]

@alanbchristie please document/investigate the work required to separate the security module for authentication in non-Diamond deployments.

It is not a priority for the current releases so please spend up to 1 hour documenting this for now.

[alanbchristie]

The current Fragalysis contains modules in the api package (app) that handles communication with the MySQL/ISPyB database to collect the Target Access Strings (TAS) (Proposals/Visits) that a user has been granted access to - validating the user's access to a given Proposal/Visit.

The basic architecture is illustrated in this diagram: -

This has drawbacks: -

1. Every stack Pod (and a fragalysis deployment can contain more than one Pod) makes validation queries to the MySQL database. Deploy 6 developer stacks, a staging, and production stack and you have (at least) 8 Pods making regular requests to MySQL. Scale the production stack to 4 Pods and then you have 12 Pods making requests.
2. The validation code is written into the stack, and this makes it difficult to replace the TAS authentication with another type of authenticator - important for others who may want to install the stack and use their own security mechanism using custom logic or other in-house database (e.g. someone who does not use ISPyB).

Extracting the validation logic

We 'extract' the validation logic into a new 'separate' kubernetes deployment (a new Pod, and Service and Ingress): -

This validation logic architecture minimises MySQL connections and makes the security mechanism pluggable because: -

• can be shared across multiple stacks
• could be quickly replaced with an alternative validator (even one that produced 'canned' or fixed results for more reliable testing) but simply using a different 'endpoint'
• could have an 'ingress' (https endpoint) so that one service implementation could be used by both the Production and Development clusters

The security Pod would offer authorisation via a simple pre-shared key mechanism (passed in the request header). This is a common and safe approach and also avoids the security Pod from having to understand tokens or the authentication meachanism. Stacks are configured with some new ENV variables: -

• SECURITY_ENDPOINT (an https address)
• SECURITY_PROVIDER (a string used to provide a name of the service i.e. "ISPyB")
• SECURITY_KEY (a key required in the header of any security request)

They then send a request to the security Pod with a username (and key) and get back a list of TAS strings.

Other options

• The Stack's would still use their existing local 'cache' to help avoid potentially expensive and unnecessary external calls
• The security pod could also introduce a cache to minimise the number of ISPyB calls it makes