IdentityServer and Blazor

Rhywden

So, I got an IdentityServer running. It works in development and it also works in production. When I use Postman to get an auth token, I get the expected result. The production server is running behind a reverse proxy. Https is enabled and the cert is valid.

Then I wanted to wire the whole thing into a Blazor Server project. And that somehow yields no results and I don't even know what exactly is going wrong because the stack trace is "helpful" and does not actually tell me what it objects to exactly. See for yourself:

The thing is that I'm damn sure that the adress I've provided actually is a valid https scheme. But I cannot check that because "System.String", not the actual value (that's soooooooo helpful!)

So, anybody have a clue where I can intercept that whole thing? Because when I try to step through starting at the Login, the whole thing throws but does not actually allow me to see anything...

Kamil Podlesak

@Rhywden said in IdentityServer and Blazor:

The thing is that I'm damn sure that the adress I've provided actually is a valid https scheme. But I cannot check that because "System.String", not the actual value (that's soooooooo helpful!)

Unless the value is actually "System.String" string, due to some WTF in configuration parsing. Unlikely, but possible - it already happened to me few times.

Rhywden

@Kamil-Podlesak Well, I cannot be sure because I don't know where to set a breakpoint to see the actual context variables. As I said, I set a breakpoint at the Login model, said breakpoint gets hit when I click on "Login", I go through the app step by step but then it simply jumps to the exception.

Kamil Podlesak

@Rhywden said in IdentityServer and Blazor:

@Kamil-Podlesak Well, I cannot be sure because I don't know where to set a breakpoint to see the actual context variables. As I said, I set a breakpoint at the Login model, said breakpoint gets hit when I click on "Login", I go through the app step by step but then it simply jumps to the exception.

You can set breakpoint on exception. Or, if not possible, directly in the exception constructor.

Disclaimer: I have never done that in .NET, so I don't know if there is any catch... but I know it's no problem in JVM.

Rhywden

@Kamil-Podlesak Just found something very well hidden away:

If you add IdentityModelEventSource.ShowPII = true; to the end of the Configure() method in Startup.cs then you actually get the values. Instead of their type.

Rhywden

@Rhywden And solved it. Finally. The problem was that the server was not picking up properly that it was sitting behind a reverse proxy and thus automatically told everyone that all the endpoints were http. No amount of putzing around with the proxy forwarders helped, in the end a brute force

app.Use(async (ctx, next) =>
            {
                ctx.SetIdentityServerOrigin("https://identity.foo.bar");
                await next();
            });

did the trick.

Tsaukpaetra

@Rhywden said in IdentityServer and Blazor:

the server was not picking up properly that it was sitting behind a reverse proxy

Yeah, late to the party but that would have been my guess.

It's really fun when things like automatic redirects will then get confused at what the URL actually is and try redirecting from https to http because of this exact problem...

Luhmann

@Tsaukpaetra said in IdentityServer and Blazor:

Yeah, late to the party

dkf

@Rhywden said in IdentityServer and Blazor:

The problem was that the server was not picking up properly that it was sitting behind a reverse proxy and thus automatically told everyone that all the endpoints were http.

Thus, System.String in an error message means that the end point is supposed to be https instead of http? That's… not seeming quite intuitive to me. But perhaps it works if the string is [object Object]?

error

@dkf If I'm understanding correctly, System.String is a kind of anonymization to prevent sensitive data from the config from being dumped into the response for everyone to see. It should probably just say [redacted] or something.

dkf

@error If it'd said [redacted] (or B•••••m) then we'd be having a less interesting discussion.

Rhywden

@error Indeed. As I said, you need to set an additional Configuration setting.

Now, why this setting isn't enabled by default when the app is running in Development is anyone's guess.

Tsaukpaetra

@Rhywden said in IdentityServer and Blazor:

@error Indeed. As I said, you need to set an additional Configuration setting.

Now, why this setting isn't enabled by default when the app is running in Development is anyone's guess.

You know why.

Rhywden

@Tsaukpaetra Because their documentation is a mess? Just for once I'd like to see a framework do a flow diagram which shows you which stations a request passes so you have an idea where exactly to put your own custom code to achieve some additional results.

Tsaukpaetra

@Rhywden I was leaning more towards "because people publish to production code built in Development (I assume you meant "Debug") and just shove the result onto a box calling it a day"

dkf

@Rhywden said in IdentityServer and Blazor:

Just for once I'd like to see a framework do a flow diagram which shows you which stations a request passes so you have an idea where exactly to put your own custom code to achieve some additional results.

But the vast majority of people writing the framework probably have no idea. Or can't write. Or both. Both is good.

Rhywden

So, I added a second Client to the server so that a 2nd app could auth against it (which was the whole point of that exercise to begin with!).

Seemed easy enough: The configuration takes an List<Client> which I interpreted as "simply add another entry to it for another client". Did so, gave the 2nd app different client ids, passwords and redirect URIs as it should be and everything worked fine.

Then I put the client into production and everything was not fine. For some reason, and I have no clue as to why, the Identity Server says upon an auth attempt:

Hey, you gave me the credentials for App2 and the id for App2 but I get the redirect URI of App1? No auth for you!

Tried a lot of things but in the end I resorted to a hack which for some godforsaken reason actually works:

I simply plonked the redirect URI of App2 into the list of allowed redir-Uris of App1 and that worked.

The only difference between the ID-server in dev and prod is that whole https-debacle - but that has nothing to do with the actual content of the requests.

And yes, I already checked, the creds for App1 are referenced nowhere in App2.