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

[Peter Schober]

* 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