IdP SSO not working

[Sara Hopkins]

Hi folks,

I've been banging my head against a client's IdP problem for some time now. They are having a problem where their users have to type in their username and password every time they attempt to access a new SP; it's not remembering the previous session. I've checked their handler.xml and the PreviousSession handler is there, the config looks fine and the default settings have not been changed.

They have three IdP servers behind a NetScaler load balancing solution. I must confess I know next to nothing about load balancers, but instinctively I'm tempted to look for the problem there. It looks to me as if it has to be something related to state. And one thing I have noticed in particular in their IdP log is that only one IP address is ever logged, which is their NetScaler IP address (a private IP on the 192.168 net). So every Shibboleth-Access, whether an SSO or an AttributeQuery, is being logged with that IP address.

The three IdP servers all log this for every user, every time they attempt to access an SP:

00:12:40.224 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:328] - Filtering out previous session login handler because there is no existing IdP session

It does this even when the IdP log shows that there clearly has been a login by that user within the last few minutes on that particular server.

I've briefly looked at the IdP code here:

https://svn.shibboleth.net/java-shib-idp2/branches/REL_2/src/main/java/edu/internet2/middleware/shibboleth/idp/authn/AuthenticationEngine.java

and that indicates that the message above is logged when a variable idpSession is null, where

Session idpSession = (Session) httpRequest.getAttribute(Session.HTTP_SESSION_BINDING_ATTRIBUTE);

but alas I don't know enough about what that means with respect to the other messages that appear in the log.

I've looked at output from Live HTTP Headers that they've given me, and cookies are definitely making it to the web browser. I have noticed that some of the messages are different from the ones I see in Live HTTP Headers for my own IdP, for which SSO works correctly. These messages relate to cache settings which I think the IdP inherits from the web server. For my IdP the web server is Tomcat, and I see this:

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Expires: 0
Cache-Control: no-cache, no-store, must-revalidate, max-age=0
Pragma: no-cache
Set-Cookie: _idp_authn_lc_key=38f2d0d2-cac1-4a1c-9aff-dc2930308fea; Version=1; Path=/idp; Secure
Location: https://my-idp.my-domain.ac.uk:443/idp/profile/Shibboleth/SSO
Content-Length: 0
Date: Wed, 22 Feb 2012 18:52:23 GMT

But for them I see this:

HTTP/1.1 302 Moved Temporarily
Date: Wed, 22 Feb 2012 08:22:32 GMT
Set-Cookie: _idp_authn_lc_key=018f7a4f-0d18-4ca2-bc27-8024e271dcc6; Version=1; Path=/idp; Secure
Location: https://their-idp.their-domain.ac.uk:443/idp/Authn/UserPassword
Content-Length: 0
Keep-Alive: timeout=5, max=98
Connection: Keep-Alive
Content-Type: text/plain

So it doesn't seem to know anything about the web server, appears not to have inherited any cache settings, and it has /idp/Authn/UserPassword as the Location where I have /idp/profile/Shibboleth/SSO.

I would be really grateful for any thoughts, especially from anyone who has experience of this kind of issue in a load-balanced environment.

Thanks in advance,

Sara
-- 
Sara Hopkins
Support Team
UK Access Management Federation for Education and Research
web:    http://www.ukfederation.org.uk/

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.