Version 5

    Note: If working with SAML, you need to be running SBS or above (there are too many bugs to easily work with in and earlier).


    **Disclaimer**: This is not meant to be a 100% comprehensive list of all possible issues that could be seen, however this list should take care of the most common issues. As more issues come to light this doc will be updated.





    Make sure DEBUG logging is enabled for SAML (from within the Admin Console, go to People -> Settings -> Single Sign On -> SAML -> Advanced -> Debug). Also turn off encryption in the SAML response handshake at the IdP (easier to determine what is being sent to the instance from the IdP and where the breakdown is occurring)


    IdP Specific


    • ADFS

      • Make sure jiveURL is running over HTTPS and that SSL is configured properly both on the load balancer (if applicable) as well as on each web app node. ADFS silently ignores any non-SSL endpoints in the SP metadata.
      • Fails to import metadata and displays


        • The ADFS server doesn't like the self-signed cert used to sign the metadata. Easiest workaround is to remove the signature in the metadata and re-import.
      • Include scoping should be unchecked, otherwise you will receive the following error message in the ADFS logs:

    Microsoft.IdentityServer.Web.UnsupportedSamlRequestException: MSIS1001: The SAML authentication request element 'Scoping' is not supported.

      • ads
    • PingFederate

      • Make sure if you attempt to access UAT and PROD using SSO, at the same time, that you do it from different browsers. Otherwise you could receive this error:




    <samlp:StatusMessage>Unexpected Runtime Authn Adapter Integration




    Unexpected Runtime Authn Adapter Integration Problem.</Cause>



      • Make sure that if the jiveURL is running over HTTPS that the base metadata URL is as well otherwise you will run into the following non-descriptive error:

    org.opensaml.common.SAMLRuntimeException: Incoming SAML message is invalid



    Caused by: org.opensaml.common.SAMLException: Unsupported request


    • Salesforce

      • wantsAssertionsSigned = false


    Common Issues


    • Destination endpoint '{}' did not match the recipient endpoint '{}':

    Intended message destination endpoint:

    Actual message receiver endpoint:

    SAML message intended destination endpoint '' did not match the recipient endpoint ''

      • The above message is due to the intended destination endpoint being listed as 'https' where as the receiver endpoint is 'http'. Two reasons this can occur are:
        • SSL is most likely not setup properly from the load balancer to the nodes (i.e. the SSL connection may be terminating before Tomcat on either node). Verify that SSL is configured not only on the load balancer but also on the individual nodes. See Forcing Traffic to HTTPS.
        • Verify that the saml.baseURL has https specified.
    • [Assertion failed] - this argument is required; it must not be null

    2011-08-31 14:56:10,254 [http-] [9B9EAD79891FC62045CD2037A89F98FB.:] INFO - Verification successful for URI "#id-LfyWPxYIwhWjA7k8VbIpidww9FE-"

    2011-08-31 14:56:10,259 [http-] [9B9EAD79891FC62045CD2037A89F98FB.:] ERROR - There was an error during SAML authentication

    java.lang.IllegalArgumentException: [Assertion failed] - this argument is required; it must not be null

      • The attribute that is attempting to be passed in does not exist, for example could be looking for 'username' when the IdP is attempting to pass in 'NameID'
    • Error at the IdP when using Safari during a SP initiated SSO login attempt.

      • If the error message displayed is MSIS7046 then change the saml.sso.binding system property (System -> Management -> System Properties) from HTTP-Post to HTTP-Redirect.
    • Metadata not in-sync between the nodes.

      • You can verify this by appending /saml/metadata to the end of each node's URL and comparing the displayed results.
        • Make sure File System caching is disabled (System -> Settings -> Storage Provider -> Cache Enable). Restart.
    • Users authentication data is too old

      • Clock drift between the timestamp on the IdP and the Jive Instance may be occurring. Increasing the response skew time in the Admin Console has no effect (JIVE-9927). Open a case with Jive Support for options.
    • Assertion is not yet valid, invalidated by condition notBefore ?

      • The notBefore timestamp is before the current timestamp on the instance.
    • User asked to confirm username and email upon first login.

      • This confirmation can be disabled by setting the following system properties and restarting the instance:
    sso.confirm.username = false = false
    • Assertion must be signed but is not

      • Set the following system property:
    saml.wantsAssertionsSigned.enabled = false
      • If setting the above system property has no affect open a case with Jive Support, will most likely need the Rat Pack plugin.
    • Missing attribute: '{}'

      • This commonly occurs due to the format of the attribute that is passed in and what the Jive Instance is looking for. For example if in the IdP the attribute for First Name is being passed as givenname however the Jive Instance is configured to have the First Name attribute mapping as 'Given Name'


                    you'll see the following error in the SAML response: User did not have the required attributes send from the identify provider. Missing attribute: Given Name. Given attributes: [,,]

                   and you can confirm what the IdP is sending above by looking at the corresponding <Attribute> in the XML response:

    <Attribute Name="">



                   changing the format of the attribute mapping in the Jive Instance from 'Given Name' to 'givenname' will resolve this.



    Common Pitfalls


    • File System caching is enabled (System -> Settings -> Storage Provider -> Cache Enable). Turn this off. This can cause the nodes to render two different metadatas if enabled.
    • PROD refreshed with UAT or vice versa
      • if the jiveProperty table is overwritten with settings from the other instance this will break SSO for the instance.
        • Steps to resolve:
          1. Restore the SAML configurations that were previously in place, jiveURL, metadata base URL, etc.
          2. Restart instance.
          3. Get new metadata from {jiveURL}/saml/metadata and re-import it into IdP


    Migrating Users


    • Users already exist in Jive.

      • Are the usernames that will be used for authentication the same as the usernames currently used by users in the Jive Instance?
        • setting the system property saml.usernameIdentity = true will cause the instance to use the look up the user by the username currently stored in the jiveUser table.
      • Are the usernames that will be used for authentication different than the usernames currently used by users in the Jive Instance?
        • Open a case with Jive Support to determine options.
    • Users do not yet exist in Jive.

      • Same scenerio as above.




    Make sure DEBUG logging is enabled for Kerberos (from within the Admin Console, go to People -> Settings -> Single Sign On -> Kerberos -> Advanced -> Debug)


    Example Configuration



    Common Pitfalls


    • Make sure the browser is configured to send Kerberos tokens (Kerberos tokens will start with a YII), place example here.
    • SPN mapping for only the principle user on the domain controller. If you create multiple SPN mappings you can run into an issue with IE reverting from Kerberos to NTLM authentication.
      • Example commands to do this:
    setspn -A HTTP/ yourPrincipleUser
    setspn -A HTTP/yourJiveServer yourPrincipleUser
    • Service Principle account should be the name from the SPN mapping
    • Service Principle should not include realm (for example serviceprinciple, not serviceprinciple@realm)
    • Realm is case sensitive and should be all CAPS (for example CORP.EXAMPLE.COM, not
    • Make sure the KDC supports a minimum of DES encryption (with newer KDCs this shouldn't be an issue)
    • If you receive an Apache 400 error when you attempt to login, you are most likely running into JIVE-11844 - this is due to the headers being sent over are too large for Apache and Tomcat to handle. To work around this perform the following steps:
      • Add the maxHttpHeaderSize to your Tomcat connector in the server.xml file (this is located at /usr/local/jive/applications/{sbs name}/conf):




          port="${http.port}" protocol="HTTP/1.1" address="${http.addr}" redirectPort="443"

          URIEncoding="UTF-8" connectionTimeout="20000">






          port="${http.port}" protocol="HTTP/1.1" address="${http.addr}" redirectPort="443"

          URIEncoding="UTF-8" connectionTimeout="20000" maxHttpHeaderSize="65536">


      • Increase the LimitRequestFieldsize in the Apache default.conf file  to 65536 (this file is located at located at /usr/local/jive/etc/httpd/sites/)
      • Restart both Apache and Tomcat - so a full instance restart.