New in IdentityServer4 v2: Simplified Configuration behind Load-balancers or Reverse-Proxies

Many people struggle with setting up ASP.NET Core behind load-balancers and reverse-proxies. This is due to the fact that Kestrel is often used just for serving up the application, whereas the “real HTTP traffic” is happening one hop earlier. IOW the ASP.NET Core app is actually running on e.g. http://localhost:5000 – but the incoming traffic is directed at e.g. https://myapp.com.

This is an issue when the application needs to generate links (e.g. in the IdentityServer4 discovery endpoint).

Microsoft hides the problem when running in IIS (this is handled in the IIS integration), and for other cases recommends the forwarded headers middleware. This middleware requires some more understanding how the underlying traffic forwarding works, and its default configuration does often not work for more advanced scenarios.

Long story short – we added a shortcut (mostly due to popular demand) to IdentityServer that allows hard-coding the public origin – simply set the PublicOrigin property on the IdentityServerOptions. See the following screenshot where I configured the value https://login.foo.com – but note that Kestrel still runs on localhost.

publicOrigin.png

HTH

This entry was posted in ASP.NET Core, IdentityServer, Uncategorized, WebAPI. Bookmark the permalink.

12 Responses to New in IdentityServer4 v2: Simplified Configuration behind Load-balancers or Reverse-Proxies

  1. Eirik M says:

    Any difference between the PublicOrigin property in v3 and the one in v4?

  2. No – it only solves one specific problem

    • Eirik M says:

      Sorry, my bad. What I meant is that independent of the PublicOrigin property developers should use the load balancer’s address when setting up the allowed CORS, redirect and logout redirect urls, shouldn’t they?

  3. robrich says:

    PublicOrigin is perfect for the IdentityServer side. For a hybrid-flow MVC client in another docker container, how do I setup the back-channel to use http://identity:5000/ and browser redirects to use http://localhost:5000/ ? Is this done with HttpOverrides middleware before OpenIdConnect middleware?

  4. Patrick says:

    Works perfectly except in one case.
    In the views that are graciously offered by your team, we have in the HomeController’s the following :

    Click here to manage your stored grants.

    The ~/grants causes a generation of the wrong URL, http://xxx.com/account/login?returnUrl=%2Fgrants, instead of https://xxx.com/account/login?returnUrl=%2Fgrants

    I assume this is because in the configuration of Kestrel it knows it is set up for HTTP and thus generates the URL in http. Is there an option I can set where the IdentityServer overrides this and sets it to HTTPS?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s