ADFS Not Sending All Required Elements in Assertion (SP Initiated)

3
votes

SAML 2.0

I'm trying to help a client figure this out. I do not have access to their ADFS server. I am the Service Provider they are trying to connect to.

IDP initiated SSO is working fine. The client picks our service from the drop-down list and their users log in seamlessly.

SP initiated is failing though. They hit our server, we send the auth request, the user makes their way through ADFS, ADFS POSTs to our ACS URL, and then fails because the assertion does not contain all of the required elements. Conditions, Audience, NameIDPolicy, etc are not there, but Cert and Signature are.

I've googled the crap out of this and can't find anything to share with my client. I am not 100% certain how experienced they are with ADFS and if they have been checking the event logs for errors. Ideas?

Below is the assertion with private info removed: <samlp:Response ID="_2ffc76ad-1691-43-9b3a-0193d8348" Version="2.0" IssueInstant="2014-12-16T20:29:20.070Z" Destination="https://xxxx.com/samldefault.aspx" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_290a5f3-4c68-b101-589a07a02a7c" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" > <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://xxxxxxxx/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="#_2ffc76ad-1691-43f5-9b3a-01936ddd8348" > <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>DPLGDmOWmjpoSdETBsPE=</ds:DigestValue > </ds:Reference > </ds:SignedInfo > <ds:SignatureValue>xxxxxxxx</ds:SignatureValue > <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#" > <ds:X509Data > <ds:X509Certificate>xxxxxxxxx</ds:X509Certificate > </ds:X509Data > </KeyInfo > </ds:Signature > <samlp:Status > <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" / > </samlp:Status > </samlp:Response>

1
samladfs

1 Answers

3
votes

Figured this out. The client looked through their server logs and found this:

Log Name:      AD FS/Admin
Source:        AD FS
Date:          12/17/2014 3:53:30 PM
Event ID:      303
Task Category: None
Level:         Error
Keywords:      AD FS
User:          AD\adfssvc
Computer:      ADFS01.ad.he-equipment.com
Description:
The Federation Service encountered an error while processing the SAML authentication request.

Additional Data
Exception details:
Microsoft.IdentityModel.Protocols.XmlSignature.SignatureVerificationFailedException: ID4037: The key needed to verify the signature could not be resolved from the following security key identifier     'SecurityKeyIdentifier

Either from their configuration, or by default in ADFS, they needed to import our public certificate. It seems illogical that ADFS would pass the user through to the Service Provider with an incomplete SAML assertion due to it requiring a certificate. However, it works now.