IdP SSO not working

[Chad La Joie]

On Wed, Feb 22, 2012 at 16:10, Sara Hopkins <sara.hopkins at ed.ac.uk> wrote:
> 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.

That's probably going to be a problem.  It may be the problem here but
even if it's not it's likely to cause issues in the future.

> 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'd advise not looking a that code.  It's complicated to follow.

> 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:

This is more likely due to a difference in IdP versions, older ones
did not set any Cache-Control headers.  I don't remember when it was
added but in the scheme things it wasn't that long ago.  That would
also account for the difference in the Locations you're seeing.  Older
IdPs didn't do HTTP redirects, just API forwards, in some cases when
transferring to/from the authn engine.

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

Well, in all cases like this, it comes down to a cookie issue.  You
said the cookie was getting to the IdP so it's more likely that the
IdP is rejecting the cookie.  The most common reason for that is IP
address issues (as noted above).  I've also seen other cases though
where the cookie value is corrupted in some way (e.g., truncated).

So, my advice would be to turn on debug logging for
edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter and
see what it says when it is inspecting the cookie.

-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered