The Shibboleth V2 IdP and SP software have reached End of Life and are no longer supported. This documentation is available for historical purposes only. See the IDP v4 and SP v3 wiki spaces for current documentation on the supported versions.

Concur Solutions

Owned by Thomas Doan
Last updated: Feb 12, 2015
2 min read

Concur Solutions considers themselves "SAML compatible but not SAML compliant". Essentially this means there are many limitations in their SSO implementation, and integration with a Shibboleth IdP is quite non-intuitive and non-standard. For example,

  • Concur does not share their SP metadata, and does not consume IdP metadata via SAMLP. Instead they require unsolicited, or IdP-initiated, SSO sessions.
  • Concur requires the IdP signing certificate to be supplied via email.
  • Concur ignores SAML attributes and looks only in the SAML subject for a NameID containing an identifier in the form userID@domain.edu. The userID in this case is the identifier provisioned to Concur via file transfer from the HR or ERP system.

The Concur SAML integration guide, and Concur mobile app integration guide, are provided only under NDA. However, the steps here should help establish the SSO partnership.

Concur integration with Shibboleth IdP

  1. Provide a copy of the IdP signing certificate to Concur via email.
  2. Ensure IdP-initiated SSO is enabled in the IdP.
    1. This is enabled by default in Shibboleth IdP 2.3.0 and above.
      https://wiki.shibboleth.net/confluence/display/SHIB2/IdPUnsolicitedSSO
  3. Configure the Concur SP metadata into the IdP (modified version provided here).
    1. Provide the metadata to the IdP file system, then configure it into relying-party.xml.

    2. Ensure the NameIDFormat in the SP metadata matches the nameFormat used in the AttributeEncoder of the AttributeDefinition in attribute-resolver.xml.

      <md:EntityDescriptor entityID="https://www.concursolutions.com"
                     xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui"
                     xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata">
  <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:Extensions>
      <mdui:UIInfo>
        <mdui:DisplayName xml:lang="en">Concur Solutions</mdui:DisplayName>
<!--    <mdui:Description xml:lang="en">Optional description.</mdui:Description> -->
        <mdui:Logo height="146" width="148">https://www.concur.com/sites/all/themes/Concur6/images/Concur_logo.png</mdui:Logo>
      </mdui:UIInfo>
    </md:Extensions>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified</md:NameIDFormat>
    <md:AssertionConsumerService index="1" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://www.concursolutions.com/SAMLRedirector/ClientSAMLLogin.aspx"/>
  </md:SPSSODescriptor>
</md:EntityDescriptor>

  4. Define a NameID attribute in attribute-resolver.xml to be released to Concur.

    1. Ensure the NameFormat used in the Attribute Encoder matches the NameIDFormat specified in the SP metadata.

    2. See https://wiki.shibboleth.net/confluence/display/SHIB2/IdPAddAttribute.

    3. Also see https://wiki.shibboleth.net/confluence/display/SHIB2/IdPCustomNameIdentifier.

      <resolver:AttributeDefinition xsi:type="ad:Template" id="ConcurID"> 
    <resolver:Dependency ref="myLDAP" />
    <resolver:AttributeEncoder xsi:type="enc:SAML2StringNameID" nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified" />
    <ad:Template>
        <![CDATA[
            ${employeeID}@domain.edu
        ]]>
    </ad:Template>
    <ad:SourceAttribute>sAMAccountName</ad:SourceAttribute>
</resolver:AttributeDefinition>

  5. Release that attribute to Concur in attribute-filter.xml.

    <afp:AttributeFilterPolicy id="releaseToConcur">
  <afp:PolicyRequirementRule xsi:type="basic:AttributeRequesterString" value="https://www.concursolutions.com" />
  <afp:AttributeRule attributeID="ConcurID">
    <afp:PermitValueRule xsi:type="basic:ANY" />
  </afp:AttributeRule>
</afp:AttributeFilterPolicy>
  6. Exclude Concur from receiving the transcientId in attribute-filter.xml.

    1. Concur cannot receive any released attributes other than the ConcurID.

    2. A basic transientId release policy might look like this.

      <afp:AttributeFilterPolicy id="releaseTransientIdToAnyone">
    <afp:PolicyRequirementRule xsi:type="basic:NOT">
        <basic:Rule xsi:type="basic:AttributeRequesterString" value="https://www.concursolutions.com" />
    </afp:PolicyRequirementRule>
    <afp:AttributeRule attributeID="transientId">
        <afp:PermitValueRule xsi:type="basic:ANY"/>
    </afp:AttributeRule>
</afp:AttributeFilterPolicy>

  7. Disable assertion encryption and NameID encryption for Concur in relying-party.xml.

    1. Insert this configuration below the Default Relying Party configuration. 

    2. See https://wiki.shibboleth.net/confluence/display/SHIB2/IdPSAML2SSOProfileConfig.

      <rp:RelyingParty id="https://www.concursolutions.com" provider="https://idp.smu.edu/idp/shibboleth" defaultSigningCredentialRef="IdPCredential">
  <rp:ProfileConfiguration xsi:type="saml:SAML2SSOProfile" encryptAssertions="never" encryptNameIds="never" />
</rp:RelyingParty>
  8. Construct and test an unsolicited URL.
    1. For example, https://idp.domain.edu/idp/profile/SAML2/Unsolicited/SSO?providerId=https%3A%2F%2Fwww.concursolutions.com

Â