Skip to content
This repository has been archived by the owner on Dec 7, 2020. It is now read-only.

Evaluating headers against access token #688

Open
SBlechmann opened this issue Oct 13, 2020 · 0 comments
Open

Evaluating headers against access token #688

SBlechmann opened this issue Oct 13, 2020 · 0 comments

Comments

@SBlechmann
Copy link

SBlechmann commented Oct 13, 2020

Title

Evaluating headers against access token

Summary

I'm aware of the EOL, which I find very sad, btw. Anyway, I wanted to ask for opinions and help on this - maybe from the community. I am also facing issues while trying to migrate to oauth2-proxy with keycloak.. this is why I'm still writing this issue for the good working louketo.

So I am using the OS FIWARE architecture (e.g. Orion context broker, mongodb, IoT Agents, etc.) and FIWARE uses headers for multi-tenancy. These headers are called "fiware-service" and "fiware-servicepath". I am thinking about using this multi-tenancy for a single company, let's say, with different departments and each department has its own fiware-servicepath.
For different companies where data should be seperated physically of course different deployments with different sub-domains should be used.

Of course not every user may send requests to every servicepath and I was thinking about adding the allowed service and servicepath as an attribute to a group or a user and include this in the access token via a scope.

But I could not find an existing way for louketo to evalulate the requested headers with the allowed headers included in the access token.
Does anyone have any idea how to solve this? Or is there any other way?

How

Check the keypair "fiware-service: XYZ" from the access token against the request headers sent by the user / application / client.

Additional Information

Right now I am using traefik as a reverse proxy. Behind this I got different instances of louketo as PEP for different services / APIs from FIWARE. I use keycloak as IDM.

Thanks for the opportunity to share my thoughts :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant