Support context field in the authorizer handler

[msimonelli331]

Keto supports conditions in their policy engine. To check against these conditions you need to send a payload with the "context" key. Oathkeeper should be able to build the payload with the context key, not just action, resource, and subject.

[iAziz786]

I'm happy to pick this up.

[aeneasr]

Nice, I think you can take a look at e.g. the remote json thing to figure this out for keto :)

[iAziz786]

Yes, I'm working on that. I have a few queries. Can you please elaborate on why are we returning only remoteIpAddress alongside requestedAt at the line below?

oathkeeper/pipeline/authz/keto_engine_acp_ory.go

Line 81 in 2734906

return map[string]interface{}{

[aeneasr]

The code is pretty old - I was also thinking that we could probably use the remote json authorizer to talk to keto and don't need the keto authorizer at all any more.

[iAziz786]

Okay, so for the entire Keto support we will be relying on remote JSON?

Do we need it to delegate through code or should we mention that in the docs?

[aeneasr]

Yeah I think so! It can do everything the keto authorizer can do as well but is more flexible. This definitely would need to be updated in the docs. I also want to switch to JsonNet #423 to make this easier.

[iAziz786]

Yeah, that's reasonable. Should we start working on that instead and once that's finished then working on this would be seamless?

Digging under I found that there is an already Golang implementation for that by Google. Have we considered using JSONnet in any other Ory projects before?

[aeneasr]

Yeah, that's reasonable. Should we start working on that instead and once that's finished then working on this would be seamless?

Yes I think that makes sense. We would however first need to figure out how to ensure backwards compatibility with existing rules. I have some ideas, but currently no time to work on it. Maybe we document remote_json with current go templates first for keto?

[iAziz786]

Just saw #441 and I think is really a great idea to first clear things and then after start working. I think we can wait once RFC is finalized. What do you think?

[aeneasr]

SGTM

[github-actions]

I am marking this issue as stale as it has not received any engagement from the community or maintainers in over half a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• open a new issue with updated details and a plan on resolving the issue.

We are cleaning up issues every now and then, primarily to keep the 4000+ issues in our backlog in check and to prevent maintainer burnout. Burnout in open source maintainership is a widespread and serious issue. It can lead to severe personal and health issues as well as enabling catastrophic attack vectors.

Thank you for your understanding and to anyone who participated in the issue! 🙏✌️

If you feel strongly about this issues and have ideas on resolving it, please comment. Otherwise it will be closed in 30 days!