This error typically indicates that you are trying to use Single Sign On with a Standard (Free) Edition of Google Apps, which is not currently supported. If you are certain that you are using Google Apps for Work, Education, or ISPs, check the configuration in your Identity Provider to ensure that you have entered your Apps domain name correctly.

This error indicates that you have not set up Single Sign On correctly in your Apps Control Panel. Please review the following steps to correct the situation:

1. In your Apps Control Panel, in Advanced Tools > Set up single sign-on, click the checkbox to Enable Single Sign-on.
2. Provide URLs for your organization's sign-in page, sign-out page, and change password page in the corresponding fields.
3. In the Verification certificate field, choose and upload a valid verification certificate file.
4. Click Save changes, wait a few minutes for your changes to take effect, and test your integration again.

This error message indicates that your Identity Provider is not providing Google with a valid SAML response of some kind. This problem is almost certainly due to a configuration issue in the Identity Provider.

• Check your Identity Provider logs and make sure that there is nothing preventing it from correctly returning a SAML Response.
• Ensure that your Identity Provider is not sending Google Apps an encrypted SAML Response. Google Apps only accepts SAML Responses that are unencrypted. In particular, please note that Microsoft's Active Directory Federation Services 2.0 often sends encrypted SAML Responses in default configurations.

The SAML 2.0 specification requires that Identity Providers retrieve and send back a RelayState URL parameter from Resource Providers (such as Google Apps). Google Apps provides this value to the Identity Provider in the SAML Request, and the exact contents can differ in every login. For authentication to complete successfully, the exact RelayState must be returned in the SAML Response. According to the SAML standard specification, your Identity Provider should not modify the RelayState during the login flow.

• Diagnose this issue further by capturing HTTP headers during a login attempt. Extract the RelayState from the HTTP headers with both the SAML Request and Response, and make sure that the RelayState values in the Request and Response match.
• Most commercially-available or open-source SSO Identity Providers transmit the RelayState seamlessly by default. For optimum security and reliability, we recommend that you use one of these existing solutions and cannot offer support for your own custom SSO software.