add login for AAR

[thoobr]

adding a login for the AAR to only be opened by dedicated users.

[thoobr]

A new endpoint was added:
/AARService/checkCredentials
requestparameters:
username
password

[croser]

needs more clarification: sso vs basic auth vs client-in-memory-auth-status?

[cdanger]

Having a web SSO (OpenID Connect) on the testbed would be better overall, because we need that too for the Trial Management Tool and Admin Tool. See my answer to a similar issue here:
DRIVER-EU/scenario-manager#2

In short, TNO or I can setup a Keycloak web authentication/SSO server as part of the testbed, or on some public TNO VM, for the central auth service. This is free and open source stuff so you can have it locally for your own tests as well.

Then make sure your webapp works properly behind a reverse proxy like Apache/Traefik (see issue on SSL reverse proxy support). Then the SSO authentication is done in the reverse proxy and your webapp gets all needed auth info via HTTP headers, also called pre-authentication mode in some web frameworks. If this doesn't work (worst case scenario), you may have to support OpenID Connect in your webapp.

[erikvullings]

For those interested, here is a simple article on Keycloak for web apps.

[cdanger]

The approach in the article requires to modify the webapp to support OIDC (via Keycloak Javascript adapter in this case), therefore puts responsibility on the webapp developer to implement security right,; also does not explain how SSL is handled to secure access to the webapp (only to the Keycloak server), although it is critical to protect exchanged tokens.

Best practice, esp. for DRIVER+ testbed, since we will and should use a reverse proxy for SSL, is to handle the OIDC authentication in the proxy as well, e.g. Apache + mod_auth_oidc (+mod_ssl for SSL), as mentioned in Keycloak doc. (Don't look at Keycloak Gatekeeper, this is not mature.) This way the security layer can be externalized outside the webapps - less effort and responsibility on webapp developers - and handled uniformly/consistently by the testbed staff. Webapp developers then need only to get the proper HTTP headers (and make sure their webapp works behind a proxy which is a must-have anyway if we want to use HTTPS everywhere).