Wrong/Multiple Redirects

[diorcety]

In many example provided the configuration of oathkeeper is the following:

      config:
        to: http://127.0.0.1:4455/login
        when:
          -
            error:
              - unauthorized
              - forbidden
            request:
              header:
                accept:
                  - text/html

If I add return_to_query_param parameter and an authorizer (remote_json with keto), if the user is already logged but don't have the right to access to this ressource, it will be redirect to login (and worse with return_to_query_param, in redirect loop).

I'm missing something or there is a lacks in the redirect error, like multiple urls? How does it suppose to be handled in production environment?

[diorcety]

For who wants this feature, I made a quick and dirty improvement: diorcety@50643ff

Here an example

      errors:
        fallback:
          - redirect#unauthorized
          - redirect#forbidden
          - json
          - redirect
        handlers:
          json:
            enabled: true
            config:
              when:
                - request:
                    header:
                      accept:
                        - application/json
          redirect#unauthorized:
            enabled: true
            config:
              to: 'http://auth.test.fr/login'
              return_to_query_param: return_to
              when:
                - error:
                    - unauthorized
                  request:
                    header:
                      accept:
                        - text/*
          redirect#forbidden:
            enabled: true
            config:
              to: 'http://www.test.fr'
              when:
                - error:
                    - forbidden
                  request:
                    header:
                      accept:
                        - text/*
          redirect:
            enabled: true
            config:
              to: 'http://www.test.fr'

[AMarti96]

@diorcety I have been checking the changes you did and match with our current use case where we want to have multiple redirect URLs, as this is not supported by Oathkeeper. Is there any chance this gets suggested to the main oathkeeper project and eventually released?

[diorcety]

We can try to create an issue and a pull request associated. I was on the urge to make something work at the time(seems really a big lack for a production environment, even wondering how it supposed to be used in production without this feature).
Not sure about the difficulty to make this happen in the ory project leadership.
I'am in vacation currently. Feel free to start/lead.

[champ-devops]

I was struggling to determine why this was not already in Oathkeeper.

However after playing around with it and actually attempting to implement, it seems as if all one needs to do is check the session on the redirect landing page. If there is a session, then the only other reason they'd be here is because they're forbidden. If there is no session, then send them to the login page as there is no credential (unauthorized).

In other words, this solution while it does address the problem, may not be required with the above.

Super new here, but we've scoured the documentation and found nothing definitive on this. Thanks for any corrections / suggestions folks may have.

[mtillberg]

I disagree, I think Oathkeeper is just not currently well suited to having a browser be the client. It's important to allow some error codes through to browsers, caching servers, search bots, etc for proper handling. I understand your 401/403 scenario, but 404/500 from the upstream server should not be shown the same way as forbidden, and Oathkeeper can generate its own 404 errors when there are no matching rules.

First, Oathkeeper as-is can handle multiple redirects. The trick is to enable the redirect handler in the config, and then setup multiple instances of the redirect handler with different configs in the rules. config.yaml seems to be overridden with the rule-specific config, however I haven't checked to see if the when clauses are merged or overridden. In config.yaml:

 errors:
  handlers:
    redirect:
      enabled: true
      config:
        when:
          - request:
              header:
                accept: ["text/*"]
        to: http://my-api/error

Then in the rules.json:

  {
    "id": "asset-protected",
    ...
    "errors": [
      {
        "handler": "redirect",
        "config": {
          "when": [
            { "error": [ "unauthorized" ] }
          ]
        }
      },
      {
        "handler": "redirect",
        "config": {
          "when": [
            { "error": [ "forbidden" ] }
          ],
          "to": "http://my-api/forbidden"
        }
      }
    ]

Second, I think there needs to be more error handlers for browser accessed content. I could see:

passthrough: Simply pass the error response from the upstream server to the client. This would preserve the HTTP error code and content. This could be used for JSON/XML as well, rather than only allowing the Oathkeeper generated error payload.
static-page: Preserve the error code, but return static content from Oathkeeper itself. access_rules:repositories has the ability to specify files, inline, HTTP or S3 content, those could be used here to define the content location to be loaded at startup. static_page: config: content: file:///path/to/file.html

Finally, and this would be a bigger change, I think it would be better to create labelled handlers in the config that are referenced in the rules, rather then simply enabling and referencing types. Instead of

(mutators|errors|authenticators|authorizers):
  handler_type:
    enabled: true
    config: ...

it could be:

(mutators|errors|authenticators|authorizers):
  handler_label:
    type: handler_type
    config: ...

This way, the configuration can be centralized as much as possible in the main config, then the rules would reference the handler_labels and could make smaller tweaks/overrides as necessary. It's not far off from the type#label style from the post above.

[mtillberg]

Actually, I take some of this back. No matching handler is equivalent to passthrough, so putting necessary when clauses to limit responses will leave unmatched responses alone. I was getting tripped up on the examples. I still think serving a static error page (equivalent to Apache's ErrorDocument) would be useful.