Invalid message format means that something in the assertion is not recognized. This can occur when the attributes are not recognized or there is key information missing in the assertion.

In order to work towards a resolution, you will need to collect an assertion and analyze it for missing parameters. You can recreate the issue in Firefox and use SAML Tracer or SSO Tracer.

Once you have collected the assertion compare it with the example assertion below. If nothing sticks out, please provide it to development with the other relevant data.

There are a few instances in which this can occur, most prominently this occurs when the attributes for email, firstname and lastname are wrong. Often times you will see attributes with names such as mail, givenname, name, etc. These will need to be adjusted to reflect as Email FirstName and LastName in the assertion. Here is an example failed assertion:

<saml2:Attribute FriendlyName="mail" 
Name="" 
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
         <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:type="xs:string">john.smith@internet.com</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute FriendlyName="sn" 
Name="" 
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
         <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:type="xs:string">Smith</saml2:AttributeValue>
      </saml2:Attribute>
      <saml2:Attribute FriendlyName="givenName" 
Name="" 
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
         <saml2:AttributeValue xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:type="xs:string">John</saml2:AttributeValue>
      </saml2:Attribute>
   </saml2:AttributeStatement>

The highlighted items above will need to be adjusted to Email, LastName and FirstName.

All certificates have a validity period, this is designated by the creating party, which could be a Cert Authority such as Thawte or GlobalSign or can be created by the customer. This error presents itself when the cert has not come into its validity period as of yet. Check the validity dates of the certificate and make sure that it is valid for the necessary time period.

Similar to the previous error, this refers to the validity period of a certificate. Certificates generally have an expiration date and most companies change them yearly. The user would get this error if the certificate has expired. This would require that we are sent an updated one and upload the new one into the account.

This is a pretty common error that's easy to identify. As the name implies, this error means that the email you are providing is not the same as the one you are typing in. The email that you type in at the Central login page must be the same as the email in the: assertion.

Here's an example assertion containing email:

<Conditions NotBefore="2015-03-11T20:22:12.093Z"
                   NotOnOrAfter="2015-03-11T21:22:12.093Z">
           <AudienceRestriction>
               <Audience>https://accounts.logme.in</Audience>
           </AudienceRestriction>
       </Conditions>
       <AttributeStatement>
           <Attribute 
Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
               <AttributeValue>Justin</AttributeValue>
           </Attribute>
           <Attribute Name="">
               <AttributeValue>Bell</AttributeValue>
           </Attribute>
           <Attribute Name="">
               <AttributeValue>jbell@logmeinse.com</AttributeValue>
           </Attribute>
       </AttributeStatement>
       <AuthnStatement AuthnInstant="2015-03-11T20:22:12.077Z">
           <AuthnContext>
               <AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef>
           </AuthnContext>
       </AuthnStatement>
   </Assertion>

Make sure that the emails match.

Certificate is not the same as the one being passed by IDP. Make sure certificates match, capture from customer or metadata xml file and re-upload.

SAML attributes missing, make sure customer has proper rules configured on IDP side. Investigate assertion make sure FirstName, LastName and Email are being provided.

Variables present for FirstName, LastName, and Email, but are provided blank with no data. Investigate assertion and rules on IDP side.

Email attribute missing in assertion. Investigate assertion and rules on IDP side.

Generally caused by timeout, this can occur if user starts login process, then does not complete and tries later. Have them try entire login process from start to finish with no pauses in-between.

Make sure certificate uploaded into the account matches certificate being provided by IDP. Capture certificate directly from customer, IDP or metadata xml file.

Cannot parse response, check to make sure assertion is coming through properly. Capture assertion and investigate what may be missing. Make sure assertion is actually being passed. At times rules not present on IDP side can cause assertion to not even trigger.

Missing federation message, proper data not being supplied in assertion. Capture assertion and investigate what may be missing.

SAML token used previously. Happens when a refresh of the page sends the same assertion twice.