Question: Need different domains from metadata response

[esumerfd]

Due to some unfortunate infrastructure we have the server hosted on one domain and the Cypress browser accessing it from another domain.

Dotnet allows me to specify a URL to get the metadata but that response needs to contain url that the browser can use.

http://auth0sim:5070/.well-known/openid-configuration

response:

{
issuer: "http://localhost:5070/.well-known/openid-configuration",
authorization_endpoint: "http://localhost:5070/.well-known/openid-configuration/authorize",
...

[ybelMekk]

Hello @esumerfd

Did you try to set/export SERVER_HOSTNAME environment variable when starting up the mock-oauth2 container?

example docker-compose.yml

version: '3.7'
services:
  mock-oauth2-server:
    image: mock-oauth2-server
    environment:
      PORT: 8080
      LOG_LEVEL: DEBUG
      SERVER_HOSTNAME: oauth2
    ports:
      - 8080:8080
    hostname: oauth2

[jksolbakken]

The server should use the Host (or the x-forwarded-for) header if it is present to construct the issuer. Does your HTTP client set the Host header? Which version of the mock-oauth-server are you using, btw?

[esumerfd]

Hi @ybelMekk, the SERVER_HOSTNAME doesn't change the endpoints in the response to .well-known/openid-configuration. I assume this is to limit the IP the server listens to?

@jksolbakken, the headers parsing is interesting but since the browser is receiving the endpoint as part of the redirect to the simulator, how would I add these headers?

The Host header would be set by the browser (cypress) to the domain in the request, which in our case is defined by the well-known authorization endpoints.

The x-forwarded-for is part of a proxy protocol isn't it? I am not clear where it would be set/added to the request. I think this means I would have to make my web server (Kestral) connect through a proxy, so the headers would be added to the well-known endpoint?

I think what I need is a way to override the default behavior of "use requesting domain in well known endpoints". Perhaps a WELL_IKNOWN_DOMAIN environment variable passed in on startup?

[jksolbakken]

My bad, I misread your question and thought you were making the requests from your Dotnet code. I can't get the SERVER_HOSTNAME thing to work, there's something fishy going on with that. We'll try to set aside some time to look into this next week.

[ybelMekk]

@jksolbakken did you digg in to this?

[ybelMekk]

@esumerfd are you using the latest version og mock-oauth2-server?

Could you also provide your setup for the server for me, so I try to reproduce it locally.

[esumerfd]

Very stock: json='{"interactiveLogin": true}' docker run -e SERVER_PORT=5070 -e JSON_CONFIG="$json" -p 5070:5070 stackct.azurecr.io/docker/auth0sim:latest

…

On Fri, Nov 4, 2022 at 5:44 AM Youssef Bel Mekki ***@***.***> wrote: @esumerfd <https://github.com/esumerfd> are you on the latest version og mock-oauth2-server? — Reply to this email directly, view it on GitHub <#362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAHP5C4SMTLJ6H73NS2BGLWGTLHBANCNFSM6AAAAAARPHGEP4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ybelMekk]

@esumerfd

Can you try to run your setup like this:

json='{"interactiveLogin": true}'
docker run  --hostname auth0sim  -e SERVER_HOSTNAME=auth0sim -e SERVER_PORT=5070 -e JSON_CONFIG="$json" -p 5070:5070

run your request with host header Host: auth0sim

http://auth0sim:5070/.well-known/openid-configuration

[esumerfd]

Thanks for taking a look at this Youssef. Here are some tests to help. Specific live use case. DotNet MVC makes this request to Auth0 like this: GET https://auth0sim:5070/.well-known/openid-configuration HTTP/1.1 Host: auth0sim:5070 User-Agent: Microsoft ASP.NET Core OpenIdConnect handler Running mock-oauth2-server with hostname and SERVE_HOSTNAME parameters. docker run --hostname auth0sim -e SERVER_HOSTNAME=auth0sim -e SERVER_PORT=5070 -p 5070:5070 ghcr.io/navikt/mock-oauth2-server:0.5.4 Request: Shows that neither the docker hostname nor the SERVER_HOSTNAME drive the choice of metadata domain. : curl http://localhost:5070/.well-known/openid-configuration { "issuer" : "http://localhost:5070/.well-known/openid-configuration", Request: Adding a Host header to the request does change the response metadata domain. Unfortunately we don't have control over how the DotNet MVC Identity framework submits this request. : curl -H "Host: foo:5070" http://localhost:5070/.well-known/openid-configuration { "issuer" : "http://foo:5070/.well-known/openid-configuration", Requirement: I need to be able to specify which metadata domain is returned to DotNet MVC so that the redirect returned to the browser can direct the user to the correct place.

…

On Sun, Nov 6, 2022 at 6:49 PM Youssef Bel Mekki ***@***.***> wrote: Can you try to run your setup like this: json='{"interactiveLogin": true}' docker run --hostname auth0sim -e SERVER_HOSTNAME -e SERVER_PORT=5070 -e JSON_CONFIG="$json" -p 5070:5070 run your request with host header Host: auth0sim http://auth0sim:5070/.well-known/openid-configuration — Reply to this email directly, view it on GitHub <#362 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAHP5EDTY4KDPRCMCNCM7DWHA7W7ANCNFSM6AAAAAARPHGEP4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[ybelMekk]

@esumerfd so in short you need a way to set metadata response from server at startup, not do this with the host header? 😄

[esumerfd]

Thats it. Much simpler way of saying it. :-)

[ybelMekk]

Ive been testing some more, and the mock-oauth-server works as intended and in your example over you say that DotNet MVC specifies Host header.

GET https://auth0sim:5070/.well-known/openid-configuration HTTP/1.1
Host: auth0sim:5070
User-Agent: Microsoft ASP.NET Core OpenIdConnect handler

[esumerfd]

yes. The problem being that the domain name exposing auth0sim to the webserver is a different than the domain name exposing the auth0sim to the browser, so when the redirect occurs to /authorize the browser can not connect.

The mock servers feature of use-the-requesting-domain-name is great for simple environments where the browser, web server and mock server are on the same network.

I have the webserver and mock server deployed as containers to k8s but the browser (cypress) is deployed to a VM outside the k8s network.

[tommytroen]

@esumerfd Hi. Late to the party here but have read through the issue now.

As you are running the containers in k8s - have you tried calling the mock server from the webserver via ingress (not via service discovery)? If you use an ingress both in container to container communication as well as from the VM hosting the browser you should get the same host in all urls.

[mrsladek]

@ybelMekk The problem with Host header is that it is not longer supported to change it since JDK 12 (https://bugs.openjdk.org/browse/JDK-8213696).

Would it be possible to fix host of the metadata (or only the issuer) to a particular value with a config parameter? I think it would be necessary in this kind of scenarios.

[ybelMekk]

@ybelMekk The problem with Host header is that it is not longer supported to change it since JDK 12 (https://bugs.openjdk.org/browse/JDK-8213696).

Would it be possible to fix host of the metadata (or only the issuer) to a particular value with a config parameter? I think it would be necessary in this kind of scenarios.

It sounds useful yes, but the container, when requesting metadata e.g. a call to curl http://oauth2:8080/default/.well-known/openid-configuration gives:

{
  "issuer" : "http://oauth2:8080/default",
  "authorization_endpoint" : "http://oauth2:8080/default/authorize",
  "end_session_endpoint" : "http://oauth2:8080/default/endsession",
  "token_endpoint" : "http://oauth2:8080/default/token",
  "userinfo_endpoint" : "http://oauth2:8080/default/userinfo",
  "jwks_uri" : "http://oauth2:8080/default/jwks",
  "introspection_endpoint" : "http://oauth2:8080/default/introspect",
  "response_types_supported" : [ "query", "fragment", "form_post" ],
  "subject_types_supported" : [ "public" ],
  "id_token_signing_alg_values_supported" : [ "ES256", "ES384", "RS256", "RS384", "RS512", "PS256", "PS384", "PS512" ]
}

then you call the jwks endpoint: curl http://oauth2:8080/default/jwks
you will get some data, but if you say change the well known metadata issuer to: yolo

you'll get what you want

{
  "issuer" : "http://yolo:8080/default"
......

but a curl to "http://yolo:8080/default" will give you curl: (6) Could not resolve host: yolo

So host of container and returned metadata must match, but we could set the issuer and metadata issuer to SERVER_HOSTNAME value as specified.