Subject type of an OAuth token

Here is an example of one oathkeeper rule, you have at the end two hydrators, the first call an internal function that handle the retrieve of the client owner if necessary (check my previous post) and the second get the output of the first hydrator using the extra variables and pass them to the internal micro-services using HTTP headers

{
  "id": "datamodel.models:read",
  "match": {
    "methods": [
      "GET"
    ],
    "url": "http://<host>/datamodel/models/<[a-zA-Z0-9-]+>"
  },
  "upstream": {
    "url": "http://<internal hostname>:<internal port>",
    "preserve_host": true
  },
  "authenticators": [
    {
      "handler": "oauth2_introspection",
      "config": {
        "required_scope": [
          "datamodel.models.readonly"
        ]
      }
    }
  ],
  "authorizer": {
    "handler": "keto_engine_acp_ory",
    "config": {
      "required_action": "read",
      "required_resource": "datamodel.models",
      "subject": "{{.Subject}}",
      "flavor": "glob"
    }
  },
  "mutators": [
    {
      "handler": "hydrator",
      "config": {
        "api": {
          "url": "http://<internal hydrator hostname>:<internal hydrator port>/client-owner",
          "retry": {
            "give_up_after": "10s",
            "max_delay": "1s"
          }
        },
        "cache": {
          "ttl": "120s"
        }
      }
    },
    {
      "handler": "header",
      "config": {
        "headers": {
          "Grpc-Metadata-Client-ID": "{{ print .Extra.client_id }}",
          "Grpc-Metadata-Subject": "{{ print .Subject }}",
          "Grpc-Metadata-User-ID": "{{ print .Extra.real_subject }}"
        }
      }
    }
  ]
}
1 Like

Thanks alot, so your flow will be : request -> authentication -> authorize -> hydrator -> header, right ?

exactly