Hello,

This maybe one for the Tomcat experts J as having sent this message to the Internet2 list, that was the only suggestion I got back – it’s a Tomcat issue – but I can’t see where. So, here we go..... suggestions welcome!

I'm attempting to set up a Shib 2 IdP on Red Hat Enterprise Linux release 3 (with JRE 1.6.0_18, apache-tomcat-6.0.20 and shibboleth-identityprovider-2.1.5) but running into a problem that looks so much like a misconfiguration someplace.

The problem is that at the point where the IdP would serve up the user authentication page (login.jsp) it's actually redirecting itself to a URL like this:

https://servername.abdn.ac.uk:80/idp/Authn/UserPassword"

That is, an SSL-enable endpoint but with the wrong port number - the ":80" just shouldn't be there.

At the same time, the idp-process log reports:

09:58:59.849 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:198] - Processing incoming request

09:58:59.849 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:228] - Beginning user authentication process.

09:58:59.850 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:334] - Filtering configured login handlers by requested athentication methods.

09:58:59.850 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:335] - Configured LoginHandlers: {urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession=edu.internet2.middleware.shibboleth.idp.authn.provider.PreviousSessionLoginHandler@184b3b, urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified=edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler@f34a08, urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler@f34a08}

09:58:59.851 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:336] - Requested authentication methods: []

09:58:59.851 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:236] - Possible authentication handlers for this request: {urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession=edu.internet2.middleware.shibboleth.idp.authn.provider.PreviousSessionLoginHandler@184b3b, urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified=edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler@f34a08, urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler@f34a08}

09:58:59.852 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:246] - Possible authentication handlers after filtering: {urn:oasis:names:tc:SAML:2.0:ac:classes:PreviousSession=edu.internet2.middleware.shibboleth.idp.authn.provider.PreviousSessionLoginHandler@184b3b, urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified=edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler@f34a08, urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport=edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler@f34a08}

09:58:59.852 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:277] - Selecting appropriate login handler for request

09:58:59.853 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:250] - Authenticating user with login handler of type edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler

09:58:59.853 - DEBUG [edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:155] - LoginContext parition: loginContexts

09:58:59.855 - DEBUG [edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:161] - LoginContext key: 10addd91-18cb-4dfa-a7e4-b78ceb0bc6a9

09:58:59.864 - DEBUG [edu.internet2.middleware.shibboleth.idp.authn.provider.UsernamePasswordLoginHandler:75] - Redirecting to https://servername.abdn.ac.uk:80/idp/Authn/UserPassword

and as Tomcat isn't listening on port 80, the authentication process stalls.

We are not running any SSL-offloading stuff to cause the 443->80 port change.

If I do enable port 80 and https on it within Tomcat, the redirect then has somewhere to go, I can login, and attributes are delivered to the SP I've been testing with. Clearly that's not how it's supposed to work, but I'm at a loss to find the bit of configuration that's causing this.

Any clues or assistance appreciated.

John Thom

University of Aberdeen