Skip to content
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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
82 changes: 82 additions & 0 deletions docs/oathkeeper/pipeline/authn.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Copy link
Collaborator

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 :)

Copy link
Author

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


### `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.
Copy link
Collaborator

Choose a reason for hiding this comment

The 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.

Copy link
Author

@vladr11 vladr11 Jun 6, 2022

Choose a reason for hiding this comment

The 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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Makes sense to me

Copy link
Author

Choose a reason for hiding this comment

The 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.
```