Header Authentification #724
Comments
|
This is exactly what I was looking for, but we might not have to explicitly set the |
|
Hi @tchiotludo , hope you are doing well, any ETA when this can be implemented ? Thank you. |
|
hi @skaravad, It's done on the |
|
Shouldn't this be (optionally?) secured by an IP whitelist, so that people won't be able to go around auth proxy even when application listens on public port? |
|
This can be done easily I think @piotrp, a PR will be welcome 👍 |
|
I think I have some time, will check. Should I create issue for this or just submit PR? |
|
maybe create the issue for the memory 👍 |
|
@piotrp @tchiotludo thank you for the feature, really appreciate it. I'm about to try the dev build , just need some help with the config, as per the documentation Do we need to specify the users who are allowed to login ? in the sense lets say we have 4 admin users and 20 developers , so we need to pre-populate them under Not sure if this is the case, but if so, then then authentication is not dynamic via header, from my understanding if a user-header is being sent to akhq, then the user is already trusted (even in the case of IP address, it is the responsibility of the admin to control access to the proxy at proxy level vs akhq to check for the IP), when it comes to authorization, like admin or reader the group should be the one controlling it. |
|
I could make an optional |
|
Yes, that makes it more dynamic, just like other dynamic auth mechanism like LDAP , all we need to know is which group the user belongs to and then apply the group permissions. |
|
@skaravad it's done, can you try please ? |
|
@tchiotludo thank you, will test it in a bit. |
|
@tchiotludo @piotrp , it is working as expected, thank you so much. On a side note, I don't think the error log below is related to this change, but here is something I see if this is not related to the auth changes, then this issue can be marked as closed, will wait for the official release. |
|
One minor issue, though I does not bother me much, on logout we get redirected to |
|
maybe a better option is to disable completely logout button with auth header, it doesn't make sense no ? |
|
That works too, or on logout redirect them to base-path (I handled it at the haproxy level with this re-direct condition to mimic other apps like grafana / jenkins which support header auth) What you suggested makes perfect sense with no logout button. Here is what I did on haproxy side. |
|
@tchiotludo current version fails when it's run using configuration that doesn't define header authentication data. I get an exception: First line is from additional logging I added to What's the desired behavior? Should there be a null check there (I can add it in PR I'm preparing) or should |
|
While we're still on topic: would it be ok to add group mappings, so that header auth would get feature parity with LDAP and OIDC providers? |
|
I meant this group mapping, eg. for LDAP you can use: And it would make sense if header authentication could also perform similar mapping. |
|
ok got it map custom group from headers with local ahhq group, make sense |
|
PR: #794 |
|
@tchiotludo @piotrp in the latest dev the header auth is broken, not sure what could be the reason, the user-header is not being picked up and the user defaults to Anonymous |
|
I have a working configuration with current dev branch (from 9th September, so without last commit). Can you enable debug logging for Have you tried issuing manual HTTP request with |
|
hi @piotrp @tchiotludo , thank you for quick response, it appears that I had a cached copy of dev image, it is working now, however post login , in the UI there is no user info (in the top right corner), not sure if this is expected. here is the log On a side note, if the log can also print the group header , that can be really useful for debugging. |
Allow to use Header coming reverse proxy to auth user.
maybe like that :
The text was updated successfully, but these errors were encountered: