Attribute Transcoding errors following IdP upgrade

[Simon McLeish]

Thanks for the pointers there, Scott. It took me a while to have time to
look at it, but I've now sorted the problem using the DEBUG log. The config
was set to use the same LDAP attribute twice, to give it a local name and
also employeeNumber, and only employeeNumber was released (the config is
like that for reasons which go back over 6 years). Before the upgrade, both
versions were encoded, with the encoding rule matched on the OID for the
employeeNumber attribute. It appears now that the first one is still
encoded, with the local name, but the second, the employeeNumber which is
the only one which is released, was not. Removing the local name
configuration means that the attribute is encoded and released again.

Cheers,
Simon

On Tue, Sep 22, 2020 at 3:47 PM Cantor, Scott <cantor.2 at osu.edu> wrote:

> On 9/22/20, 10:30 AM, "users on behalf of Simon McLeish" <
> users-bounces at shibboleth.net on behalf of simon.mcleish at gmail.com> wrote:
>
> >    OK, so why would it not be loading the resolver file (in the extra
> lookup instance where it doesn't work) when it did
> > before? And why does it still work for a "normal" authentication through
> the IdP?
>
> Are you talking about an AttributeQuery? The only reason it would be any
> different with a query is if it's trying to filter attributes based on the
> request, so it would depend on what's in the request. That requires
> decoding the SAML Attribute, not encoding the IdP Attribute.
>
> I would be looking closely at the logs at startup regarding the
> transcoding rules it installs based on the resolver and the logs in detail
> of the message in and what it's trying to decode at that point. The rules
> are all recorded at startup on DEBUG to get a full summary of them.
>
> It's possible there's a NameFormat issue, and it's also possible the old
> code was broken/sloppy about handling that in some way.
>
> And it's equally possible there's a bug because queries are practically
> unused at this point.
>
> -- Scott
>
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20201012/360b665c/attachment.htm>