Oathkeeper ignores the --config parameter:

$ cat ~/.oathkeeper-api.yml
DATABASE_URL: postgres://.../oathkeeper
...
$ oathkeeper serve --config ~/.oathkeeper-api.yml api
FATA[0000] Unable to initialize database connectivity    error="No database URL provided"

It seems this is because viper.SetConfigName unsets configFile:

If URL matches by multiple rules, Oathkeeper returns 500 error Expected exactly one rule but found multiple rules. I think, this is bad idea.
For example, if we want to add two rules: /<.*> with token introspection and /swagger.json without introspection.
Now we can't just add this 2 rules. This enforces us to create many rules for every /* route to avoid overlap.
This error is not obvious. It will appear only in runtime, Oathkeeper don't test it during rules import.
This is not internal, not server, and not exactly error - so, returning 500 error is wrong

My proposal is to add priority field to rule definition, and to apply rule with the highest priority for given URL.

Alternative solutions:

1. Use PCRE instead of default golang's RE2 to allow using negative lookahead in rules definition
2. Add exclude_url field in match
3. Just don't return 500 and apply first matched rule

Is your feature request related to a problem? Please describe.

We need an endpoint which shows us, for example, which handlers (authorizers, ...) are enabled.

Describe the bug
When oathkeeper authenticator handler is set to "jwt", the "required_scope" parameter check the "scope" claim. However, when hydra server is configured to generate jwt as access token, it set the different scopes inside the "scp" claim.

Then all request through oathkeeper are denied

To Reproduce

Run the https://github.com/ory/examples full-stack example and configure :

• Hydra to generate jwt as access token, modify the full-stack/docker-compose.yml file and add in hydra/environnement the line OAUTH2_ACCESS_TOKEN_STRATEGY=jwt
• Oathkeeper to be able to validate the signature by pointing the public key used to sign jwt by adding the line AUTHENTICATOR_JWT_JWKS_URL= http://hydra:4444/.well-known/jwks.json in the oathkeeper-api/environnement and oathkeeper-proxy/environnement
• Modify the rules of oathkeeper by changing the file full-stack/config/oathkeeper/rules/resource-server.json and replacing the line "handler": "oauth2_introspection" by "handler": "jwt"

Expected behavior
The configuration of "required_scope" should parse the "scp" claim and not "scope" claim http://self-issued.info/docs/draft-ietf-oauth-token-exchange-03.html#scopes

it seems that the claim "scope" is parsed in https://github.com/ory/oathkeeper/blob/master/proxy/authenticator_jwt.go line 131

Screenshots
Request with a valid Access Token
You already performed an OAuth 2.0 Token. Therefore, this consumer application has an access token (it's eyJhbGciOiJSUzI1NiIsImtpZCI6InB1YmxpYzoxMWY5Y2M5YS0zZGM5LTQ3OTEtOTkwNS1iYTI2MDVhN2FlZDkiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOltdLCJjbGllbnRfaWQiOiJjb25zdW1lci1hcHAiLCJleHAiOjE1NDMzNzMwMzUsImlhdCI6MTU0MzM2OTQzNSwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo0NDQ0LyIsImp0aSI6ImU0YTAwN2IyLWRlYzQtNDNiYS1iNjk3LWRhZDEwZTNlZmFmNyIsIm5iZiI6MTU0MzM2OTQzNSwic2NwIjpbIm9mZmxpbmUiLCJvcGVuaWQiLCJhcnRpY2xlcy5yZWFkIl0sInN1YiI6ImZvb0BiYXIuY29tIn0.Eygkne9ByXEOvHoKwsL3_6Tnz0NoZS4eU1sKIEQXEDS2bWx5nV-JNGCpBZe8YcUQicd_W2YWNKDt-SY7E1ZuJIc7jU-jPrBoR_8OW-h3IoEhkRET3CvcI912RYuNzonMCty5z-mxmRiY-XPFhh4b36UUEK6DtIkVgRKOIrGTMEaRCvIY2qrNjFWlZ7B6vSasLhlJ0rRc4oyxCpz1dnQcGGvNe9GiuRGrwRRwpsiST7oxLSkWtP0ZOlLxkMdMLyAIQ7VaVz86p1y1LLgTEt27nYC5Fzi0iQNQhDCfrLzYvFF5QZm5aMydRMr5Igkyd0qx7FD4F6xJw4xspciI8eS2aoz2ZXWCUPGLYaDUepvVKfnM4XjP3sZQkY-7scsrVjqCv-0hAeGFNWjGHm6YADOU8_RzFd8NtMWT6tmCkcEJk4MCRjfB8cKXjzFJJbCWT6N6TNoLxGsjwjVAmAdDAiUBFiWtdKoN0TfUXjDuXm3JDM6qg5r8-gDIet6ooZWRcE2bpOlzGQWca6FBzG-s_GxFPFe24G_CeM3Ac6gmcTGUjiChYyML1KHRRQlx-B0SthrMaBu53bCYzveuTirehBWj3PG59TpASbNBWaayP9132LG0r8On5tnwpJJLh4rTwz0INO34u2V3iJBjqpW4xgT6BPAvhKRz52u3S2n-pBe1bTg). We're making a request to the backend and are including the token in the HTTP request header:
{
"alg": "RS256",
"kid": "public:11f9cc9a-3dc9-4791-9905-ba2605a7aed9",
"typ": "JWT"
}
{
"aud": [],
"client_id": "consumer-app",
"exp": 1543373035,
"iat": 1543369435,
"iss": "http://localhost:4444/",
"jti": "e4a007b2-dec4-43ba-b697-dad10e3efaf7",
"nbf": 1543369435,
"scp": [
"offline",
"openid",
"articles.read"
],
"sub": "[email protected]"
}

HTTP Response Body
{"error":{"code":403,"status":"Forbidden","reason":"Token is missing required scope articles.read.","message":"Access credentials are not sufficient to access this resource"}}

When you changed the consent app to add the claim "scope" we get :

You already performed an OAuth 2.0 Token. Therefore, this consumer application has an access token (it's eyJhbGciOiJSUzI1NiIsImtpZCI6InB1YmxpYzoyNDFhOGFmZi04OGQ1LTQ4NTctYWI5OS01MDFiZGVhMzkyMzUiLCJ0eXAiOiJKV1QifQ.eyJhdWQiOltdLCJjbGllbnRfaWQiOiJjb25zdW1lci1hcHAiLCJleHAiOjE1NDMzNzk2MTgsImlhdCI6MTU0MzM3NjAxOCwiaXNzIjoiaHR0cDovL2xvY2FsaG9zdDo0NDQ0LyIsImp0aSI6IjQ1MGFlOTI1LWUyN2YtNDVhYy1hNTVkLWE5YmJlOGY2MmViZiIsIm5iZiI6MTU0MzM3NjAxOCwic2NvcGUiOlsib3BlbmlkIiwiYXJ0aWNsZXMucmVhZCJdLCJzY3AiOlsib3BlbmlkIiwiYXJ0aWNsZXMucmVhZCJdLCJzdWIiOiJmb29AYmFyLmNvbSJ9.CPowFDgN2RhD9IWxu4OCGFnqnRT3Z7Q7tNiIA0m4cq10bU6JyMbo804UADwzroe4ssGKk_Ptjy1EfObIo0ne4IOMwPsHM_9rmLNYD93XYWTKPa3DqTW5_OiUtCQWpt9U5Dstnjf-eKOOeB9dEYjyulFydRPlqagY9jw4SJmmoyfSyJ-wqiYQSIWgHIGuNRMr_6ul7aplhpEUKzFivVVEVvKOtTCUsSsaC7fdMcqJekhrVE0GnWZoyK-d-DwZGBr8NeKV6KDu3l7Vemt1Wtd0vf_LcNL9AFbBK4CevGFi1cAxDsSPvuAAoIGhAxTKSCkbP53lh87gf-maLO6EVrFOy721uZvHnJJddvWqvb5ge-IYRrAUTL56-xPresEPAYpTSOs2cxxz-JdEXMoUlm8CDt8pAejDvXrl69VpfmHmAf7VOe80En0J7bEq-MvGO0KrRYSvdjOnp-wVIPNOYH9PlInLfuM7qnZ5_J727pWqfm8CQwHR0aUXgvB4x90En8dSvYU-_a1Sqg6wWxv7L11CIkT65nY1Lw-NBLvkCSqAZO9KOQyiwL3lfyMUn7qsJsDkBm_lP75c31tCRh2xecddLtP2K30IUKqp6zBcGud0AYODj86OUBEy5D_N6SQo7S0ZRZoQABm6IZxQeWqmUF8bejbbsRJv3ikwsto2cYKANw4). We're making a request to the backend and are including the token in the HTTP request header:
{
"alg": "RS256",
"kid": "public:66c5e53a-4c79-4b32-b625-a2ed940e9d7c",
"typ": "JWT"
}
{
"aud": [],
"client_id": "consumer-app",
"exp": 1543379463,
"iat": 1543375863,
"iss": "http://localhost:4444/",
"jti": "2cf61755-75c0-49a5-91da-7db8561f16cd",
"nbf": 1543375863,
"scope": [
"articles.read"
],
"scp": [
"articles.read"
],
"sub": "[email protected]"
}

HTTP Response Body
{
"message": "Congratulations, you gained access to this endpoint!",
"tokenClaims": {
"client_id": "consumer-app",
"exp": 1543379619,
"iat": 1543376019,
"iss": "http://oathkeeper-api:4456",
"jti": "580c44ae-5bf8-4027-b87d-cb436941ace7",
"nbf": 1543376019,
"scope": "openid articles.read",
"sub": "[email protected]",
"username": ""
}
}

Version:
docker version
Client:
Version: 18.09.0
API version: 1.39
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:49:01 2018
OS/Arch: linux/amd64
Experimental: false

Server: Docker Engine - Community
Engine:
Version: 18.09.0
API version: 1.39 (minimum version 1.12)
Go version: go1.10.4
Git commit: 4d60db4
Built: Wed Nov 7 00:16:44 2018
OS/Arch: linux/amd64
Experimental: false

Thank you in advance for your return

Hi.
I faced with an issue setting up Hydra in pair with OathKeeper. Following the guidelines I have run Hydra, but when I starting with OathKeeper it fails with an "Unable to refresh RSA keys for JWK signing" error.

Using:

• Hydra v0.11.6
• OathKeeper 0.0.29

OathKeeper log:

time="2018-02-28T09:19:21Z" level=error msg="Unable to refresh RSA keys for JWK signing" error="Expected status code 200 but got 403" retry=0

Hydra log:

hydra_1 | time="2018-02-28T09:19:21Z" level=info msg="started handling request" method=POST remote="172.18.0.4:39010" request=/oauth2/token
hydra_1 | time="2018-02-28T09:19:21Z" level=info msg="started handling request" method=POST remote="172.18.0.4:39012" request=/oauth2/token
hydra_1 | time="2018-02-28T09:19:21Z" level=info msg="completed handling request" measure#http://localhost:4444.latency=90761997 method=POST remote="172.18.0.4:39010" request=/oauth2/token status=200 text_status=OK took=90.761997ms
hydra_1 | time="2018-02-28T09:19:21Z" level=info msg="started handling request" method=GET remote="172.18.0.4:39010" request="/keys/oathkeeper:id-token/private"
hydra_1 | time="2018-02-28T09:19:21Z" level=info msg="Access granted" client_id=oathkeeper-client request="&{[] [] { 2018-02-28 09:19:21.148473 +0000 +0000 0xc420494000 [hydra.introspect hydra.warden hydra.keys.] [hydra.introspect hydra.warden hydra.keys.] map[grant_type:[client_credentials] scope:[hydra.introspect hydra.warden hydra.keys.]] 0xc42030b250}}" result="&{oathkeeper-client [hydra.introspect hydra.warden hydra.keys.] http://localhost:4444 oathkeeper-client 2018-02-28 09:19:21.148473 +0000 +0000 2018-02-28 10:19:21.236134569 +0000 UTC map[]}" subject=oathkeeper-client
hydra_1 | time="2018-02-28T09:19:21Z" level=error msg="An error occurred while handling a request" code=404 details="[]" error=": Not found" reason= request-id= status= trace="Stack trace: \ngithub.com/ory/hydra/jwk.(*SQLManager).GetKey\n\t/go/src/github.com/ory/hydra/jwk/manager_sql.go:139\ngithub.com/ory/hydra/jwk.(*Handler).GetKey\n\t/go/src/github.com/ory/hydra/jwk/handler.go:210\ngithub.com/ory/hydra/jwk.(*Handler).GetKey-fm\n\t/go/src/github.com/ory/hydra/jwk/handler.go:70\ngithub.com/ory/hydra/vendor/github.com/julienschmidt/httprouter.(*Router).ServeHTTP\n\t/go/src/github.com/ory/hydra/vendor/github.com/julienschmidt/httprouter/router.go:299\ngithub.com/ory/hydra/vendor/github.com/urfave/negroni.Wrap.func1\n\t/go/src/github.com/ory/hydra/vendor/github.com/urfave/negroni/negroni.go:41\ngithub.com/ory/hydra/vendor/github.com/urfave/negroni.HandlerFunc.ServeHTTP\n\t/go/src/github.com/ory/hydra/vendor/github.com/urfave/negroni/negroni.go:24\ngithub.com/ory/hydra/vendor/github.com/urfave/negroni.middleware.ServeHTTP\n\t/go/src/github.com/ory/hydra/vendor/github.com/urfave/negroni/negroni.go:33\ngithub.com/ory/hydra/vendor/github.com/urfave/negroni.(middleware).ServeHTTP-fm\n\t/go/src/github.com/ory/hydra/vendor/github.com/urfave/negroni/negroni.go:33\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1918\ngithub.com/ory/hydra/cmd/server.(*Handler).rejectInsecureRequests\n\t/go/src/github.com/ory/hydra/cmd/server/handler.go:200\ngithub.com/ory/hydra/cmd/server.(*Handler).(github.com/ory/hydra/cmd/server.rejectInsecureRequests)-fm\n\t/go/src/github.com/ory/hydra/cmd/server/handler.go:113\ngithub.com/ory/hydra/vendor/github.com/urfave/negroni.HandlerFunc.ServeHTTP\n\t/go/src/github.com/ory/hydra/vendor/github.com/urfave/negroni/negroni.go:24\ngithub.com/ory/hydra/vendor/github.com/urfave/negroni.middleware.ServeHTTP\n\t/go/src/github.com/ory/hydra/vendor/github.com/urfave/negroni/negroni.go:33\ngithub.com/ory/hydra/vendor/github.com/urfave/negroni.(middleware).ServeHTTP-fm\n\t/go/src/github.com/ory/hydra/vendor/github.com/urfave/negroni/negroni.go:33\ngithub.com/ory/hydra/vendor/github.com/meatballhat/negroni-logrus.(*Middleware).ServeHTTP\n\t/go/src/github.com/ory/hydra/vendor/github.com/meatballhat/negroni-logrus/middleware.go:136\ngithub.com/ory/hydra/vendor/github.com/urfave/negroni.middleware.ServeHTTP\n\t/go/src/github.com/ory/hydra/vendor/github.com/urfave/negroni/negroni.go:33\ngithub.com/ory/hydra/vendor/github.com/urfave/negroni.(middleware).ServeHTTP-fm\n\t/go/src/github.com/ory/hydra/vendor/github.com/urfave/negroni/negroni.go:33\ngithub.com/ory/hydra/metrics.(*MetricsManager).ServeHTTP\n\t/go/src/github.com/ory/hydra/metrics/middleware.go:157\ngithub.com/ory/hydra/vendor/github.com/urfave/negroni.middleware.ServeHTTP\n\t/go/src/github.com/ory/hydra/vendor/github.com/urfave/negroni/negroni.go:33\ngithub.com/ory/hydra/vendor/github.com/urfave/negroni.(*Negroni).ServeHTTP\n\t/go/src/github.com/ory/hydra/vendor/github.com/urfave/negroni/negroni.go:73\ngithub.com/ory/hydra/vendor/github.com/rs/cors.(*Cors).Handler.func1\n\t/go/src/github.com/ory/hydra/vendor/github.com/rs/cors/cors.go:200\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1918\ngithub.com/ory/hydra/vendor/github.com/gorilla/context.ClearHandler.func1\n\t/go/src/github.com/ory/hydra/vendor/github.com/gorilla/context/context.go:141\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1918\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2619\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1801\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:2337" writer=JSON
hydra_1 | time="2018-02-28T09:19:21Z" level=info msg="completed handling request" measure#http://localhost:4444.latency=8060668 method=GET remote="172.18.0.4:39010" request="/keys/oathkeeper:id-token/private" status=404 text_status="Not Found" took=8.060668ms

Digging into the code of OathKeeper I found it depends on github.com/ory/[email protected]. And since it fails in the following line https://github.com/ory/oathkeeper/blob/master/rsakey/manager_hydra.go#L42 I did not find GetJsonWebKey method within JWKApi interface implemented for github.com/ory/[email protected]. It seems latest version of OathKeeper is incompatible with latest of Hydra.
Could you please advice what to do or probably share some drawbacks of using OathKeeper with latest version of Hydra?

Thanks in advance.

I currently use Vault from hashicorp and it's pretty good.

It seems to make slot of sense to support Vault as an Authenticator for Key system.

I don't know enough about the details of oxy system to suggest the exact interface connections though. Maybe you do.

The reasoning for keeping vault is because users can request access to a resource if they need it and the vault system provides admin ticketing. Also of course it provides the secure storage.

Anyway happy to discuss

Describe the bug
Unable to install oathkeeper CLI

To Reproduce
Steps to reproduce the behavior:

1. Run $ go get github.com/ory/oathkeeper

# github.com/ory/x/metricsx
../../../go/src/github.com/ory/x/metricsx/middleware.go:101:10: undefined: analytics.Config`

Is your feature request related to a problem? Please describe.]

Implement GRPC response in the Decisions API. If Content-type is application/grpc ORY Oathkeeper should response with the appropriate GRPC response.

Describe the solution you'd like

Something like this in the judge handler:

func grpcHandlerFunc(rpcServer *rpc.Server, other http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        ct := r.Header.Get("Content-Type")
        if r.ProtoMajor == 2 && strings.Contains(ct, "application/grpc") {
            rpcServer.ServeHTTP(w, r)
        } else {
            other.ServeHTTP(w, r)
        }
    })
}

Currently, we use the issuer from the introspection / warden endpoint for the ID token. However, this is sometimes empty, especially when no credentials are given. Investigate if we should set this to oathkeeper's URL or Hydra's

For consistency, should be HTTP_TLS_CERT_PATH and HTTP_TLS_KEY_PATH

certString, keyString := viper.GetString("HTTP_TLS_CERT"), viper.GetString("HTTP_TLS_KEY") certPath, keyPath := viper.GetString("HTTP_TLS_CERT_PATH"), viper.GetString("HTTP_TLS_KEY_PATH")

See https://community.ory.sh/t/please-specify-the-ory-hydra-endpoint-url/491

When posting a large body over a slow internet connection the connection is cancelled after 5 seconds. I've tracked it down to the graceful wrapper but couldn't figure out why it was causing the issue.

I removed launching the proxy with graceful and it works now.

May 03 03:16:28 instance-1 oathkeeper[2170]: time="2018-05-03T03:16:28Z" level=info msg="started handling request" method=POST remote=x.x.x.x request=/api/v1/item
May 03 03:16:28 instance-1 oathkeeper[2170]: time="2018-05-03T03:16:28Z" level=info msg="Access request granted" access_url="https://api-server/api/v1/item" granted=true mode=policy reason="Rule requires policy-base
May 03 03:16:33 instance-1 oathkeeper[2170]: time="2018-05-03T03:16:33Z" level=info msg="Round trip failed" error="read tcp 127.0.0.1:4455->127.0.0.1:38400: i/o timeout" url="http://localhost:3000/api/v1/item"
May 03 03:16:33 instance-1 oathkeeper[2170]: 2018/05/03 03:16:33 http: proxy error: read tcp 127.0.0.1:4455->127.0.0.1:38400: i/o timeout
May 03 03:16:33 instance-1 oathkeeper[2170]: time="2018-05-03T03:16:33Z" level=info msg="completed handling request" measure#oathkeeper-proxy.latency=4999954714 method=POST remote=x.x.x.x request=/api/v1/item stat
May 03 03:16:47 instance-1 oathkeeper[2170]: time="2018-05-03T03:16:47Z" level=info msg="started handling request" method=POST remote=x.x.x.x request=/api/v1/item
May 03 03:16:47 instance-1 oathkeeper[2170]: time="2018-05-03T03:16:47Z" level=info msg="Access request granted" access_url="https://api-server/api/v1/item" granted=true mode=policy reason="Rule requires policy-base
May 03 03:16:52 instance-1 oathkeeper[2170]: time="2018-05-03T03:16:52Z" level=info msg="Round trip failed" error="read tcp 127.0.0.1:4455->127.0.0.1:38410: i/o timeout" url="http://localhost:3000/api/v1/item"
May 03 03:16:52 instance-1 oathkeeper[2170]: 2018/05/03 03:16:52 http: proxy error: read tcp 127.0.0.1:4455->127.0.0.1:38410: i/o timeout
May 03 03:16:52 instance-1 oathkeeper[2170]: time="2018-05-03T03:16:52Z" level=info msg="completed handling request" measure#oathkeeper-proxy.latency=4999908503 method=POST remote=x.x.x.x request=/api/v1/item stat
May 03 03:17:51 instance-1 oathkeeper[2170]: time="2018-05-03T03:17:51Z" level=info msg="started handling request" method=POST remote=x.x.x.x request=/api/v1/item
May 03 03:17:51 instance-1 oathkeeper[2170]: time="2018-05-03T03:17:51Z" level=info msg="Access request granted" access_url="https://api-server/api/v1/item" granted=true mode=policy reason="Rule requires policy-base
May 03 03:17:56 instance-1 oathkeeper[2170]: time="2018-05-03T03:17:56Z" level=info msg="Round trip failed" error="read tcp 127.0.0.1:4455->127.0.0.1:38418: i/o timeout" url="http://localhost:3000/api/v1/item"
May 03 03:17:56 instance-1 oathkeeper[2170]: 2018/05/03 03:17:56 http: proxy error: read tcp 127.0.0.1:4455->127.0.0.1:38418: i/o timeout
May 03 03:17:56 instance-1 oathkeeper[2170]: time="2018-05-03T03:17:56Z" level=info msg="completed handling request" measure#oathkeeper-proxy.latency=4999861120 method=POST remote=x.x.x.x request=/api/v1/item stat
May 03 03:19:10 instance-1 oathkeeper[2170]: time="2018-05-03T03:19:10Z" level=info msg="started handling request" method=POST remote=x.x.x.x request=/api/v1/item
May 03 03:19:10 instance-1 oathkeeper[2170]: time="2018-05-03T03:19:10Z" level=info msg="Access request granted" access_url="https://api-server/api/v1/item" granted=true mode=policy reason="Rule requires policy-base
May 03 03:19:15 instance-1 oathkeeper[2170]: time="2018-05-03T03:19:15Z" level=info msg="Round trip failed" error="context canceled" url="http://localhost:3000/api/v1/item"
May 03 03:19:15 instance-1 oathkeeper[2170]: 2018/05/03 03:19:15 http: proxy error: context canceled
May 03 03:19:15 instance-1 oathkeeper[2170]: time="2018-05-03T03:19:15Z" level=info msg="completed handling request" measure#oathkeeper-proxy.latency=5000230223 method=POST remote=x.x.x.x request=/api/v1/item stat
May 03 03:19:33 instance-1 oathkeeper[2170]: time="2018-05-03T03:19:33Z" level=info msg="started handling request" method=POST remote=x.x.x.x request=/api/v1/item
May 03 03:19:33 instance-1 oathkeeper[2170]: time="2018-05-03T03:19:33Z" level=info msg="Access request granted" access_url="https://api-server/api/v1/item" granted=true mode=policy reason="Rule requires policy-base
May 03 03:19:38 instance-1 oathkeeper[2170]: time="2018-05-03T03:19:38Z" level=info msg="Round trip failed" error="read tcp 127.0.0.1:4455->127.0.0.1:38436: i/o timeout" url="http://localhost:3000/api/v1/item"
May 03 03:19:38 instance-1 oathkeeper[2170]: 2018/05/03 03:19:38 http: proxy error: read tcp 127.0.0.1:4455->127.0.0.1:38436: i/o timeout
May 03 03:19:38 instance-1 oathkeeper[2170]: time="2018-05-03T03:19:38Z" level=info msg="completed handling request" measure#oathkeeper-proxy.latency=5000137768 method=POST remote=x.x.x.x request=/api/v1/item stat
May 03 03:22:07 instance-1 oathkeeper[2170]: time="2018-05-03T03:22:07Z" level=info msg="started handling request" method=POST remote=x.x.x.x request=/api/v1/item

Ask for the Auth0 JWT middleware how they solved auto discovery.

Right now, misconfigured authorizers will be disabled. This sucks for management UIs and developer experience. Instead, we should show a decent log error message as well as a decent error message in the http response.

I have created some oathkeeper rules, adding them as it's done in "ory/examples".

by mistake, two of them were applying to the same route, so obviously, the error when trying to access the route was:
{"error":{"code":500,"status":"Internal Server Error","message":"Expected exactly one rule but found multiple rules"}}

I delete one of them (and verify it has been deleted with GET /rules), but the error doesn't go away, even after waiting for more than 30s

see gist for details and steps to reproduce the problem

It's not clear why certain env vars are only in proxy mode while others are in api mode.

Is there any way we can add the WWW-Authenticate header to a 401 response so that a user using a web browser will be prompted for credentials?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication

The options are a bit confusing:

• BypassAuthorization: Basically a passthrough - does not modify the access token at all
• BypassAccessControlPolicies: Requires an access token with an appropriate scope but does not check access control policies - injects a JWT as bearer token
• AllowAnonymous: If an access token is supplied, it is introspected for the user. If that fails, or no token was given, the user is called anonymous - injects a JWT as bearer token

When running the tests against a non-docker hydra (current master) I get the following:

=== RUN   TestManager/case=hydra
--- FAIL: TestManager (1.87s)
    --- PASS: TestManager/case=local (0.01s)
    --- FAIL: TestManager/case=hydra (1.86s)
        Error Trace:    manager_test.go:71
        Error:          Received unexpected error:
                        Expected at least one private key but got none
                        github.com/ory/oathkeeper/rsakey.(*HydraManager).Refresh
                                /home/andre/go2/src/github.com/ory/oathkeeper/rsakey/manager_hydra.go:68
                        github.com/ory/oathkeeper/rsakey.TestManager.func1
                                /home/andre/go2/src/github.com/ory/oathkeeper/rsakey/manager_test.go:71
                        testing.tRunner
                                /nix/store/d3vzj0lqdd879m812kpwzazzxzb27bik-go-1.10.1/share/go/src/testing/testing.go:777
                        runtime.goexit
                                /nix/store/d3vzj0lqdd879m812kpwzazzxzb27bik-go-1.10.1/share/go/src/runtime/asm_amd64.s:2361
        Test:           TestManager/case=hydra
FAIL
FAIL    github.com/ory/oathkeeper/rsakey        1.872s

It looks like there has been a change to generating the keys to use a GUID causing https://github.com/ory/oathkeeper/blob/master/rsakey/manager_hydra.go#L42 to not find it and loop generating initial RSA keys.

I hacked a fix by introducing a new key identifier. I see there are changes coming for hydra and was thinking of targeting the later code if possible.

Hello again,

I am using full stack of your applications. I am having a problem now with working behind a proxy (traefik) that drops the tls. I would like to connect oathkeeper to the hydra within internal web but the hydra requires the 'X-Forwarded-Proto':'https' header.
Could you add please the feature that adds the XFP header i.e. using the environment variables when the protocol is 'http'?

Describe the bug
Getting Bad Request for authorizer of type keto_engine_acp_ory when creating a new rule.

To Reproduce
Steps to reproduce the behavior:
Use keto_engine_acp_ory with config containing required_action and required_resource

Expected behavior
A clear and concise description of what you expected to happen.
Should expect rule to be inserted.

Version:

• Environment: Docker
• Version v0.14.2_oryOS.10

Additional context
I have set the required Environment variable to enable the Keto authorizer: using new variable AUTHORIZER_KETO_URL
Error From API:

{
    "error": {
        "code": 400,
        "status": "Bad Request",
        "reason": "Authorizer \"keto_engine_acp_ory\" is valid but has not enabled by the server's configuration, enabled authorizers are: [allow deny]",
        "message": "The request is malformed or contains invalid data"
    }
}

Hi there,

so I kinda messed up. This project is currently released as version v1.0.0-beta.X. The goal of this was to have one coherent version across all services to make integration of them as easy as possible. While that was a good intention, releasing something as v1.0.0 gave the wrong impression of stability, and rightful so. My initial idea was to label projects that are not fully backed yet with a -sandbox or -preview tag (v1.0.0-sandbox) but that contradicts how semantic versioning works and is probably even more confusing.

For so many reasons this was a bad decision, this project specifically moved right away from v0.0.29 to v0.11.0 to v1.0.0 - instead of going through a "sandbox" or "graduating" phase where you, the community, evaluates the usefulness of the service and gives feedback on missing parts which may require breaking changes.

To resolve this, we worked on a new concept which I would like to present to you here. To not make the same mistake again, I want to get your feedback on this before moving forward with this plan. Implementing this plan implies that versions v1.0.0-beta.* will be purged and that we will start tagging this as a v0.y.z release instead.

Please read (and give feedback) on the following paragraphs which will be (upon approval) immortalized in the ORY Documentation:

Software Versions

The ORY ecosystem consists of multiple services versioned using semantic versioning. This section
explains how we define service versions and what they mean.

There are two types of services:

• Graduated services change rarely in a backwards incompatible fashion. A service can be considered graduated if
  the major version is >= 1 - for example: v1.0.1, v2.2.2. If a serious backwards incompatible
  change is made, the major version jumps one up. Most, if not all, REST APIs will provide backwards compatible transformations that
  make it possible to interact with the server using older API concepts.
• Incubating services have well defined concepts but do not provide backwards compatible REST APIs yet. Incubating
  services are indicated by major version numbers of 0 - for example: v0.10.0
• Sandbox services may implement concepts, provide APIs and CLIs which are not fully baked yet. It is possible that
  these services change in unpredictable ways. These services are indicated by major version numbers of 0 and the
  sandbox label - for example: v0.10.0-sandbox.

To make deployment easier but stay compatible with semantic versioning, each service is equipped with a ecosystem version
number denoted by +oes.X where X represents the version ecosystem. This is specifically useful when using
incubating or sandboxed services which do not share the version numbers of graduated services. Let's look at some examples:

• ORY Hydra v1.0.1+oes.6 is best compatible with ORY Oathkeeper v0.12.1+oes.6 and ORY Keto v0.5.1-sandbox+oes.6.
• ORY Hydra v1.0.2+oes.7 is best compatible with ORY Oathkeeper v0.12.2+oes.7 and ORY Keto v0.6.0-sandbox+oes.7.
• ORY Hydra v1.0.3+oes.8 is probably not fully compatible with ORY Oathkeeper v0.12.1+oes.6 nor with ORY Keto
  v0.5.1-sandbox+oes.6.
• ORY Hydra v1.1.0+oes.9 is best compatible with ORY Oathkeeper v1.1.0+oes.9 and ORY Keto v1.1.0+oes.9.

Important: Each release - unless explicitly labeled as -unstable - is going through extensive quality assurance
and is considered secure and reliable enough to be run in production. If you choose to go with an incubating or sandbox
service, it is likely that you will spend some time addressing breaking changes.

We always provide ways to migrate breaking changes, and all breaking changes are meticolously described in each project's
UPGRADE.md as well as HISTORY.md.

I would like to see two new Issuer types: Headers and Cookies.

Headers

As a baseline proposal for Headers, I'd like to start with Go text/template based configuration and proceed from there. An example rule might look like this, with the template root object being the proxy.AuthenticationSession:

{
    "id": "some-id",
    "upstream": {"url": "http://my-backend-service"},
    "match": { },
    "authenticators": [ ],
    "authorizer": { },
    "credentials_issuer": {
        "handler": "headers",
        "config": {
            "X-User": "{{ .Subject }}",
            "X-Audience": "{{ .Extra[\"aud\"] }}",
            "X-Issuer": "{{ .Extra[\"iss\"] }}"
        }
    }
}

Some concerns I have with the above would be the performance and unnecessary complexity of text/template. The same might be accomplished with a Sprintf, but with the open-ended nature of the Extra map field of the AuthenticationSession struct, I can think of no good way to ensure all map fields are passed into Sprintf reliably. This assumes that the oauth2_introspection Authenticator is eventually extended to allow for "extension" fields for arbitrary introspection data (which I would also love to see).

Cookies

Using text/template as well for the same reasons as above:

{
    "id": "some-id",
    "upstream": {"url": "http://my-backend-service"},
    "match": { },
    "authenticators": [ ],
    "authorizer": { },
    "credentials_issuer": {
        "handler": "cookies",
        "config": {
            "cookie-name": {
                "user": "{{ .Subject }}",
                "audience": "{{ .Extra[\"aud\"] }}",
                "issuer": "{{ .Extra[\"iss\"] }}"
            }
        }
    }
}

Security Concerns

Baseline security would require that the above Headers and Cookies are stripped from incoming requests to the specified upstream, to prevent someone being able to "log in" by running a simple curl -H "X-User: admin" http://example.com

Other Implementations

Kong provides upstream header data in its gateway service, however the headers are fixed: https://docs.konghq.com/plugins/oauth2-authentication/#upstream-headers

This would certainly help with performance, but I think it would be unnecessarily restrictive when considering that OAuth2 introspection could allow for a great deal more upstream context, and that some out-of-the-box applications may have specific requirements for receiving authentication information. I think a good middle ground would be to have a set of default headers which would be used if config is left blank, making the rules simpler and easier to write in many cases.

It's my understanding that AWS API Gateway has a similar feature, but I've been unable to locate the documentation for it. If anyone could link the relevant docs here for review that would be great.

Copy the configuration management used in Hydra and Hive

Hello I'm using your full-stack within my app.

I have a problem with patching the url matcher. When i try to add <http|https> regexp just as you shown within the guide, the API replies with:

Value "<http|https>://hydra.myurl.com/keys" from match.url field is not a valid url.

It is probably the problem with putting raw value into govalidator.

oathkeeper tag beta8 is not compatible with hydra beta 8.

In particular, this build uses pre-beta8 hydra SDK client, and is not able to distinguish AdminURL from PublicURL.

When running from docker images beta8 (hydra & oathkeeper), I am unable to have oathkeeper use a setup with admin and public running on separate ports.

Currently users have to specify a random hs256 secret for oathkeeper even if they don't use id_token credential issuer. I think it would be more convenient to atomatically disable this issuer if there are no configurations for it.

Steps to reproduce:

$ docker run --rm -it -e DATABASE_URL=memory oryd/oathkeeper:v1.0.0-beta.9 serve api
FATA[0000] Unable to initialize the ID Token signing algorithm  error="The secret set in CREDENTIALS_ISSUER_ID_TOKEN_HS256_SECRET must be 32 characters long."

I have deployed ory os on various systems and I always run into the same issue when dealing with oathkeeper. In my case there is an nginx server that terminates all https requests and forwards the traffic to an oathkeeper upstream server.

Due to the nature of this setup, I always have to specify my match rules as http protocol as that is what nginx passes to oathkeeper.

Can someone point me in the right direction on solving this issue? I could not find anything in the documentation.

Thanks

Needs Go 1.10

As latest release have already been migrated to go module, the dep doesn't work any more, it would be better to update the instructions same as keto or hydra does, or add up additional note to clarify.

README - building-from-source

hydra - README - buiding from source

https://github.com/open-policy-agent/opa

Is your feature request related to a problem? Please describe.
Make Subject configurable instead of hard coding to session.Subject
https://github.com/lsjostro/oathkeeper/blob/master/proxy/authorizer_keto_warden.go#L96

Describe the solution you'd like
Would be nice to be able to pass something from the Extra attribute. i.e session.Extra["email"], as Subject to Keto. Maybe use the same implementation as in headers in Credentials Issuers using go templates?

Tokens issued by oathkeeper (beta 4)have different kid values than in .well-known/jwks.json

{ "alg": "HS256", "kid": "ba4a9b07-2543-4d5f-b0e8-ad4df2b669db", "typ": "JWT" }

has kid of ba4a9b07-2543-4d5f-b0e8-ad4df2b669db

but when i get well-known/jwks.json there is no such kid

{ "keys": [ { "use": "sig", "kty": "oct", "kid": "dc39e248-1005-4689-bb67-f938c9a4b63f", "alg": "HS256", "k": "MGEwNGQzMzAtMDIyOC00MGE5LWI5NjctMTcwM2M0ZWU5MTJl" } ] }

It appears that Oathkeeper is missing a serve all command similar to Hydra. This would be useful for launching both in a single container.

Likewise, both the serve proxy and serve api commands bind to port 4455, even though the help documentation states the api will bind to port 4456 by default.

Describe the bug
With CORS enabled, the proxy does not seem to return the correct headers.

To Reproduce
Steps to reproduce the behavior:
Enable CORS in config
Set CORS_ALLOWED_ORIGINS="*"
Make request to through Oathproxy

Expected behavior
Response from Proxy to return single Access-Control-Allow-Origin header

Screenshots

Version:

• Environment: Docker
• Version: v0.14.2_oryOS.10

Additional context
Also, setting the origin explicitly in CORS_ALLOWED_ORIGINS results in similar error, Access-Control-Allow-Origin is set twice in the response.

Migrate SQL command not working as specified in documentation.
Looks like its only supporting Postgres at the moment.

https://github.com/ory/oathkeeper/blob/v1.0.0-beta.4/cmd/helper_sql.go#L35

Hi, I'm having an issue when I try to use my access rules(Oathkeeper), policies and roles (Keto) with an external consumer app.

I have valid access tokens obtained from Hydra (login & consent flow - authorization code flow performed before this step). Oathkeeper produces the following errors when it tries to authorize (handler keto_engine_acp_ory) current request.

Docker Logs - API
time="2019-03-11T14:14:33Z" level=info msg="started handling request" method=GET remote="172.22.0.1:36978" request=/judge/api/dummies time="2019-03-11T14:14:33Z" level=warning msg="The authorization handler encountered an error" access_url="http://localhost:4456/api/dummies" authorization_handler=keto_engine_acp_ory error="Access credentials are not sufficient to access this resource" granted=false reason_id=authorization_handler_error time="2019-03-11T14:14:33Z" level=warning msg="Access request denied" access_url="http://localhost:4456/api/dummies" error="Access credentials are not sufficient to access this resource" granted=false time="2019-03-11T14:14:33Z" level=error msg="An error occurred while handling a request" code=403 details="map[]" error="Access credentials are not sufficient to access this resource" reason= request-id= status=Forbidden trace="Stack trace: \ngithub.com/ory/oathkeeper/proxy.(*AuthorizerKetoWarden).Authorize\n\t/go/src/github.com/ory/oathkeeper/proxy/authorizer_keto_warden.go:130\ngithub.com/ory/oathkeeper/proxy.(*RequestHandler).HandleRequest\n\t/go/src/github.com/ory/oathkeeper/proxy/request_handler.go:147\ngithub.com/ory/oathkeeper/judge.(*Handler).judge\n\t/go/src/github.com/ory/oathkeeper/judge/handler.go:103\ngithub.com/ory/oathkeeper/judge.(*Handler).ServeHTTP\n\t/go/src/github.com/ory/oathkeeper/judge/handler.go:70\ngithub.com/urfave/negroni.Wrap.func1\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:46\ngithub.com/urfave/negroni.HandlerFunc.ServeHTTP\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:29\ngithub.com/urfave/negroni.middleware.ServeHTTP\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:38\ngithub.com/urfave/negroni.middleware.ServeHTTP-fm\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:38\ngithub.com/ory/x/metricsx.(*MetricsManager).ServeHTTP\n\t/go/pkg/mod/github.com/ory/[email protected]/metricsx/middleware.go:207\ngithub.com/urfave/negroni.middleware.ServeHTTP\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:38\ngithub.com/urfave/negroni.middleware.ServeHTTP-fm\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:38\ngithub.com/meatballhat/negroni-logrus.(*Middleware).ServeHTTP\n\t/go/pkg/mod/github.com/meatballhat/[email protected]/middleware.go:136\ngithub.com/urfave/negroni.middleware.ServeHTTP\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:38\ngithub.com/urfave/negroni.(*Negroni).ServeHTTP\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:96\ngithub.com/rs/cors.(*Cors).Handler.func1\n\t/go/pkg/mod/github.com/rs/[email protected]/cors.go:207\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1964\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2741\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1847\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1333" writer=JSON time="2019-03-11T14:14:33Z" level=info msg="completed handling request" measure#oathkeeper-api.latency=17072600 method=GET remote="172.22.0.1:36978" request=/judge/api/dummies status=403 text_status=Forbidden took=17.0726ms

Docker Logs - Proxy
time="2019-03-11T14:15:13Z" level=info msg="started handling request" method=GET remote="172.22.0.1:36742" request=/api/dummies time="2019-03-11T14:15:13Z" level=warning msg="The authorization handler encountered an error" access_url="http://localhost:4455/api/dummies" authorization_handler=keto_engine_acp_ory error="Access credentials are not sufficient to access this resource" granted=false reason_id=authorization_handler_error time="2019-03-11T14:15:13Z" level=warning msg="Access request denied" access_url="http://localhost:4455/api/dummies" error="Access credentials are not sufficient to access this resource" granted=false time="2019-03-11T14:15:13Z" level=error msg="An error occurred while handling a request" code=403 details="map[]" error="Access credentials are not sufficient to access this resource" reason= request-id= status=Forbidden trace="Stack trace: \ngithub.com/ory/oathkeeper/proxy.(*AuthorizerKetoWarden).Authorize\n\t/go/src/github.com/ory/oathkeeper/proxy/authorizer_keto_warden.go:130\ngithub.com/ory/oathkeeper/proxy.(*RequestHandler).HandleRequest\n\t/go/src/github.com/ory/oathkeeper/proxy/request_handler.go:147\ngithub.com/ory/oathkeeper/proxy.(*Proxy).Director\n\t/go/src/github.com/ory/oathkeeper/proxy/proxy.go:121\ngithub.com/ory/oathkeeper/proxy.(*Proxy).Director-fm\n\t/go/src/github.com/ory/oathkeeper/cmd/serve_proxy.go:219\nnet/http/httputil.(*ReverseProxy).ServeHTTP\n\t/usr/local/go/src/net/http/httputil/reverseproxy.go:197\ngithub.com/urfave/negroni.Wrap.func1\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:46\ngithub.com/urfave/negroni.HandlerFunc.ServeHTTP\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:29\ngithub.com/urfave/negroni.middleware.ServeHTTP\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:38\ngithub.com/urfave/negroni.middleware.ServeHTTP-fm\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:38\ngithub.com/ory/x/metricsx.(*MetricsManager).ServeHTTP\n\t/go/pkg/mod/github.com/ory/[email protected]/metricsx/middleware.go:207\ngithub.com/urfave/negroni.middleware.ServeHTTP\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:38\ngithub.com/urfave/negroni.middleware.ServeHTTP-fm\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:38\ngithub.com/meatballhat/negroni-logrus.(*Middleware).ServeHTTP\n\t/go/pkg/mod/github.com/meatballhat/[email protected]/middleware.go:136\ngithub.com/urfave/negroni.middleware.ServeHTTP\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:38\ngithub.com/urfave/negroni.(*Negroni).ServeHTTP\n\t/go/pkg/mod/github.com/urfave/[email protected]/negroni.go:96\ngithub.com/rs/cors.(*Cors).Handler.func1\n\t/go/pkg/mod/github.com/rs/[email protected]/cors.go:207\nnet/http.HandlerFunc.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:1964\nnet/http.serverHandler.ServeHTTP\n\t/usr/local/go/src/net/http/server.go:2741\nnet/http.(*conn).serve\n\t/usr/local/go/src/net/http/server.go:1847\nruntime.goexit\n\t/usr/local/go/src/runtime/asm_amd64.s:1333" writer=JSON time="2019-03-11T14:15:13Z" level=info msg="completed handling request" measure#oathkeeper-proxy.latency=9067300 method=GET remote="172.22.0.1:36742" request=/api/dummies status=403 text_status=Forbidden took=9.0673ms

Sending request with Postman App,
{ "error": { "code": 403, "status": "Forbidden", "message": "Access credentials are not sufficient to access this resource" } }

Anyone have any idea why this is happening? All configurations are correct (based on the latest full stack example) and the error message does not provide a clear motive.

Thanks 👍