-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Replace Keto Authorization with External HTTP Authorization #864
Conversation
437e872
to
83d3a65
Compare
String subject = getSubjectFromAuth(authentication, DEFAULT_SUBJECT_CLAIM); | ||
checkAccessRequest.setAction("ALL"); | ||
checkAccessRequest.setContext(context); | ||
checkAccessRequest.setResource(projectId); |
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.
we probably need to change this to include the resourcetype like org.feast.project:{projectId}
or something
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.
Oops, I fixed it but havent pushed yet.
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 had the do-not-merge on for protection ;)
But no worries, this at least allows your team to move ahead. I'll submit a patch tomorrow. I am going to bed now.
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dr3s, woop The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
/ok-to-test |
/ok-to-merge |
What this PR does / why we need it:
We need to extend Feast Auth towards Feast Serving, but pulling in more and more dependencies in Serving (and throughout Feast) is becoming a big pain. This PR replaces the existing Keto Authorization Provider with an HTTP Authorization Provider. It also comes with an Open API specification that users can implement as a web service in order to roll their own authorization layer.
Does this PR introduce a user-facing change?: