Propagate auth headers to white-listed resources

[ikhomutov]

Summary

Right now if the user is accessing a white-listed resource, the authorization headers (neither Authorization nor X-Auth-Token) are forwarded to a upstream-url, which means that my backend is not aware if the user is authenticated or not. Previously there was an allow-anonymous attribute which did exactly what I need.
I could in theory use access token from cookies, but right now I have enable-encrypted-token parameter activated and I don't see easy ways to decrypt it.

Why?

In my case, I have a website that provides an additional functionality for registered users, while others still can access the website in a read-only mode. I manage permissions on a backend side and need GGK to only handle authentication flow with keycloak.

How

Probably it should be just like it was with allow-anonymous resource parameter

Acceptance criteria

If the user navigates to a resource that is marked as white-listed, the authorization headers propagated to an upstream-url server, just like they do on protected resources.

[p53]

Hi thank you for opening issue! Hmm a little bit contradictory requirements, you would like to not authenticate as you are setting white listed resource on the other hand you would like to decrypt token that means you assume bounding of token to gatekeeper but other people might not want to do that. Not sure about allow anonymous attribute as far as I remember there was not such flag but yeah i don't know all deep history of louketo but sounds to me like an alternative to white-listed not additional flag. Anyway in old versions of louketo there were also bugs and bad design decisions so I need to think about this of how to implement it in clean way.

[ikhomutov]

yes, looks like you're right and there were no such flag. probably we used a patched version of ggk in my previous project and added this flag manually for this exact case.
still, I think this would be a very useful flag that allows to specify resources where you not force user to be authenticated, but if they are - you want to know this as it will change the appearance of the website.

[p53]

@ikhomutov i was thinking about this, actually you are already doing some kind of authentication as you must use password to encrypt token on client side, can you explain a little bit more your setup, you have client which sends encrypted token for both read-only and write users, you want gatekeeper to decrypt it (in case of write user to do also other checks) in both cases and then backend decides if user should have read-only or write access, right? wouldn't be proper design to authenticate both users but they would have different groups? why you don't want to authenticate read-only user?