noop authenticator doesn't skip id_token mutator

[lcsanchez]

Describe the bug

Using the noop authenticator doesn't behave as describe by the authn pipeline docs.

The noop handler tells ORY Oathkeeper to bypass authentication, authorization, and mutation

When I make a request that matches the rule below, the id_token mutator being invoked and a JWT token with sub: "" is injected into the Authorization header.

Reproducing the bug

Steps to reproduce the behavior:

Server configuration

access_rules:
  repositories:
    - file://config/access-rules.json

authorizers:
  allow:
    enabled: true
  deny:
    enabled: true

authenticators:
  noop:
    enabled: true
  oauth2_introspection:
    enabled: true
    config:
      introspection_url: https://hydra-admin.local/oauth2/introspect

mutators:
  noop:
    enabled: true
  id_token:
    enabled: true
    config:
      issuer_url: http://oathkeeper.local/
      jwks_url: file://config/secret.jwks

[{
  ...
  "authenticators": [
    {
      "handler": "oauth2_introspection",
      "config": {
        "required_scope": []
      }
    },
    { 
      "handler": "noop" 
    }
  ],
  "authorizer": { "handler": "allow" },
  "mutators": [{ "handler": "id_token" }],
  "errors": [{ "handler": "json" }]
}]

Expected behavior

I would expect that when a request is made that matches the rule and no Authorization header is specified, the request is forwarded with no Authorization header value present.

Environment

• Version: v0.38.9-beta.1
• Environment: OS X, Docker

Additional context

I've been able to reproduce locally and debug the code a bit, here's what I found:

1. The request handler initializes the empty subject
2. noop authenticator is found and request gets flagged as being able to proceed (found = true).
3. id_token mutator gets invoked with the empty subject and the JWT gets assigned to the Authorization header.

Trying to get some clarification on whether the docs are simply out of date and the behavior was changed at some point. Or if this is a bug. Thanks!

[lcsanchez]

Happy to contribute a fix if I can get some guidance on what the actual behavior should be. Seems like pipeline docs do not match the current behavior.

[aeneasr]

Thank you! This is intended behaviour as the upstream service still needs to be able to verify the request. We should update the documentation here!

[github-actions]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan on resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneous you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

[mmellison]

We recently ran across this, and it's making migrating a legacy app to use Oathkeeper a bit complicated.

Our legacy system uses HTTP basic authentication which is validated using some custom business logic. We were looking to use Oathkeeper during a deprecation period where users could use their legacy credentials, or if they've updated to our new environment, they would use oauth2_introspection with an id_token mutator.

The problem is, even when we use a noop authenticator in order to pass through the legacy credentials, the id_token mutator clobbers the Authorization header with a "blank" token (empty string for "sub" claim).

Using this handler is basically an allow-all configuration. It makes sense when the upstream handles access control itself or doesn't need any type of access control.

Unfortunately, based on the docs we thought the noop authenticator was a true short-circuit, and now we're having to look into a much more complex solution (routing the request based on header to bypass Oathkeeper, for example).

[yunier-sc]

Same example here. My team had to implement risky solutions in Gloo routing just to accommodate the cases that could have been easily handled by having a fallback mechanism like noop. It is unclear why it was decided to change the behaviour in #97 and 6f8ab4f : No description, no comments, nothing.