In a project to evaluate a variety of different identity providers, I have a code base that has already successfully authenticated with Azure AAD and Okta using WsFederation Owin package. The next one up on the eval list is an internally hosted ADFS. As was true with the first two:
I get to the idp login page,
login,
get sent back to the host (running locally) with a POST with form variables including the RequestSecurityTokenResponse in wtresult form variable.
An external login cookie is issued
my ExternalLoginCallback function is called
what is different is here:
var loginInfo = await AuthenticationManager.GetExternalLoginInfoAsync();
if (loginInfo == null)
{
return RedirectToAction("Login");
}
loginInfo is null. Here are the potential clues I have yet to decipher. If I don't set
app.UseExternalSignInCookie(DefaultAuthenticationTypes.ExternalCookie);
in my startup, I get a authenticated claims identity in User.Identity. However there is no username, name or role claims in this identity. If compare the tokens returned from Okta and ADFS, there are two differences. Both have upn, name and role claims but the ADFS claims are SAML 1.0 assertions where the Okta are SAML 2.0. The other difference is that ADFS signature method is sha265 where Okta is sha1.
Could these differences cause my problem? The people configuring ADFS aren't aware of a way to specify these things, can WsFederation middleware be configured to either request something specific or use what ADFS is using?
The answer to this has been found. The saml nameid claim type needs to be added to ADFS for the OWIN middleware to pick this up as a valid external login. Thanks to this article that pointed out the details.
http://darb.io/blog/2014/06/30/WebAPI-and-ADFS-as-external-login-provider/