feat: Traefik decision api support #904
Conversation
…ernalServer errors on expectation failures
… the last commits
Codecov Report
@@ Coverage Diff @@
## master #904 +/- ##
==========================================
- Coverage 65.72% 64.60% -1.13%
==========================================
Files 104 103 -1
Lines 4633 4732 +99
==========================================
+ Hits 3045 3057 +12
- Misses 1314 1402 +88
+ Partials 274 273 -1
Continue to review full report at Codecov.
|
|
This PR would be a solution for the discussion #899 for the integration of Traefik and Oathkeeper |
… the decision api impl updated to cover the header use cases
…ide effect confusions
|
@aeneasr: In principle, this PR is complete. I also added traefik to the list of supported integrations. The documentation is however kind of thin. If there would be a section for integration examples, I would add some. I'm also not sure, where to put the information about how the url to be tested is created by oathkeeper (request url + header combinations) |
|
@aeneasr: I'm not sure, whether the new guide about integrating oathkeeper with traefik is properly referenced in the |
There was a problem hiding this comment.
Thank you! Great stuff :)
Regarding the docs, we are currently in the process of moving all the docs to github.com/ory/docs to resolve several major problems in the CI infrastructure. You can either keep them in this branch and I merge them into ory/docs once this is merged, or we make a PR against this PR ( ory/docs#557 ) in this directory: https://github.com/ory/docs/tree/next-generation/docs/oathkeeper
| @@ -42,7 +43,7 @@ func (v *VerifierDefault) Verify( | |||
|
|
|||
| kid, ok := token.Header["kid"].(string) | |||
| if !ok || kid == "" { | |||
| return nil, errors.WithStack(herodot.ErrInternalServerError.WithReason("The JSON Web Token must contain a kid header value but did not.")) | |||
| return nil, errors.WithStack(herodot.ErrBadRequest.WithReason("The JSON Web Token must contain a kid header value but did not.")) | |||
There was a problem hiding this comment.
Changing all of these is kind of a breaking change (although not an terrible one). Given that our service configuration returns something incorrect here, why would we report to the client calling this endpoint that it's a bad request?
There was a problem hiding this comment.
According to my understanding of the code, this is actually not about our service configuration, it is about the data sent by the client. If the client sent a malformed request (here the an access token not containing the expected data), it should imho be answered accordingly.
Another reason was logging. Internal server error is about unrecoverable errors, which imply some kind of a bug, which should be addressed. Here, we don't have things like this. So I wanted avoiding the be filled with error log statements, which are no errors.
Do you agree, or do you still want to have these changes reverted?
There was a problem hiding this comment.
I see, in case that we verify credentials, Unauthorized error would also be acceptable. What do you think?
There was a problem hiding this comment.
The main idea is not polluting the logs with error messages, which are actually not errors. I consider this as best practice.
Ah, if I remember correctly, to have the error handler working with traefik (to redirect to the login page), I had to change some of the responses to Unauthorized (which relate to authentication cases).
Back to your proposal. So you would rather like to see all changed responses to be Unauthorized? Fine for me ;)
There was a problem hiding this comment.
Please let me know if this is what you would like to have. I'll then update the PR accordingly.
|
Let's do a PR against the ory/docs PR. |
|
Ok :) The PR in ory/docs is merged so it can be straight against master! |
|
The last commit (see above) includes the merge with current master and removes the documentation. Latter is moved to the other PR (also referenced above) |
This PR contains the documentation for the updates done in ory/oathkeeper#904.
|
Hi there, forgive me if this sounds pushy (I'm at the edge of my seat for this functionality). As I don't know how your release schedules work, would someone be able to tell me when this will be available as a docker container for me to use? |
|
I just spotted the |
@aeneasr: This is the PR I was talking to you about yesterday
Related issue(s)
This PR focuses on the decision API only. So I don't know, whether other traefik specific use cases are supported.
There are a couple of discussions, issues and stale PRs related to this PR:
Checklist
Further Comments
Even there are a couple of ideas outlined in the referenced issues/PRs on how oathkeeper could be enhanced to have a more generic implementation to support different use cases (like other API gateways or proxies), this PR does not take them into account. Rather is focuses on Traefik support only. I'm convinced, it is however a good starting point to move forward and to resolve at least a couple of requests here at github, as well as at Slack. Further enhancements can then be done in further iterations. I also didn't want to touch any parts of the configuration, as we should first make use of the updated ory-x configuration capabilities.
Tests and documentation will be added as soon as we have a common understanding on how to proceed.
Beyond that, the given PR enables full support for the Traefik's ForwardAuth middleware.
Please note that this implementation does not differentiate between different strategies (where to get the information about the upstream service uri, host, scheme and method). If no
X-Forwarded-*header is set for a particular attribute, it is taken from the Request URL, otherwise the corresponding value from the header is taken. This way one can overwrite any, or none of the aforesaid attributes which is a non-breaking change to the current behavior.I have not implemented a separate decision end-point by intention, as it would uselessly blow the code base by mainly copying&pasting code (implementation & tests) and make the project less maintainable. I'm also not really sure, whether an introduction of different strategies makes sense. But if it is according to the community, I personally favor a strategy based approach (via configuration) much more (which depends on the new ory-x version), compared to specific endpoints.