ClientStorageService error when issuing delegated assertion

Description

As discussed in the users list:

http://marc.info/?l=shibboleth-users&m=147087384910813&w=2

When issuing a delegation assertion (Liberty SSOS profile), the following error is logged twice in succession:

ERROR [org.opensaml.storage.impl.client.ClientStorageService:451] -
StorageService shibboleth.ClientSessionStorageService: No storage
object found in session

Presumably the error occurs because the client (presenter) does not support the session cookie, but the client-side storage does not seem useful in the delegation case, and should be skipped.

Attaching an edited trace log (with DEBUG level for opensaml, net.shibboleth.idp.saml.saml2.profile.delegation, and net.shibboleth.idp.saml.nameid).

Environment

None

Attachments

1

Activity

Brent Putman 
October 19, 2016 at 1:24 AM

Fixed in r8514.

Brent Putman 
October 19, 2016 at 1:23 AM

I just went with the same action "splicing" technique whereby we bypassed other actions in the parent flows that aren't applicable to the SSOS flow.

Scott Cantor 
October 18, 2016 at 7:47 PM

, let me know if you want me to put a fix for this in, but I'd still need you to verify it.

Scott Cantor 
August 12, 2016 at 7:54 PM

The SSOS flow inherits from the SAML 2 SSO abstract parent flow, and that one does a unilateral call into the client-storage/read (and write) flows. Those flows have some checking for non-browser to skip the LocalStorage step, but they still do a cookie read so that if an ECP client wanted to have a cookie jar, things would all work properly.

The SSOS flow bypasses authentication so by design there's no session logic and no point in transiting the storage flows.

The fix is probably to define a Boolean bean to inject as an activationCondition on the PopulateClientStorageLoadContext and PopulateClientStorageSaveContext action beans. The SSO flows would define a TRUE bean for that, but the SSOS flow would use a FALSE bean and voila, short-circuit.

Alternatively there's probably a parent/child flow trick that could be used to re-wire the behavior, but not sure that's much more clear in the end.

Fixed

Details

Assignee

Reporter

Components

Fix versions

Affects versions

Created August 12, 2016 at 7:40 PM
Updated October 19, 2016 at 1:24 AM
Resolved October 19, 2016 at 1:24 AM