Authentication Does Not Do A Return Trip on Challenge, Just Shows Current User Profile Page

Question

I am doing WS-Federation Authentication using OWIN against a ForgeRock server and when upon a request it does this middleware step to determine whether a user is authenticated, determines, no, and attempts to .Challenge:

//    IOwinContext, Func<Task>
app.Use(context, continuation) =>
{
   if (context.Authentication.User?.Identity?.IsAuthenticated ?? false) return continuation();
   else
   {
       context.Authentication.Challenge("MyAuthenticationOperationName"); // Auth InstanceName
       return Task.Delay(0);
   }
}

When the .Challenge is called, it goes to the Server, the server just displays a "User Profile" page with my username/email etc (the cliams). I am expecting a return where the user is Authenticated and I can extract claims...but that is not happening.

Why?

---

Code based off of this answer OWIN Authentication Pipeline To Use Katana Middleware Correctly?.

---

Unclear whether to ask a corresponding question, but in debug mode I see multiple lines of these in the debug output where the each .js files is different:

Could not read source map for https://{MyForgeRockServer}/sso/XUI/main.be0f90f3fb.js: Unexpected 503 response from https://{MyForgeRockServer}/sso/XUI/main.be0f90f3fb.js.map: unable to verify the first certificate Could not read source map for https://{MyForgeRockServer}/sso/XUI/13.1579ea987b.js: Unexpected 503 response from https://{MyForgeRockServer}/sso/XUI/13.1579ea987b.js.map: unable to verify the first certificate Could not read source map for https://{MyForgeRockServer}/sso/XUI/370.20a02fe45c.js: Unexpected 503 response from https://{MyForgeRockServer}/sso/XUI/370.20a02fe45c.js.map: unable to verify the first certificate ...

See comment as to why this section is not to be considered related to the issue

Watters

those errors are about debug files. You should only see those when running in VS. (VS generates it's own version of your JS files along with .map files so you can put in breakpoints.) Safe to ignore. – Oaken

Updated answer. What I am seeing in another project which uses WIF with similar parameters is that I am not using the authenticate attribute like it is; hence no direct challenge call as I have above. I am going to add that to my test project to see if it handles differently. – Seligman

Thinking about it more, it is kind of interesting that it's a certificate error. Might be worth looking into why your self-signed certificate isn't being verified locally. Seems like that should automatically be added when you run locally. – Oaken

My initial thought was that these occur as a token's claims are being attempted, but haven't found a smoking gun to that affect. – Seligman

not a token thing... this is ssl/cert. – Oaken