Infinispan Based Storage Service

[Cantor, Scott]

On 7/4/12 7:59 AM, "Manuel Haim" <haim at hrz.uni-marburg.de> wrote:
>
>Multiple keys within StorageService:
>The Shibboleth IdP stores a Session object under multiple keys within
>the StorageService (not only by sessionId). I guess if your filter only
>calls Infinispan's "put" method by sessionId, the other objects (and
>object keys) may not be updated. This may cause problems with artifact
>resolution via IdP backchannel, as the Session object needs to be
>available e.g. by principalName or transientId.

For logout maybe, but not for artifacts. I think you're confusing
artifacts with something else.

> So you should test the
>back-channel by logging in to one IdP node and having back-channel
>requests go to another IdP node (open relying-party.xml and set
>includeAttributeStatement="false" within the saml:SAML2SSOProfile, so
>the SP only gets an artifact and is forced to do artifact resolution).

That has nothing to do with artifacts, that's attribute query. So I'm
guessing you are in fact confusing them.

>Please also note that artifact resolution can also be forced by the SP
>and is the default behaviour for the Shibboleth SP 1.x.

Definitely not.

FWIW, queries are trivial, you just drop in the stateless variant of the
transient ID mapper. No need for clustering that.

-- Scott