I have configured my IdP with:
and I noticed the following error messages in my idp-process.log:
This was puzzling me for a while. After some debugging and staring into the code, I have managed to track this down to the logic in net.shibboleth.idp.session.impl.StorageBackedSessionManager in the indexBySPSession method.
The conditions on lines 671 and 680 say:
- If we have a sessionList that does not contain the SP entityId yet, update the record
- If this fails, switch to creating the record as it must have been just deleted.
- Else, try creating the record - and if it fails, switch to updating, as it must have been just created.
This logic breaks if the sessionList already exists and it already contains the SP entityId. In this case, the first condition never holds, so the else branch gets used, trying to create the record instead - and after 10 retries, the method gives up.
This flow can be triggered when the SP makes multiple subsequent SSO requests. I triggered it when testing, but I can also imagine real life use cases that trigger that too.
In this case, failing to add the SP entityId to the Secondary Index is completely harmless, as the SP entityId is already included in the Secondary Index for that IdP session. However, it generates rather disturbing (but spurious) error messages.
The fix should be trivial - to also consider the case when sessionList exists and already contains the SP entityId.