Closed rh1984 closed 5 years ago
For a multi-tenant setup do you have more than one instance of OpenIdConnect configured? If so, did you give them unique CallbackPath's? That's required to disambiguate.
I only have one openidconnect configured. The multi tenant logic is kept in the events for that scheme since those configurations are contextual to the tenant using the portal. Again though, we DO have a cookie scheme configured as well, but that shouldn't make a difference right?
Using cookie auth is fine.
The ordering of that error doesn't make sense, the correlation cookie is checked long before any of those other events. Are you sure it's the same request? Is it possible that the request is finishing but then redirecting back to /signin-oidc again? A Fiddler trace would show that.
You're right that the behavior and order seems to indicate that it's redirecting back to /signin-oidc twice. I had that in mind, but couldn't find anywhere in the code that would be happening. I put a breakpoint in the signin-oidc method in the MVC controller and it didn't hit it even the "first" time it would have happened after the successful auth.
I'll troubleshoot it in Fiddler, though, to confirm at least something might be loading signin-oidc twice in some way, whether it's a redirect or some other weird bug.
I put a breakpoint in the signin-oidc method in the MVC controller
?? There should not be a signin-oidc method on your MVC controller, that path should only be handled by the middleware directly.
Aha. It looks like what I was doing was incorrectly setting the "RedirectUri" to /signin-oidc in the ChallengeResult() call of the signin method. I had confused that with the CallbackPath in the configuration. So, it was calling back /signin-oidc, and then redirecting to /signin-oidc, resulting in the error.
And, yes, I've removed the signin-oidc handler from the MVC controller. That was a misunderstanding on my part. Thanks for your help!
Hi, all,
I have a perplexing issue and it's difficult for me to determine if it's a bug with my code or a bug in the authentication layer.
Long story short, we have a multi-tenant setup where different tenants might opt-in to using OpenID via AzureAD. The rest usually just use a cookie-based setup where we handle the users. We are using ASP.NET Core 2.1 on Service Fabric with Kestral.
So, as such, we have things set up so that the cookie auth scheme "falls back" to OpenID auth using AzureAD. I also am using Microsoft Graph API to get group information. So, the workflow is an admin to both our portal and their own AzureAD logs into our portal, enters their tenant id, and then "signs up," granting the permissions to connect their AzureAD to our AD app, and from that point on, users can authenticate via SSO.
Here's the perplexing thing: If a user grants access and/or signs in, everything appears to work:
OnAuthenticationCodeReceived gets hit with the access token OnTokenResponseReceived gets hit I get the principal filled in with the proper info The Microsoft Graph API gets the group information just fine using the access token
Then after all the "hard" stuff is figured out and the user is authenticated, my breakpoint hits the OnRemoteFailure() with the "Correlation Failed" exception.
Only thing is, the user's still signed into the site, and I still can access the Graph API using the token provided during that whole setup. It's as if I could even "ignore" this exception and pretend it didn't happen, and the user would have a decent experience.
From what I've read "Correlation Failed" is one of those exceptions that has many possible causes, and I've ruled out several:
The ClientID and Secret are correct. I've verified that the RedirectUri matches correctly, including ensuring it is using HTTPS I'm using a fully trusted and verified SSL certificate The Instance is https://login.microsoftonline.com The RemoteAuthenticationTimeout is set to 1 hour I've verified that the tenant I'm signing in with is correct I've tried using incognito mode I've cleared the cache of all auth tokens in case there was some old token being used This is happening locally with a single node so there shouldn't be any load balancer-related or backplane-related issues (although we do also have that covered AFAICT anyways)
At this point I'm out of ideas. I find it strange that the authentication works fine except for this one error.