KentorAuthServicesAuthenticationHandler.CreateErrorAuthenticationTicket - Object reference not set to an instance of an object.

[kb99]

We are getting the following exception intermittently in our Live environment when some clients are logging in from an ADFS Idp.

We cant see what the user experience is when this exception is getting raised or if there is a set of steps to replicate it.

System.NullReferenceException: Object reference not set to an instance of an object.
   at Kentor.AuthServices.Owin.KentorAuthServicesAuthenticationHandler.CreateErrorAuthenticationTicket(HttpRequestData httpRequestData, Exception ex)
   at Kentor.AuthServices.Owin.KentorAuthServicesAuthenticationHandler.<AuthenticateCoreAsync>d__0.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter`1.GetResult()
   at Kentor.AuthServices.Owin.KentorAuthServicesAuthenticationHandler.<InvokeAsync>d__4.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

We are currently using v0.21.2 of Kentor.AuthServices and targeting net462

[AndersAbel]

Looks bad. But the CreateErrorAuthenticationTicket method is not that large, should be possible to pinpoint it.

Can you enable full verbose logging to see if you can get any hints on what's wrong?

[kb99]

We will look to enable verbose logging in Live to try and capture more information if/when the issue occurs again. Might take a little while before I can report back with any detailed findings.

[kb99]

The exception occurred again and here are the logs recorded from AuthServices

Verbose - Extracted ReturnUrl from query string

Verbose

Expanded AuthServicesUrl
  AssertionConsumerServiceUrl: https://mydomain.com/identity/cd0951fc93/Acs
  SignInUrl: https://mydomain.com/identity/cd0951fc93/SignIn
  LogoutUrl: https://mydomain.com/identity/cd0951fc93/Logout
  ApplicationUrl: https://mydomain.com/identity/

Info - Initiating login to http://adfs.idpcompany.com/adfs/services/trust

Verbose - Http POST binding extracted message

<samlp:Response ID="_26a80815-8063-45b6-a2b6-7bda3033adf2" Version="2.0" IssueInstant="2018-03-06T10:30:53.085Z" Destination="https://mydomain.com/identity/cd0951fc93/Acs" 
Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="ida051de0885834a69b52ef62c028bd2dc" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
	<Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://adfs.idpcompany.com/adfs/services/trust</Issuer>
	<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
		<ds:SignedInfo>
			<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
			<ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
			<ds:Reference URI="#_26a80815-8063-45b6-a2b6-7bda3033adf2">
				<ds:Transforms>
					<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
					<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
				</ds:Transforms>
				<ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
				<ds:DigestValue>....</ds:DigestValue>
			</ds:Reference>
		</ds:SignedInfo>
		<ds:SignatureValue>.....</ds:SignatureValue>
		<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
			<ds:X509Data>
				<ds:X509Certificate>.....</ds:X509Certificate>
			</ds:X509Data>
		</KeyInfo>
	</ds:Signature>
	<samlp:Status>
		<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
			<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:RequestDenied" />
		</samlp:StatusCode>
	</samlp:Status>
</samlp:Response>

Verbose - Signature validation passed for Saml Response _26a80815-8063-45b6-a2b6-7bda3033adf2

I can see that the SAML message contains a statusCode of status:RequestDenied instead of an expected code like Success

[kb99]

a second instance of this exception occured this morning and the log messages contained the same information - the SAML message contained a RequestDenied status