https://www.ory.sh/ logo
Join Slack
Powered by
hello all, a (hopefully) quick question about muta...
# talk-oathkeeper
n
hello all, a (hopefully) quick question about mutators: we are putting oathkeeper in front of our graphql API with some operations unauthenticated. it’s easy enough to put the anonymous authenticator to allow those operations through oathkeeper, but we want to mutate auth’d operations using the id_token mutator. is it possible to skip the mutator in the anonymous cases to leave the Authorization header empty? so far if it is i haven’t been able to find that option
also tried creating two different rule chains, one for anon and one for auth’d, but that doesn’t work since the match rules would be the same in both
i can easily enough handle that at the application level with a standardized subject for anonymous users (probably just keeping the default from oathkeeper), but curious if there were a way to keep it as-is since the empty header is currently how our applications determine an anonymous user
c
Why not just two instances of oathkeeper?
n
that’s one option, though that seems like way too much management (even if infrastructure is automated) for a workaround of a relatively simple thing, just handling a hard-coded anonymous user is better in our case, especially since we can easily ensure that will never overlap with real subjects
g
Hi, I have the same issue. Any updates on this? Seems like a standard use-case to me…
@numerous-umbrella-61726 Did you find a way to achieve this?
In addition to the problem described, if I use the 
id_token
mutator when trying to anonymously access the resource, the mutator will throw an error:
Copy code
error executing claims template in rule "my-protected-resource": template: 17f927a7349643c00f29237db1327131:1:79: executing "17f927a7349643c00f29237db1327131" at <.Extra.identity.traits.email>: nil pointer evaluating interface {}.traits reason= request-id= status=500 writer=JSON
config.yaml
Copy code
mutators:
  # ...
  id_token:
    enabled: true
    config:
      issuer_url: <http://localhost:4455/>
      jwks_url: file:///cfg/jwks.json
      claims: '{
        "aud": [ "<https://project-holi.org/services/okuna/api>" ],
        "email": "{{ .Extra.identity.traits.email }}"
      }'
rules.yaml
Copy code
- id: my-protected-resource
  version: v0.38.25-beta.1
  upstream:
    url: <http://host.docker.internal:8000/>
  match:
    url: http://<127.0.0.1|localhost>:4455/<.*>
    methods:
      - GET
  authenticators:
    - handler: cookie_session
    - handler: bearer_token
    - handler: anonymous
  authorizer:
    handler: allow
  mutators:
    - handler: id_token
OK, I just found out it’s a Go template and I can work around with ifs. But it would still be cleaner to not have an ID token generated at all for anonymous access.
n
my solution was to change my underlying service code to check for an empty subject rather than a completely empty auth header, so not ideal but worked well enough for now
the other solution i thought about was to split the routes into separate files, so anon routes could skip everything and auth’d routes could use the mutator, but that seems even more complicated as now i have to care at the oathkeeper level which routes are which when right now that’s only at the service level
g
my solution was to change my underlying service code to check for an empty subject rather than a completely empty auth header, so not ideal but worked well enough for now
Yeah, that was what I did too for now, thanks
5 Views
Open in Slack
PreviousNext
Powered by