We are having a problem transitioning from AD FS 2.0 to AD FS 3.0.
We have an ASP.NET MVC application which uses federated authentication through AD FS. In our test environment we have Thinktecture Identityserver 2 configured as a claims provider in AD FS. The application requests authenticationType="urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI"
. For reference, here is the entire identity section of our web.config file:
<system.identityModel>
<identityConfiguration>
<claimsAuthenticationManager type="ProjectName.Authorization.AuthenticationManager, ProjectName" />
<claimsAuthorizationManager type="ProjectName.Authorization.AuthorizationManager,ProjectName" />
<audienceUris>
<add value="https://applicationdomain/" />
</audienceUris>
<securityTokenHandlers>
<securityTokenHandlerConfiguration saveBootstrapContext="true">
<issuerNameRegistry type="System.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, System.IdentityModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<trustedIssuers>
<add thumbprint="(thumbprint of ADFS certificate)" name="ADFS Test" />
</trustedIssuers>
</issuerNameRegistry>
</securityTokenHandlerConfiguration>
</securityTokenHandlers>
</identityConfiguration>
</system.identityModel>
<system.identityModel.services>
<federationConfiguration>
<wsFederation freshness="120" passiveRedirectEnabled="true" issuer="https://adfsdomain/adfs/ls" realm="https://applicationdomain/" requireHttps="true" authenticationType="urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI" />
<serviceCertificate>
<certificateReference findValue="(thumbprint of application's certificate)" storeLocation="LocalMachine" storeName="My" x509FindType="FindByThumbprint" />
</serviceCertificate>
<cookieHandler requireSsl="true" />
</federationConfiguration>
</system.identityModel.services>
We are currently running on somewhat outdated servers with Windows Server 2008 R2 and AD FS 2.0, but it works. We have recently set up a new environment of servers running Windows Server 2012 R2 and AD FS 3.0. We have installed our MVC application on a new server, and set up AD FS 3.0 on another, configured like the old AD FS 2.0 (as far as we can tell) with the MVC app as a relying party and Thinktecture Identityserver 2 as a claims provider. One difference is that we are now using an AD FS Proxy on a separate server, since AD FS 3.0 requires this (whereas AD FS 2.0 did not). In fact we have two AD FS servers, and then two proxies behind a load balancer. Thinktecture Identityserver 2 is still running on an old server (on Windows Server 2008 R2).
Here is the problem: I browse to the application's address. I get redirected to AD FS as expected, which promptly redirects me to Thinktecture Identityserver 2. So far so good. I log in with a user name ("Anders") and password and get redirected back to AD FS. Here I get a general error page saying "An error occured". In the event log on the AD FS server (the load balancer apparently always directs me to the same node, which happens to be the primary) I find two errors and one warning. First error:
Event 197, AD FS
The Federation Service could not satisfy a token request because the
accompanying credentials do not meet the authentication type requirement of
'urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI' for the relying party
'https://applicationdomain.no'.
Authentication type:
Desired authentication type(s): urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI
Relying party: https://applicationdomain.no
This request failed.
Then the warning:
Event 1000, AD FS
An error occurred during processing of a token request. The data in this event
may have the identity of the caller (application) that made this request. The
data includes an Activity ID that you can cross-reference to error or warning
events to help diagnose the problem that caused this error.
Additional Data
Caller: Anders
OnBehalfOf user:
ActAs user:
Target Relying Party: https://applicationdomain.no
Then the second error:
Event 364, AD FS
Encountered error during federation passive request.
Additional Data
Protocol Name:
wsfed
Relying Party:
Exception details:
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.InvalidAuthenticationTypePolicyException: Exception of type 'Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.InvalidAuthenticationTypePolicyException' was thrown.
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityModel.SecurityTokenService.SecurityTokenService.EndIssue(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.SubmitRequest(MSISRequestSecurityToken request, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.RequestBearerToken(MSISRequestSecurityToken signInRequest, Uri& replyTo, IList`1& identityClaimCollection)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.RequestBearerToken(MSISSignInRequestMessage signInRequest, SecurityTokenElement onBehalfOf, SecurityToken primaryAuthToken, SecurityToken deviceSecurityToken, String desiredTokenType, WrappedHttpListenerContext httpContext, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, MSISSession& session)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSerializedToken(MSISSignInRequestMessage wsFederationPassiveRequest, WrappedHttpListenerContext context, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired)
at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.SendSignInResponseForSecurityToken(GenericProtocolRequest originalRequest, SecurityTokenElement requestedTokenElement, ProtocolContext context)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
I have read about supported SAML Authentication types in AD FS on this page: https://msdn.microsoft.com/en-us/library/hh599318.aspx. SmartcardPKI is not listed here. (Though note that the documentation is for AD FS 2.0.)
On the AD FS servers (both the old and the new) I have tried listing the supported AuthenticationTypes using the following PowerShell command:
get-adfsproperties | select-object -expandProperty AuthenticationContextOrder | select-object -Property AbsoluteUri
Both on the old server and the new this outputs:
urn:oasis:names:tc:SAML:2.0:ac:classes:Password
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient
urn:oasis:names:tc:SAML:2.0:ac:classes:X509
urn:federation:authentication:windows
urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos
No SmartcardPKI here either. Never the less it works in the old environment.
I also tried using PasswordProtectedTransport in place of SmartcardPKI (by editing the MVC application's web.config). The result was exactly the same, except that the first error message now said:
The Federation Service could not satisfy a token request because the
accompanying credentials do not meet the authentication type requirement of
'urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport' for the
relying party 'https://applicationdomain.no'...
Any pointers as to what I should try next would be very welcome. Maybe there are differences between AD FS 2.0 and 3.0 which require me to make configuration changes to Thinktecture IdentityServer 2?