Which handler LDAP SSO - NOW kerberos integration
Morris, Andi
amorris at cardiffmet.ac.uk
Fri Nov 21 09:32:03 EST 2014
OK, this sparked my interest some more, so I started again and decided to follow the path to getting Apache and mod_auth_kerb working with REMOTE_USER.
I followed the usual steps to get Oracle JDK setup and running as the default
Followed the instructions I have to get Apache setup and configured for listening on ports 443 and 8443.
Listen 443
Listen 8443
<VirtualHost _default_:443>
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLOptions +StdEnvVars
SSLCertificateFile /opt/shibboleth-idp/credentials/cert.crt
SSLCertificateKeyFile /opt/shibboleth-idp/credentials/cert.key
#SSLCertificateChainFile /opt/shibboleth-idp/credentials/AddTrustExternalCARoot.crt
ErrorLog logs/ssl_443_error_log
TransferLog logs/ssl_443_access_log
LogLevel warn
CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
<VirtualHost _default_:8443>
SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLOptions -StdEnvVars +ExportCertData
SSLCertificateFile /opt/shibboleth-idp/credentials/idp.crt
SSLCertificateKeyFile /opt/shibboleth-idp/credentials/idp.key
#SSLCertificateChainFile /opt/shibboleth-idp/credentials/intermediate.ca-bundle
SSLVerifyClient optional_no_ca
SSLVerifyDepth 10
ErrorLog logs/ssl_8443_error_log
TransferLog logs/ssl_8443_access_log
LogLevel warn
CustomLog logs/ssl_request_log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
</VirtualHost>
Installed shibboleth
I then went through the steps at :
http://research.ncl.ac.uk/gfivo/documents/UsingKerberosticketsfortrueSingleSignOn.pdf
Adjust httpd.conf to show ServerName and UseCanonicalName as:
ServerName idp.dev.cardiffmet.ac.uk
UseCanonicalName On
Setup Kerberos on the server and verified that it was working with kinit commands.
Configured auth_kerb.conf as:
LoadModule auth_kerb_module modules/mod_auth_kerb.so
<Location /idp/Authn/RemoteUser>
SSLRequireSSL
AuthType Kerberos
AuthName "Shib Kerberos Login"
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbAuthRealms INTERNAL.NETWORK.COM
Krb5KeyTab /etc/shib.keytab
KrbSaveCredentials On
KrbServiceName HTTP/idp.dev.cardiffmet.ac.uk at INTERNAL.NETWORK.COM
require valid-user
</Location>
Configured the apache proxy pass onto the tomcat connector on 8009
ProxyPass /idp/ ajp://127.0.0.1:8009/idp/
Configured Tomcat to listen on port 8009 and to redirect that traffic onto 8443
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="8009" request.tomcatAuthentication="false"
address="127.0.0.1" enableLookups="false"
protocol="AJP/1.3" redirectPort="8443" />
Setup the 8443 connector in Tomcat
<Connector port="8443"
maxHttpHeaderSize="8192"
maxSpareThreads="75"
scheme="https"
secure="true"
SSLEnabled="true"
sslProtocol="TLS"
clientAuth="want"
keystoreFile="/opt/shibboleth-idp/credentials/idp.jks"
keystorePass="changeit"
truststoreFile="/opt/shibboleth-idp/credentials/idp.jks"
truststorePass="changeit"
truststoreAlgorithm="DelegateToApplication"
protocol="org.apache.coyote.http11.Http11Protocol" />
However I now get errors in Catalina.out as below:
---------------------------------------------------------------------------------------------------------------
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=128m; support was removed in 8.0
Nov 21, 2014 2:16:34 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
Nov 21, 2014 2:16:35 PM org.apache.coyote.http11.Http11Protocol init
SEVERE: Error initializing endpoint
java.io.IOException: DelegateToApplication TrustManagerFactory not available
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.init(JSSESocketFactory.java:465)
at org.apache.tomcat.util.net.jsse.JSSESocketFactory.createSocket(JSSESocketFactory.java:130)
at org.apache.tomcat.util.net.JIoEndpoint.init(JIoEndpoint.java:538)
at org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:176)
at org.apache.catalina.connector.Connector.initialize(Connector.java:1007)
at org.apache.catalina.core.StandardService.initialize(StandardService.java:677)
at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795)
at org.apache.catalina.startup.Catalina.load(Catalina.java:540)
at org.apache.catalina.startup.Catalina.load(Catalina.java:560)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:261)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Nov 21, 2014 2:16:35 PM org.apache.catalina.startup.Catalina load
SEVERE: Catalina.start
LifecycleException: Protocol handler initialization failed: java.io.IOException: DelegateToApplication TrustManagerFactory not available
at org.apache.catalina.connector.Connector.initialize(Connector.java:1009)
at org.apache.catalina.core.StandardService.initialize(StandardService.java:677)
at org.apache.catalina.core.StandardServer.initialize(StandardServer.java:795)
at org.apache.catalina.startup.Catalina.load(Catalina.java:540)
at org.apache.catalina.startup.Catalina.load(Catalina.java:560)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:261)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Nov 21, 2014 2:16:35 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 899 ms
Nov 21, 2014 2:16:35 PM org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
Nov 21, 2014 2:16:35 PM org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.24
Nov 21, 2014 2:16:35 PM org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor idp.xml
------------------------------------------------------------------------------------------------------------------------
Commenting out the 8443 connector in Tomcat means that the service will start properly, and I suspect that it's because Apache and Tomcat are both told to listen on 8443, however I'm firstly surprised that the output doesn't say that, as I've seen in other mailing list entries, and secondly, commenting the 'Listen 8443' part of Apache's ssl.conf doesn't resolve the issue.
Have I missed something to do with this Apache/Tomcat integration?
Cheers,
Andi
-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: 19 November 2014 17:52
To: Shib Users
Subject: Re: Which handler LDAP SSO - NOW kerberos integration
On 11/19/14, 5:43 PM, "Morris, Andi" <amorris at cardiffmet.ac.uk> wrote:
>Very fair points, and I wasn't having a dig at anybody, or the project
>in general.
I didn't take it that way in any sense, I just wanted to explain some of why it's not in the state we'd like.
>I'm going to have to get around this somehow as I just can't see the
>internal departments being at all happy if I can't get integrated logon
>working in the new version, when it worked in the old. So tomorrow,
>fresh install, start again, and try to get spnego working once more.
As an option, you could do it in Apache with mod_auth_kerb worst case, and pass in REMOTE_USER.
But if you're saying that everybody accessing the IdP can use SPNEGO, then the error handling issues that make this so painful go away for the most part and it should be much cleaner either way. If not, the pain here is because SPNEGO (and HTTP authentication in general) is just badly designed for these kinds of environments.
-- Scott
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
More information about the users
mailing list