Trouble with SP (BambooHR) - have taken debugging as far as I can

[Mak, Steve]

            <PolicyRequirementRule xsi:type="Requester" value="https://whitmansandbox.bamboohr.com/saml/consume.php" />

This needs to be the EntityID of the RP, not the ACS endpoint.

From: users <users-bounces at shibboleth.net> on behalf of Mike Osterman <ostermmg at whitman.edu>
Reply-To: Shib Users <users at shibboleth.net>
Date: Friday, July 26, 2019 at 5:37 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Trouble with SP (BambooHR) - have taken debugging as far as I can

Thanks, Peter. I've done some more digging and changed some things, but still stuck. (see below)

On Fri, Jul 26, 2019 at 3:19 AM Peter Schober <peter.schober at univie.ac.at<mailto:peter.schober at univie.ac.at>> wrote:
* Mike Osterman <ostermmg at whitman.edu<mailto:ostermmg at whitman.edu>> [2019-07-26 06:45]:
> After some digging around, I found the documentation to do a Regex match in
> the Requester URL:
> https://wiki.shibboleth.net/confluence/display/IDP30/RequesterRegexConfiguration
>
> And came up with this:
>     <AttributeFilterPolicy id="BambooHR-SAML">
>         <PolicyRequirementRule xsi:type="RequesterRegex" regex="^
> https://whitmansandbox.bamboohr.com/.*$" />

Regexes shouldn't be necessary. I'm guessing your tenant SP is only
that: One (1) SP with one (1) unchanging entityID. Just providing the
correct entityID there (cf. the metadata you added for that SP) should
suffice?
But either way it still doesn't match:

You're right - I dug into the metadata file in $IDP_HOME/metadata/ and it advertises a URL without a wildcard:
        <md:EntityDescriptor
                                        entityID="BambooHR-SAML">
                <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
                        <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
                        <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                                                                        Location="https://whitmansandbox.bamboohr.com/saml/consume.php"
                                                                        index="0"
                                                                        isDefault="true"/>
                </md:SPSSODescriptor>
        </md:EntityDescriptor>

So I've updated my attribute filter policy, and removed the entityID from the policy id attribute, just to make the logs easier to read:

    <AttributeFilterPolicy id="bamboohr">
        <PolicyRequirementRule xsi:type="Requester" value="https://whitmansandbox.bamboohr.com/saml/consume.php" />
        <AttributeRule attributeID="mail">
            <PermitValueRule xsi:type="ANY" />
        </AttributeRule>
    </AttributeFilterPolicy>

> causing the
> net.shibboleth.idp.saml.nameid.impl.AttributeSourcedSAML2NameIDGenerator
> messages in lines 32-33 here:
> https://gist.github.com/ostertoaster/3d322c8d2c9a48d9f8c3bb34cd7e12d0

Line 11 already states that the policy didn't apply, hence no
attributes and no attribute-sourced NameID:

> Attribute Filter Policy 'BambooHR-SAML'  Policy is not active for this request

And yet still, same result - see line 5:
https://gist.github.com/ostertoaster/740cb2174bafe3679a00aceb5e24cb72

The only thing I didn't explicitly state is it only supports NameID (yeah, I know it sucks), but my understanding is I still need to release the 'mail' attribute so it can be released through NameID format.

They also support Google Sign-In, but I *really* don't want to go that route, nor do I think our ISO wants to.

Thanks,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190727/ca1774a8/attachment.html>