SP 2.5.1 ss:mem target lost

[Scott Koranda]

Hello,

I have a 2.5.1 Shibboleth SP running on CentOS 6.x. It is
configured so that the relayState attribute for the <Sessions>
element has the value "ss:mem".

Randomly but repeatedly with enough frequency to be bothersome
a session initiated using the NativeSP session creation
parameters entityID and target sent to the handler location
/Shibboleth.sso/Login is successfully created but the browser
is not redirected to the target but instead is directed to the
"home URL". The homeURL attribute for the
<ApplicationDefaults> element is not explicitly configured.

I have traced the interaction between the browser and the
servers and have verified that both when the problem is
exhibited and when it is not:

- the entityID and target parameters are being correctly sent
  to the session initiator, with the exception that the values
  are not completely and properly URL encoded (and that will
  be fixed).

- the SP is passing to the IdP (in this case a Shibboleth IdP)
  via redirect a RelayState that does contain a value prefixed
  with "ss:mem" (properly URL encoded of course)

- the full value for the RelayState is being passed back by
  IdP with the SAMLResponse and they are being properly
  POST'ed back to the SP at the correct endpoint

- after the POST the SP is returning a 302 Found with a
  Set-Cookie that establishes the SP session

- the Location returned with the 302 is the home URL and not
  the original target

The only significant different between a trace when the
problem is exhibited and when it is not is the change in the
value for the Location: header sent by the SP with the 302
redirect after the POST.

The problem is seemingly random and not correlated with load.
The SP session itself is always fine. It has the expected
lifetime and the expected attributes.

On another SP instance I configured shibd.logger with

log4j.category.Shibboleth.SessionCache=DEBUG
log4j.category.XMLTooling.StorageService=DEBUG

I had hoped that I would be able to see in the log file the
consumption of the target parameter and its conversion to a
ss:mem relay state "bucket" but I did not see that, or any
other way to confirm that the SP is receiving the target
parameter.

Questions:

a) The incomplete URL encoding of the value for the target
parameter concerns me and I intend for it to be fixed to rule
it out as a problem, but since the flow works "correctly"
approximately 80% or more of the time is the URL encoding
issue likely or not to contribute?

b) Is there a shibd.logger configuration I can make to have
the consumption of the target attribute and its conversion
into a ss:mem relay state logged so that I can see it?

c) Any ideas as to why the problem may be happening?

d) I would be grateful for further debugging suggestions.

Thanks,

Scott K