Troubleshooting Certificate Issues

For the past few days, we’ve been working on SAML 2.0 interoperability with OIOSAML and had to dig pretty deep to troubleshoot some issues we were running into. OIOSAML is an implementation of a SAML 2.0 compliant service provider for Java and J2EE applications which runs on Apache Tomcat. The issue wasn’t rocket science; however if we could not resolve it, federated authentication couldn’t be enabled for this application. The only error on the SP was:

Stack Trace:

Caused by: dk.itst.oiosaml.sp.model.validation.ValidationException: The response is not signed correctly

at com.sf.sfv4.authentication.saml2.extend.SFSAML2Response.validateResponse(SFSAML2Response.java:97)

at com.sf.sfv4.authentication.saml2.SFSAML2AssertionConsumerHandler.handleSAMLResponse(SFSAML2AssertionConsumerHandler.java:392)

... 45 more

A Google search on the error provided some possible leads to what the problem could be. However, one would immediately assume the issue was within the signing certificate due to the error. Yes, but you’d have to prove it.

When the SP consumes the SAMLResponse from an issuing IDP, the SP checks the IDP metadata file for a valid issuer; or Entity Id. This value should is stored in the local .xml of an STS within the EntityDescriptor element under the Entity ID attribute. For example, when publishing federation metadata in ADFSv2, these values are within the first element:

+ <EntityDescriptor wsu:Id="8e0d3ee9-0865-49c7-9c05-c8c64399757f" entityID="https://xxx.xxxx.com/Trust" xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

Understanding what happens under the hood helps extremely in troubleshooting problems. When an SP (RP-STS) consumes an incoming SAMLResponse, it checks its policy store for a valid entity id, which then tells the token issuance service which certificate to validate the authenticity of the message by digital signature within the response or assertion sections of the SAML token.

However, in my scenario we never exchanged federation metadata other than manually providing parameters because the delivery method was IdP-initiated POST binding; therefore we had to prove the signature was bad. To do so, we basically wrote an application and published it as an RP to our IP-STS. The core functionality of signing an XML document can be referenced in Rebecca Croft’s blog, Apollo Jack using the System.Security.Cryptography namespace and System.Security.Cryptography.XML.

The SAMLResponse you consume can be displayed in a simple web form which you can write code to validate the SAML formatting and digital signature. The message will be encoded in Base64, therefore you’d need to decode it then check the signature.

To decode the message, you can use this method:

   1: public static String decodeMessage(string samlResponse)

   2:         {          

   3:             byte[] encodedDataAsBytes = System.Convert.FromBase64String(samlResponse);

   4:             string decodedSAMLResponse = System.Text.Encoding.UTF8.GetString(encodedDataAsBytes);

   5:             return decodedSAMLResponse;

   6:         }

To check a signature, you’d use the public key portion of the signing certificate and the SignedXml.CheckSignature method. From there, you can be insured your signing certificates should be validated on the RP side.