Add endpoint for answering access requests directly #42
Comments
|
Mind fleshing out some detail here? I'm not quite sure what you mean from just the title. |
|
The idea here is that we have an endpoint which is capable of answering requests based on the rules defined in oathkeeper, but without the proxy capability. So a bit like the warden endpoint + access rule :) |
|
@arekkas, this means it can be used with nginx auth_request module? |
|
Yes, looks like it would! |
|
Cool. That would be pretty awesome. |
|
Good discussion on this in the ambassador slack channel. I think their design approach is really good on this, see: https://www.getambassador.io/reference/services/auth-service edit// once done ping rdl/flynn and they might publish it as a blog post |
|
Was researching nice out of the box ways to integrate oauth with ambassador. Saw the slack channel discussion and sounds like this would go a long way of making it happen. Hoping this happens. |
|
It shouldn't be very hard to add this functionality as it's basically all here already, especially since we're answering those requests based on the HTTP protocol itself, which is what we're already doing for the proxy. What would change is obviously the response but that is not hard to deal with. There are still other issues that need to be addressed by our team first, but it's on the list! |
|
Awesome. Any order of magnitude time estimate on when this may happen. As in weeks, months, years? Thanks! |
|
Can't guarantee anything, definitely not years nor many months, maybe 4-8 weeks. |
|
Thanks. Just was looking for a rough estimate to decide if I can wait a bit for this. I'll keep an eye out for sure. |
This patch adds endpoint `/judge` to `oathkeeper serve api`. The `/judge` endpoint mimics the behavior of `oathkeeper serve proxy` but instead of forwarding the request to the upstream server, the endpoint answers directly with a HTTP response. The HTTP response returns status code 200 if the request should be allowed and any other status code (e.g. 401, 403) if not. Assuming you are making the following request: ``` PUT /judge/my-service/whatever HTTP/1.1 Host: oathkeeper-api:4456 User-Agent: curl/7.54.0 Authorization: bearer some-token Accept: */* Content-Type: application/json Content-Length: 0 ``` And you have a rule which allows token `some-bearer` to access `PUT /my-service/whatever` and you have a credentials issuer which does not modify the Authorization header, the response will be: ``` HTTP/1.1 200 OK Authorization: bearer-sometoken Content-Length: 0 Connection: Closed ``` If the rule denies the request, the response will be, for example: ``` HTTP/1.1 401 OK Content-Length: 0 Connection: Closed ``` Close #42 Signed-off-by: arekkas <[email protected]>
This patch adds endpoint `/judge` to `oathkeeper serve api`. The `/judge` endpoint mimics the behavior of `oathkeeper serve proxy` but instead of forwarding the request to the upstream server, the endpoint answers directly with a HTTP response. The HTTP response returns status code 200 if the request should be allowed and any other status code (e.g. 401, 403) if not. Assuming you are making the following request: ``` PUT /judge/my-service/whatever HTTP/1.1 Host: oathkeeper-api:4456 User-Agent: curl/7.54.0 Authorization: bearer some-token Accept: */* Content-Type: application/json Content-Length: 0 ``` And you have a rule which allows token `some-bearer` to access `PUT /my-service/whatever` and you have a credentials issuer which does not modify the Authorization header, the response will be: ``` HTTP/1.1 200 OK Authorization: bearer-sometoken Content-Length: 0 Connection: Closed ``` If the rule denies the request, the response will be, for example: ``` HTTP/1.1 401 OK Content-Length: 0 Connection: Closed ``` Close #42 Signed-off-by: arekkas <[email protected]>
No description provided.
The text was updated successfully, but these errors were encountered: