Binary Attributes during IdP upgrading

Posted on Thursday, 27 May 2021

Shibboleth Identity Provider (IdP) operators must pay particular attention to the changes related to Binary Attributes during upgrades of the IdP within v3 and between v3 and v4. Operators who follow our guidance (Deprecated features in Shibboleth IdPv3 will be removed in v4 documentation and IdP v4 upgrade), including testing as described below, should not experience any issues.

If your IdP references Binary Attributes in its LDAP service (typically objectGUID and objectSID in Active Directory) you must use new configuration elements, or the values of attributes generated from binary attributes may change after upgrade. The new configuration options are required because the underlying LDAP libraries in the Shibboleth IdP have changed (see Shibboleth IdP release notes - LDAP changes).

The most common use case is an eduPersonTargetedID attribute that is generated using a ComputedID connector which uses a Binary Attribute as a source. IdPs must retain a consistent value over upgrades or lose all personalisation at SPs. Other observed effects of not using the new configuration are:

A generated attribute for a single user changes between sessions The same attribute is generated for multiple user accounts, which has implications for user privacy, and may result in data loss or data breach.

IdP operators are STRONGLY advised to review UK federation documentation to mitigate risk during upgrades. In particular, you should ensure that the values of attributes generated by your IdP before and after an upgrade are consistent. You can use the aacli script provided as part of the Shibboleth IdP, or by using the UK federation Test SP

This item was posted in the UK federation members communication on Friday 21st May 2021.

Edited by JonAgland on 28 May 2021, at 10:24 AM