add keycloak integration

[stevenolen]

This issue is intended to track the integration/support of keycloak for identity management and authentication (a bit more abstractly, keycloak is implementing openid-connect,which is an identity service built on the oauth2 framework). Using a third-party, rather than implementing oauth2 or ldap/ad with ohmage, provides a great trade-off with flexibility: while another process must be managed, the process offers the ability to integrate with an enormous offering of identity backends.

Below are some (high level) implementation plans for discussion/first pass

server changes (implement as bearer only for ease of integration):

• offer keycloak_enabled: true/false from config/read api.
  • can we handle both local login and keycloak login simultaneously?
• add additional JWT authentication option to UserRequest class
  • on startup, import keycloak.json, namely the keycloak server pub key
  • verify the JWT signature using the keycloak pub key. perhaps using jjwt?
  • once verified, using content to update user's details/properties (too much overhead to do this on every request? if not, it provides most compatibility with existing SQL builder logic.)

client changes:

• ohmage.js
  • add keycloak.js dep, support keepalive/token refresh
  • if keycloak_enabled: true
  • don't store/send auth_token cookie/param.
  • don't store/send username param.
  • send Authorization header (rely on keycloak for refresh, and server to throw expiration errors.)
• cordova
  • Likely implement similarly to: https://github.com/keycloak/keycloak/tree/master/examples/cordova
  • investigate timeouts re: above, perhaps use offline_token if they do expire? this is a misuse of offline tokens though..

TODOs/Outstanding:

• user privileges: Given the above, enabling keycloak would force user privileges to be managed as roles in keycloak, and would break the functionality of user/update calls. Would need to implement the keycloak admin apis to propagate changes back to keycloak.
• class roles: keycloak would not manage user roles in a class, user would still need to be made restricted/privileged in a class using ohmage apis.
• using bearer-only for the server: this makes the clients a bit heavier, while drastically reducing logic on the server. A huge benefit since we need to preserve backwards compatibility on the server, and also because the javascript adapter for keycloak is quite functional and stable for our needs.

@hongsudt, could I bug you to run over this list with me to make sure I'm not missing anything?

[stevenolen]

884 #885 #886 all related to this issue.

[stevenolen]

884 mentions some current limitations of this implementation. I'll copy the outstanding ones here to continue to track:

• User info from keycloak is used on creation, but never updated after that.
• local_auth_enabled parameter is still function-less.