Update Keycloak backend

[jemrobinson]

• Improves documentation about how to use Keycloak
• Drops the suggested method of adding a client-scoped mapper to expose a hardcoded domain as this was not working in some cases for an unknown reason
• Move OAuthDataMapper to once-per-server to simplify various nested constructors
• Adds a --disable-user-domain-verification flag for cases where domain validation is not wanted
• Enables --keycloak-domain-attribute to be set from Docker

Closes #54. Closes #55.

[jemrobinson]

@seang96: I think this will solve your problem. You can either set the correct Keycloak domain attribute to whatever your hardcoded attribute name is (using KEYCLOAK_DOMAIN_ATTRIBUTE in Docker or --keycloak-domain-attribute at the command line) or you can ignore domain verification (using DISABLE_USER_DOMAIN_VERIFICATION in Docker or --disable-user-domain-verification at the command line).

If you think this is sufficient, I'll merge this PR into main so you can test the Dockerised version.

[seang96]

I don't really need the domain validation so I can test both out. If you publish an image with the PR I could test before you merge.

[jemrobinson]

Thanks! Can you try with docker pull ghcr.io/alan-turing-institute/apricot:54-fix-keycloak-backend?

[seang96]

#55 appears good to close with this update!

#54 I can still reproduce the original issue. I am thinking it may be a client side timeout when getting initial access token on first request, if it fails it fails to build the LDAP structure and queries always fail. I'll look into what causes this some more to confirm my theory though.

[jemrobinson]

Thanks @seang96. It's definitely possible for either of

1. Apricot to make a request to Keycloak before Keycloak is initialised
2. A user to make a request to Apricot before Apricot is initialised

Do you think one of these is happening in your case?