Working with PathBase

I am trying to get the library working on a service that sits behind a gateway that modifies the path. Currently it is redirecting to a /trust/saml/… endpoint and missing the base path. Is there anyway to get the library to work with PathBase?

Thanks,
Kiel

Hi Kiel,

We don’t do anything specifically with PathBase.

Could you provide some more details as to what the issue is and what you’d like to see happen?

Thanks.

[quote]
ComponentSpace - 1/21/2020
Hi Kiel,

We don't do anything specifically with PathBase.

Could you provide some more details as to what the issue is and what you'd like to see happen?

Thanks.
[/quote]

Hi,

Here is more info on base path: https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer?view=aspnetcore-3.1#deal-with-path-base-and-proxies-that-change-the-request-path
We are planing to map auth server behind gateway with URL rewrite like this:

gateway.com/api/auth/[rest of url]

This gateway url is re-written to:

[service-endpoint]/[rest of url]

but when service generated redirects it should obey base path property (/api/auth in this case should be set) and prefix redirect URL with it, it also should utilize .net capabilities to read X-Forwarded-* headers for non relative urls.

currently without base bath Auth service will redirect us to:
gateway.com/[redirect url]

when it should redirect to if base path is used:
gateway.com/api/auth/[redirect url]

Without that capability it is impossible to load balance this service behind any kind of gateway where its not mapped at the root.

Thanks for the extra information. This is something we will look at supporting in a future release.

[quote]
ComponentSpace - 1/22/2020
Thanks for the extra information. This is something we will look at supporting in a future release.
[/quote]

Is there any ETAs on this?

This is currently blocking our SAML flow implementation using this library, we probably can implement dirty request intersections and modifications for some time, but it is not maintainable at the long term.

I’m afraid we don’t have an ETA at this stage. It is on our feature list though.

We have your email address so we’ll contact you with any status updates.

Update: We have dug into the issue and understood that problem was not with a library but rather with IIS rewrite rule we have been using to test.

The problem with this settings in IIS Proxy: https://domainwebcenter.com/wp-content/uploads/2011/11/IIS-ARR-Reverse-Rewrite-Host.png
By default “reverse rewrite host in response headers” is enabled in IIS proxy and when using it it will mess up redirect requests created by application.
So when library was redirecting sign-in request to [quote]…onelogin.com/trust/saml/…[/quote] IIS will change it to [quote]…app.domain/trust/saml/…[/quote]

Once this was disabled we also were able to adjust base path to for app API routes using [quote] context.Request.PathBase = new PathString(“/foo”);[/quote] in the middleware.
Also we have added logic as per MS article to handle X-Forwarded-* headers.

Thanks for getting in touch with us, but this is not a limitation on the library side, but rather implementation issue.

Thanks for the update and including this information.