-
-
Notifications
You must be signed in to change notification settings - Fork 381
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
add documentation for remote_json authenticator #827
base: master
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -915,3 +915,85 @@ The request has been allowed! The subject is: "peter" | |
|
||
In the background, this handler will fetch all JSON Web Key Sets provided by configuration key `authenticators.jwt.jwks_urls` and | ||
use those keys to verify the signature. If the signature can't be verified by any of those keys, the JWT is considered invalid. | ||
|
||
## `remote_json` | ||
|
||
The `remote_json` authenticator will forward the HTTP request (method, path, headers and body) to an upstream service. If the service returns `200 OK` and body `{ "subject": "...", "extra": {} }`, then the authenticator will set the subject appropriately. | ||
|
||
### `remote_json` Configuration | ||
|
||
- `service_url` (string, required) - The service to forward request method/path/headers/body to for authentication. | ||
- `preserve_path` (boolean, optional - defaults to `false`) - If set to `true`, any path in `service_url` will be preserved instead of replacing the path with the path of the request being checked. | ||
- `extra_from` (string, optional - defaults to `extra`) - A [GJSON Path](https://github.com/tidwall/gjson/blob/master/SYNTAX.md) pointing to the `extra` field. This defaults to `extra`, but it could also be `@this` (for the root element), `session.foo.bar` for `{ "subject": "...", "session": { "foo": {"bar": "whatever"} } }`, and so on. | ||
- `subject_from` (string, optional - defaults to `subject`) - A [GJSON Path](https://github.com/tidwall/gjson/blob/master/SYNTAX.md) pointing to the `subject` field. This defaults to `subject`. Example: `identity.id` for `{ "identity": { "id": "1234" } }`. | ||
- `method` (string, optional) - The method to pass to the authenticator service. If set, the method of the original request is overwritten with the specified method. If not set, the method of the original request is used. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Open question : does it make sense to use the original request method as a fallback instead of the default method set to POST? For example, let's say we do a DELETE request and have set this authentication in our rule but haven't overridden the config method propoperty. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think it makes sense because it would be the only way to pass the original method. Now it is true that usually an authentication server does not perform the authentication based on the request method, but I believe that it would be useful to cover such a case as well. Another possibility would be to make the default behaviour to send a POST request to the authn server if no method is specified, and have another config flag that enables the users to simply forward the original method as well, which by default is disabled, so one needs to explicitly enable the current behaviour which preserves the method. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Makes sense to me There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Changed the behaviour of the authenticator and updated the docs |
||
|
||
```yaml | ||
# Global configuration file oathkeeper.yml | ||
authenticators: | ||
cookie_session: | ||
aeneasr marked this conversation as resolved.
Show resolved
Hide resolved
|
||
# Set enabled to true if authenticator should be neabled and false to disable the authenticator. Defaults to false. | ||
enabled: true | ||
|
||
config: | ||
service_url: https://auth-service-host | ||
``` | ||
|
||
```yaml | ||
# Some Access Rule: access-rule-1.yml | ||
id: access-rule-1 | ||
# match: ... | ||
# upstream: ... | ||
authenticators: | ||
- handler: remote_json | ||
config: | ||
service_url: https://auth-service-host | ||
preserve_path: false | ||
``` | ||
|
||
```yaml | ||
# Some Access Rule Using A Custom Method: access-rule-2.yml | ||
id: access-rule-2 | ||
# match: ... | ||
# upstream: ... | ||
authenticators: | ||
- handler: remote_json | ||
config: | ||
service_url: https://auth-service-host | ||
preserve_path: true | ||
method: "POST" | ||
``` | ||
|
||
### `remote_json` Access Rule Example | ||
|
||
```shell | ||
cat ./rules.json | ||
|
||
[{ | ||
"id": "some-id", | ||
"upstream": { | ||
"url": "http://my-backend-service" | ||
}, | ||
"match": { | ||
"url": "http://my-app/some-route", | ||
"methods": [ | ||
"GET" | ||
] | ||
}, | ||
"authenticators": [{ | ||
"handler": "remote_json" | ||
}], | ||
"authorizer": { "handler": "allow" }, | ||
"mutators": [{ "handler": "noop" }] | ||
}] | ||
|
||
curl -X GET -H "token: my-token" -d '{ "some": "body" }' http://my-app/some-route | ||
|
||
HTTP/1.0 200 OK | ||
The request has been allowed! The subject is: "peter" | ||
|
||
curl -X GET -H "token: invalid" -d '{ "some": "body" }' http://my-app/some-route | ||
|
||
HTTP/1.0 401 Status Unauthorized | ||
The request isn't authorized because the provided credentials are invalid. | ||
``` |
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.
Could you extend a bit the description to point out that it aims to send both request body & headers? At least this is how I understood from the root issue description and would be nice to give here also a small note about the difference to
bearer_token
authenticator which you have pointed in the issue comment :)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.
Added a note to point out the difference between the
remote_json
&bearer_token
authenticators