IdentityServer4 nginx proxy_pass

Created on 13 Nov 2018  路  9Comments  路  Source: IdentityServer/IdentityServer4

Hi!
Guys help solve the problem! I am trying to work with identity Server 4 via nginx proxy_pass.

I've got some services: auth.service (identityServer), service.backend, service.site(asp.net mvc client).
auth.service host on localhost:5000, service.backend on localhost:6000, service.site on localhost:6001.

I want proxy to 80 port. The result should be as follows: http://localhost/auth , http://localhost/backend, http://localhost/ (site)

This is my nginx.conf

```events {
}

http {
server { # simple reverse-proxy
listen 80;
server_name droplet;

     location /backend/ {
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_pass http://droplet:6000/;
     }

     location /auth/ {
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_pass http://droplet:5000;
     }

     location /signin-oidc/ {
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_pass http://droplet:6001/signin-oidc;
     }

     location / {
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header   Upgrade $http_upgrade;
        proxy_set_header   Connection keep-alive;
        proxy_set_header   Host $host;
        proxy_cache_bypass $http_upgrade;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto $scheme;
        proxy_pass http://droplet:6001;
     }

 }

}
```
Then I try to switch to a protected resource. I am redirected to the login page. It's OK. I enter my username and password, click login. It's OK.

The authorization server then redirects me to http://myhost/signin-oidc. And here I get the error!

Correlation failed

I started watching what was happening!
It turns out that the request POST http://myhost/signin-oidc return http code 301 and immediately GET request to the same path.

What am I doing wrong?

Most helpful comment

@eaba I updated the ConfigMap yaml and applied the changes, then I deleted the ingress controller pods to force them to reload with the new config. To verify my changes took effect, I tunneled into one of the ingress pods and looked at nginx.conf.

Other things you may want to consider when running an ASP.NET Core app behind a reverse proxy.

  • Add the forward headers middleware to your HTTP Pipeline in Startup.cs
  • If you are using TLS termination at the reverse proxy, your Identity Server will think it is operating in an HTTP context. Thus, the discovery page will return HTTP urls. You need to set the HTTP Pipeline context to use HTTPS.

All of these issues were preventing Identity Server from working for me when deployed in AKS.

I wrote up a blog post here for this issue.

All 9 comments

This seems to be a general question about IdentityServer - not a bug report or an issue.

Please use one of the our free or commercial support options

See here for more details.

Thanks!

Did you ever manage to resolve this issue ?
We are hitting the same issue with http2 / nginx / ID4

For future reference, our issue was that the default settings for header sizes in nginx were too small.

This worked for us:

    proxy-buffer-size: "128k"
    proxy-buffers: "4 256k"
    proxy-busy-buffers-size: "256k"
    large-client-header-buffers: "4 16k"
    client-header-buffer-size: 64k
    http2-max-field-size: 16k
    http2-max-header-size: 128k
    large-client-header-buffers: 8 64k

@Vandersteen how did you apply those settings? Annotation? ConfigMap? Please provide sample
Additionally, did you get https working on the backend? In my own case, the ingress keeps sending http traffics to the back end and when I tried enforcing https traffics, I kept getting 502 errors.
Thanks

nginx-ingress terminates ssl
services / deployments / pods use http (In some apps we make use of the ForwardedHeaders.Proto & From)

I apply'd these configurations in the configmap

I apply'd these configurations in the configmap

Further supporting this statement, some of the configuration options aren't accessible via annotations. It has to be done with a ConfigMap.

@lenardchristopher and @Vandersteen please can you show how you were able to apply the configuration in the configmap?
I tried same but nginx conf is not being updated

@eaba I updated the ConfigMap yaml and applied the changes, then I deleted the ingress controller pods to force them to reload with the new config. To verify my changes took effect, I tunneled into one of the ingress pods and looked at nginx.conf.

Other things you may want to consider when running an ASP.NET Core app behind a reverse proxy.

  • Add the forward headers middleware to your HTTP Pipeline in Startup.cs
  • If you are using TLS termination at the reverse proxy, your Identity Server will think it is operating in an HTTP context. Thus, the discovery page will return HTTP urls. You need to set the HTTP Pipeline context to use HTTPS.

All of these issues were preventing Identity Server from working for me when deployed in AKS.

I wrote up a blog post here for this issue.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings