Upgraded IDP from v2 to v3 - user can login but no attributes are being received at the SP

Joel Saunders Joel.Saunders at zones.com
Thu Jan 31 12:48:09 EST 2019


Thanks for the response.

In the end, putting debug on the IDP helped me figure out what the issue was.
Looks like the attribute-filter.xml file needed to have the attributes that I needed passed defined in it.

The debug showed me that 4 attributes were being passed back to the IDP, but then  3 of them were being dropped since they weren't specified in the attribute-filter.xml file.

One attribute named transientid was allowed.  I had to add the following to the attribute-filter.xml file for the others to be passed on to the SP:

    <!--  Release the UID to anyone -->
    <afp:AttributeFilterPolicy id="releaseUIDToAnyone">
        <afp:PolicyRequirementRule xsi:type="basic:ANY"/>

        <afp:AttributeRule attributeID="uid">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
        </afp:AttributeRule>

    </afp:AttributeFilterPolicy>

    <!--  Release the EPPN to anyone -->
    <afp:AttributeFilterPolicy id="releaseEPPNToAnyone">
        <afp:PolicyRequirementRule xsi:type="basic:ANY"/>

        <afp:AttributeRule attributeID="eduPersonPrincipalName">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
        </afp:AttributeRule>

    </afp:AttributeFilterPolicy>

    <!--  Release the DEPTNO to anyone -->
    <afp:AttributeFilterPolicy id="releaseDEPTNOToAnyone">
        <afp:PolicyRequirementRule xsi:type="basic:ANY"/>

        <afp:AttributeRule attributeID="departmentnumber">
            <afp:PermitValueRule xsi:type="basic:ANY"/>
        </afp:AttributeRule>

    </afp:AttributeFilterPolicy>


On to the next fire....    Thanks for all of the help!

... Joel
-----Original Message-----
From: users <users-bounces at shibboleth.net> On Behalf Of Peter Schober
Sent: Thursday, January 31, 2019 11:13 AM
To: users at shibboleth.net
Subject: Re: Upgraded IDP from v2 to v3 - user can login but no attributes are being received at the SP

* Joel Saunders <Joel.Saunders at zones.com> [2019-01-31 13:53]:
> The same SP works fine with another IDP (with back-channel query) but 
> doesn't get any attributes from the V3 Shib IDP, so I don't think that 
> the SP is the issue, but I could be wrong.

Which part is your responsibility? If the SP then you may opt to disable attribute queries on the SP. To do that make sure you don't have an AttributeResolver element of type="Query" in your SP's shibboleth2.xml

If the IDP then make sure to release the required attributes to the SP. It's that simple.

> How would you proposed that I troubleshoot this?
> 	I guess that I should begin by putting debug on at both IDP
> 	and SP?   Unless there are other steps that I could take?

No need for debug logging anywhere: The logs will tell you what
happenend: The IDP's what went out, the SP's what it recieved (and sometimes what it threw away/rejected due to policy).

The Shibboleth IDP also has the aacli utility allowing you to excercise your resolver (and filter) easily from the command line, and for arbitrary userids and SP entityIDs.
So unless/until the aacli shows that the right attributes go out to the right SP with the right attribute names and the right attribute values you'll have to tune your IDP config.

If you think the IDP is configured correctly but aacli and logs say otherwise, then you'd still have to find out whether the IDP resolved the attributes correctly but did not release them (adjust the filter,
then) or that even resolution fails before. In that case you could set "net.shibboleth.idp.attribute" to DEBUG logging in your  IDP's conf/logback.xml. That will tell you exactly what attribute values are found and therefore also the "why" of (not) releasing them.

-peter
--
For Consortium Member technical support, see https://urldefense.proofpoint.com/v2/url?u=https-3A__wiki.shibboleth.net_confluence_x_coFAAg&d=DwICAg&c=bFSfV3JDZVFjkVdrOg1Bnsgwku-x_EGNRi2KNxwvClI&r=WG-pl0WpwyPk-r6oNnUhsoAUBdVNpC8ryokTG8RkffA&m=gbDxYP69rpeR14zXpx8u0BR_YDdTm2TbVEFYP2RnEkw&s=kYgFCGBew8zfoJVnI-Odf4XJPbwpNY2EHvCMlg9Ijlo&e=
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net


More information about the users mailing list