Add remoteuser authenticator #1
Conversation
nbarrientos
force-pushed
the
issue84
branch
6 times, most recently
from
8b79cf8 to
f9af8d0
Compare
| // | ||
| // In the future, per-user ACLs/roles/etc could even be part of other | ||
| // headers. Alternatively, there could also be a local DB here (as in | ||
| // the userlist authenticator). Or a even a combination of both! |
There was a problem hiding this comment.
Do you think maybe we can just add a flag to the userlist one, something like a default username when none is given.
Setting that option would trigger the userlist one to accept a empty login and then look for this header, if the header is set it would use the default username to find a user definition and use that as a template.
That feels like less code and probably a bit easier to handle?
| @@ -312,6 +313,29 @@ Once you signed up for Okta and set up a application for Choria you'll get endpo | |||
|
|
|||
| Here we configure `acls` based on Okta groups - all users can `rpcutil ping`, there are Puppet admins with appropriate rights and fleet wide admins capable of managing anything. | |||
|
|
|||
| #### Login delegation via `X-Remote-User` | |||
|
|
|||
| It's possible to delegate the responsibility of verifying the users' identity to a front-end configured using the mechanism of your choice (Kerberos, OIDC, etc) and setting the identity of the caller in the `X-Remote-User` HTTP header. In this case, configure the `remoteuser` authenticator and make sure that the entrypoint `/login` is well protected. All users will receive the same ACLs et al, configured via `default_user`. | |||
There was a problem hiding this comment.
It's all users strictly getdefault_user or users without a definition get default_user ? A fall back user may be useful. e.g we might have use for handful of special users .
There was a problem hiding this comment.
|
Found an ancient comment I never submitted. @nbarrientos can you rebase so I can give this a spin. |
Done. |
See https://github.com/nbarrientos/aaasvc/blob/issue84/README.md#login-delegation-via-x-remote-user
For "internal" comsumption only (needs discussion upstream):
With config:
{ "logfile": "aaasvc.log", "loglevel": "info", "choria_config": "choria.conf", "authenticator": "remoteuser", "auditors": [ "logfile" ], "authorizer": "actionlist", "signer": "basicjwt", "port": 8080, "monitor_port": 8081, "site": "default", "tls_certificate": "", "tls_key": "", "tls_ca": "", "basicjwt_signer": { "signing_certificate": "signing_pub.pem", "max_validity": "24h" }, "logfile_auditor": { "logfile": "audit.log" }, "remoteuser_authenticator": { "signing_key": "signing_key.pem", "validity": "1h", "default_user": { "acls": [ "puppet.*" ], "properties": { "group": "admins" }, "organization": "cern" } } }To be discussed in choria-io#84. We need though something quick to unblock the testing/validation.