[Shib-Users] Shibboleth IdP 2.1.2 and SLES11
Florian Götz
when trying to setup a Shibboleth IdP on SLES11 I ran into problem with the
certificates. I can´t get the certificates trusted (more on that later).
A second testinstallation on a Ubuntu 9.04 server runs flawless, but since we
are only using SLES11 systems I must port it to SLES.
SLES11 natively has installed a java version from IBM (1.6.0-124.7.1 IBM-
ILAN).
When I install the sun version I get an error from Shibboleth, or better SAML
that the version of java I am using would be buggy.
>OpenSAML requires an xml parser that supports JAXP 1.3 and DOM3.
>The JVM is currently configured to use the Sun XML parser, which is known
>o be buggy and can not be used with OpenSAML. Please endorse a functional
>JAXP library(ies) such as Xerces and Xalan. For instructions on how to
>endorse
>a new parser see
>http://java.sun.com/j2se/1.5.0/docs/guide/standards/index.html
I can install Xerces and Xalan, but the message stays the same.
With the native IBM Java 1.6.0 Shibboleth starts up, but I get errors, that
the certificates are untrusted:
javax.net.ssl.SSLHandshakeException: com.ibm.jsse2.util.g: PKIX path building
failed: java.security.cert.CertPathBuilderException: PKIXCertPathBuilderImpl
could not build a valid CertPath.; internal cause is:
java.security.cert.CertPathValidatorException: The certificate issued by
CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom
AG, C=DE is not trusted; internal cause is:
java.security.cert.CertPathValidatorException: Certificate chaining error
I first thought that this is a matter with the Java Keystore. But I´m not using
that on the Ubuntu version at all, so why should I use it on SLES?
I even tried to add the CA Certificate mentioned in the errormessage, but that
doesn´t help either. Then I was reminded that not root, but the user tomcat
"executes" tomcat and with that the Idp. So I tried to add the CA to tomcats
keystore, but that didn´t help either.
Does anyone know how to install Shibboleth IdP on SLES the right way?
--
Best regards,
Florian Götz
-----
Chad La Joie
JDK (as opposed to something like IBM's J9 or Jikes) is really really
slow when doing crypto operations (which is what the IdP spends most of
its time doing).
Second, the reason endorsing Xerces and Xalan didn't work, when you
tried with the Sun JDK, is that Tomcat overrides that mechanism. The
shib install docs give you the directions for doing this in Tomcat:
https://spaces.internet2.edu/display/SHIB2/IdPApacheTomcatPrepare
Lastly, assuming you want to continue to try and use the IBM JDK, what
exactly was generating that error? I'm guessing Tomcat since the IdP
does not try to do anything with PKIX work. If that's the case your
best bet is going to be to email the Tomcat list. I certainly don't
have any real experience with IBM JDK + Tomcat.
--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch
Bernd Oberknapp
> First, I'd recommend using either the Sun JDK or OpenJDK because IBM's JDK (as
> opposed to something like IBM's J9 or Jikes) is really really slow when doing
> crypto operations (which is what the IdP spends most of its time doing).
>
> Second, the reason endorsing Xerces and Xalan didn't work, when you tried with
> the Sun JDK, is that Tomcat overrides that mechanism. The shib install docs
> give you the directions for doing this in Tomcat:
> https://spaces.internet2.edu/display/SHIB2/IdPApacheTomcatPrepare
>
> Lastly, assuming you want to continue to try and use the IBM JDK, what exactly
> was generating that error? I'm guessing Tomcat since the IdP does not try to
> do anything with PKIX work. If that's the case your best bet is going to be
> to email the Tomcat list. I certainly don't have any real experience with IBM
> JDK + Tomcat.
The SLES 11 Tomcat like the openSUSE 11.1 Tomcat probably uses a
JAVA_ENDORSED_DIRS environment variable which is empty by default.
I've set
JAVA_OPTS="-Xmx1024M -XX:MaxPermSize=512M"
JAVA_ENDORSED_DIRS="/usr/share/tomcat6/endorsed"
in /etc/sysconfig/tomcat which works fine for my test IdP on openSUSE
11.1.
It's also possible to set the Java for Tomcat in /etc/sysconfig/tomcat
with JAVA_HOME so you can either change the default Java for the server
with 'update-alternatives --config java' or just the Java for Tomcat by
setting JAVA_HOME to the appropriate directory.
Best regards,
Bernd
-- --------------------------------------------------------------------- --
Dipl.-Math. Bernd Oberknapp Universitaetsbibliothek Freiburg
Tel: +49-761 / 203-3852 Rempartstrasse 10-16 | Postfach 1629
Fax: +49-761 / 203-3987 79098 Freiburg | 79016 Freiburg
Florian Götz
sorry for the long time between the answers, but there were too many other
things to do :(
I tried SLES11 with Java 1.6.0 from Sun now.
Used Xalan and Xerces with the Howto Chad send.
Had to change the JAVA_HOME for Tomcat to point towards the Sun Java, copied
the endorsed files into tomcat.
Java works with Tomcat6, Xalan and Xerces now.
I recovered my Shibboleth configuration and tried to start the servlet.
The moment he tries to get the metadata via https there is the PKIX error
again. Spelled a bit different, but I think this is due to the sun version.
09:49:05.979 - DEBUG
[org.opensaml.saml2.metadata.provider.HTTPMetadataProvider:228] - Refreshing
cache of metadata from URL https://www.aai.dfn.de/fileadmin/metadata/DFN-AAI-
Test-metadata.xml, max cache duration set to 2880 seconds
09:49:05.979 - DEBUG
[org.opensaml.saml2.metadata.provider.HTTPMetadataProvider:271] - Fetching
metadata document from remote server
09:49:06.580 - WARN
[org.opensaml.saml2.metadata.provider.FileBackedHTTPMetadataProvider:101] -
Unable to read metadata from https://www.aai.dfn.de/fileadmin/metadata/DFN-AAI-
Test-metadata.xml attempting to read it from local backup
javax.net.ssl.SSLHandshakeException:
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
[na:1.6]
at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1591)
[na:1.6]
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:187)
[na:1.6]
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:181)
[na:1.6]
As Bernd already wrote, the certificate files are part of the configuration, but
it seems that he tries to search the java keystore. This problem does not
occur on the Ubuntu system. I don´t have a clue what SLES does at this point.
I tried to create a keystore for the user "tomcat" as he is the one who starts
tomcat and should be the one who tries to access the keystore. But that didn´t
help either.
Anymore tips for me?
Best regards,
Florian
----------------------------------------------------------------------------------------
Dipl.-Inf. (FH) Florian Götz
Rechenzentrum Hochschule Mannheim
Paul-Wittsack-Straße 10
68163 Mannheim
Tel: 0621/292-6232
EMail: f.g...@hs-mannheim.de
Internet: http://www.rz.hs-mannheim.de
-----
Bernd Oberknapp
> As Bernd already wrote, the certificate files are part of the configuration,
> but it seems that he tries to search the java keystore. This problem does
> not occur on the Ubuntu system. I don´t have a clue what SLES does at this
> point.
>
> I tried to create a keystore for the user "tomcat" as he is the one who
> starts tomcat and should be the one who tries to access the keystore. But
> that didn´t help either.
>
> Anymore tips for me?
Since you use https for downloading the metadata, Java tries to verify
the certificate of the DFN-AAI website. This should work fine with Java
1.6.0_12 or newer. If you have to use an older Java version you can
import the Deutsche Telekom CA 2 certificate into the Java CA keystore
(a local keystore doesn't work). Or you can simply switch to http for
downloading the metadata.
Florian Götz
If I use keytool --importcert -file dtagxyz.crt the local users keystore is
used.
The path /etc/java-6-sun/security/cacerts like mentioned in the Howto from DFN
is not existent on the SLES11 system.
Best regards,
Florian
--
Bernd Oberknapp
> But how do I access the global CA keystore?
> If I use keytool --importcert -file dtagxyz.crt the local users keystore
> is used.
>
> The path /etc/java-6-sun/security/cacerts like mentioned in the Howto from
> DFN is not existent on the SLES11 system.
The path is /usr/lib/jvm/java-1.6.0-sun-1.6.0/jre/lib/security/cacerts for
openSUSE 11.1, should be the same for SLES11. But I would recommend to not
change the CA keystore but to upgrade to the latest Java 1.6.0 or switch
to http for downloading the metadata instead.
Florian Götz
from Sun does not create the proper links and stuff for SLES.
So I added the DTAG Root CA to the keystore under /usr/lib/jvm/java-1.6.0-
sun-1.6.0/jre/lib/security/cacerts.
Shibboleth IdP is now version 2.1.3, because I had to setup the machine again
and the new version was released already.
The Shibboleth servlet starts up properly, the metadata file gets copied (with
https) and everything seems to work fine so far.
Now I tried to test the whole stuff against the DFN
https://testsp2.aai.dfn.de/.
I get an error message from Shibboleth:
opensaml::FatalProfileException
The system encountered an error at Wed Sep 2 14:11:40 2009
To report this problem, please contact the site administrator at
root@localhost.
Please include the following message in any email:
opensaml::FatalProfileException at
(https://testsp2.aai.dfn.de/Shibboleth.sso/SAML2/POST)
SAML response contained an error.
Error from identity provider:
Status: urn:oasis:names:tc:SAML:2.0:status:Responder
Sub-Status: urn:oasis:names:tc:SAML:2.0:status:AuthnFailed
I read in a former Mail on the list (form Baljitt Chima) about a similar
failure. In that case the testSP had a problem.
Is the error mentioned above a failure at my Shibboleth IdP or on the TestSP?
Best regards,
Florian
--
Mit freundlichen Grüßen
Florian Götz
----------------------------------------------------------------------------------------
Chad La Joie
IdP logs and see what they sayd.
--
Florian Götz
errors. After the large java error the process goes on (after the dots below)
without any further warnings.
14:43:49.394 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:444] -
Completing user authentication process
14:43:49.394 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:503] -
Validating authentication was performed successfully
14:43:49.394 - ERROR
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:525] - No
user identified by login handler.
14:43:49.395 - ERROR
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:481] -
Authentication failed with the error:
edu.internet2.middleware.shibboleth.idp.authn.AuthenticationException: No user
identified by login handler.
at
edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine.validateSuccessfulAuthentication(AuthenticationEngine.java:526)
[shibboleth-identityprovider-2.1.3.jar:na]
at
edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine.completeAuthentication(AuthenticationEngine.java:467)
[shibboleth-identityprovider-2.1.3.jar:na]
at
edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine.service(AuthenticationEngine.java:213)
[shibboleth-identityprovider-2.1.3.jar:na]
.
.
.
.
.
14:43:49.396 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:162] -
Returning control to profile handler
14:43:49.396 - DEBUG
[edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:296] -
LoginContext not bound to HTTP request, retrieving it from storage service
14:43:49.396 - DEBUG
[edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:307] -
LoginContext key is '1ec85c9f-96ce-4809-a64d-a358077df3b9'
14:43:49.396 - DEBUG
[edu.internet2.middleware.shibboleth.idp.util.HttpServletHelper:310] -
parition: loginContexts
14:43:49.396 - DEBUG
[edu.internet2.middleware.shibboleth.idp.authn.AuthenticationEngine:170] -
Returning control to profile handler at: /profile/SAML2/Redirect/SSO
The message "No user identified by login handler" confuses me, because I don´t
even get the regular mask to type in a user or something. I went straight to
the error.
Best regards,
Florian
--
Chad La Joie
what leads the IdP to send back to the SP an authentication failed error.
Errors in the log file something, don't just ignore them and assume
nothing is wrong.
--
Florian Götz
I surely didn´t ignore the errors, or else I would not post a question here.
I just had no clue where the source of that error was.
But I found a tricky typo in the handler.conf and this problem is solved too.
Shibboleth Logins against the DFN Testsp2 are working fine now.
But the output of the website changed.
At the Shibboleth Login-page I get the Shibboleth Logo as usual and the
Username, Password Fields.But in between there are status messages:
<logo_as_usual>
Existing Session: false
Requested Authentication Methods: []
Attempting Authentication Method:
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
Is Forced Authentication: false
<username field>
<password field>
<login_button>
I know you have nothing to do with the DFN testsps and don´t know how they are
configured. But maybe this is a change in the IdP from 2.1.2 to 2.1.3?
Cause I didn´t have the status messages in 2.1.3 and didn´t change a single
bit of the login-page or the rest of the configuration compared to 2.1.2.
Thanks alot for all the help so far!
Best regards,
Florian
Chad La Joie
an *EXAMPLE* page. In 2.1.3 it became easier to access some of the
per-request specific information that the IdP tracks and the example
page was changed to reflect that. Per the documentation for the
username/password login handler you *should* be changing the login.jsp
file to meet the look and feel of your site.
Florian Götz wrote:
> Cause I didn´t have the status messages in 2.1.3 and didn´t change a single
> bit of the login-page or the rest of the configuration compared to 2.1.2.
Florian Götz
part is just the technical stuff behind.
Thanks for your help!
Best regards,
Florian