Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Composite configurable mutator cache key per rule. #885
base: master
Are you sure you want to change the base?
feat: Composite configurable mutator cache key per rule. #885
Changes from 10 commits
5c1e99d
e025ce4
71a9fe5
882ce57
50872af
77a476b
6210b6b
875f8ea
7ccdffa
0607a61
601dd25
9d02d9e
43dd077
7600bf8
a42d632
de55e3a
881642d
8048c09
0599bfb
7cc9f4f
b58dbd5
5130d4e
1065975
4ab1904
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Key is a composite key based on configuration property + three distinct repeatable properties (URL for
hydrator
,rule id
andsubject
of session).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not sure if that is enough! What about extra properties of the session, such as e.g. "scope" or "permissions"? These could all influence the hydrator response and could lead to eventual security vulnerabilities down the road. I think we need to take the full session in a serialized form if we want to be sure that the cache can actually be reused!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If using complete
AuthenticationSession
one is not benefiting given the volatiltity of this structure - usingsubject
,rule id
,hydrator URL
as part of the composition is enabling flexibility while ensuring a certain level of constraint. The user is also free given flexibility to set a key which can include all of the above (i.e. JWT-claims) using templating.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. I am unsure though wether I can agree here. I think it points to a deeper issue though which is manifesting in this pr: It is not possible to define the cache key reliably. Actually, one would probably like to define the cache key themselves (e.g. subject + scope) to make the system more efficient. For example, the AuthSession might contain vital info such as a "permissions" array. Yet, it may also contain a counter or timestamp which is changing for most of the requests - invalidating the cache if included.
We are still not there yet with a new concept for Ory Oathkeeper, but I think this is a very interesting problem that could very well warrant a realignment on Ory Oathkeeper which would be to make access control at the reverse proxy as efficient and flexible as possible.
I think this too could benefit from JsonNet, as JsonNet is typable, lintable, and can produce errors (go templating fulfills none of these properties).
Unfortunately, for this PR in particular, I don't think the current implementation can be accepted because it still bears too many risks and this particular type of issue has already caused a CVE in Ory Oathkeeper which is why I am so hyper-sensible about this topic: GHSA-qvp4-rpmr-xwrr
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you. Let us inverse the solution. If you feel a user can't define a cache key freely (given cause of concerns as mentioned) - what about allowing the user to define exclusion of request/response
headers
(I also believe I saw an issue regarding this)? If the wholeAuthenticationSession
is used as a cache keyheaders
represents a volatile part (i.e. subject to middleware enrichment which is hard to predict and control).extra
is defined as part of previous steps in the pipeline and can be more controlled. What is your thoughts?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a brilliant idea! Exclusion is much safer (because explicit) :)