Federation with Concur?

[David Gersic]

There are a couple of things on that page that I'm not sure about. None are serious.


In the metadata configuration, he has the entityID as  entityID="https://www.concursolutions.com" where I think it should be  entityID="https://www.concursolutions.com/"  The trailing slash is important. Maybe this changed between when he wrote it and now, but the XML I got from Concur has the trailing slash in it. There are a few other changes in the way his sample metadata is set up from the way Concur actually sends it. Look carefully here if you're following the recipe.


Related to this, in attribute-filter.xml, I'm assuming that the afp:PolicyRequirementRule and basic:AttributeRequesterString values need the trailing slash to match the entityID.


In attribute-resolver.xml he's doing a Template:

<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>

 where it looks like Scoped:

    <resolver:AttributeDefinition xsi:type="ad:Scoped" xmlns="urn:mace:shibboleth:2.0:resolver:ad" id="ConcurNameID" scope="yourdomain.edu" sourceAttributeID="uid">
        <resolver:Dependency ref="myLDAP" />
            <resolver:AttributeEncoder xsi:type="SAML2StringNameID"
                xmlns="urn:mace:shibboleth:2.0:attribute:encoder"
                nameFormat="urn:oasis:names:tc:SAML:2.0:nameid-format:unspecified" />
    </resolver:AttributeDefinition>

 would be simpler, at least to me. Is there any effective difference here, assuming that domain.edu is the same for both definitions?


It would seem simpler to me to edit relying-party.xml only once, putting in the metadata configuration and the disable of encrypted assertions at the same time. Also the sample rp:RelyingParty has "idp.smu.edu"  in it. That should probably be an "idp.yourdomain.edu"  there.


The test URL in the last step must match the metadata in step 1. If you have the trailing slash in the entityID in the metadata, then the test URL must have it as well:

https://idp.domain.edu/idp/profile/SAML2/Unsolicited/SSO?providerId=https%3A%2F%2Fwww.concursolutions.com%2F

Also here, the test URL text shows "idp.domain.edu", but the actual URL location is "idp.smu.edu".


________________________________________
From: users <users-bounces at shibboleth.net> on behalf of Cantor, Scott <cantor.2 at osu.edu>
Sent: Monday, September 28, 2015 1:41 PM
To: Shib Users
Subject: Re: Federation with Concur?

On 9/28/15, 2:34 PM, "users on behalf of David Gersic" <users-bounces at shibboleth.net on behalf of dgersic at niu.edu> wrote:

>Anybody here federated with Concur (concur.com)? I just got asked if we can, but the only docs provided so far are for how to set up ADFS to work with their stuff. That they're doing SAML seems like a good sign.

https://wiki.shibboleth.net/confluence/display/SHIB2/Concur+Solutions

The verbage is a bit overblown there in the sense that the author I think is under the impression that any of the things that seem off are in any way unusual for a vendor.

I didn't have significant trouble getting it to work, but of course they have no intention of joining a federation.

They don't have a key so there isn't exactly a lot for them to share with you, it's a URL and that's about it.

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net