Kerberos Web Authentiation with Apache and Solaris 10
By wyllys on Mar 10, 2005
Single Sign On Web AuthenticationThis document describes how to configure the various pieces needed to setup a web server to participate in a Kerberos single-sign on (SSO) environment using a standard web server such as Apache or Microsoft IIS. This does not describe specialized Web-SSO systems such as that offered by the Access Manager product.
IntroductionWeb based SSO using Kerberos typically means following the specification that Microsoft released which describes how they do Kerberos auth for web. A copy of this (now expired) IETF draft is here.
SPNEGO is an IETF protocol that is used by GSSAPI applications to negotiate the underlying mechanism to be used. It is known as RFC 2478. This is NOT designed specifically for HTTP use and it was not written for the sole purpose of facilitating web-based SSO. There are other security protocols that make use of it, most notably SASL, which is used often for secure LDAP authentication.
There are 3 pieces needed in order to enable this functionality for Single-Sign On Web authentication:
- A browser that supports the "WWW-Authenticate: Negotiate" header
- A web server that supports the "Negotiate" authentication feature of HTTP
- A Kerberos realm and working KDC that issues tickets to the users.
BrowsersCurrently, there are 3 browsers that support the "Negotiate" authentication extension.
Mozilla and FirefoxOnce you have the necessary browser, you must configure it to support the feature, it is not typically enabled by default. For Mozilla and Firefox, you may need to adjust a couple of private user preferences so that the authentication will be allowed on a non-secure connection (i.e. not SSL).
Setting the PreferencesIn the URL window, enter about:config. This brings up a complete list of user preferences that can be set.
Parameters for Mozilla and Firefox
- network.negotiate-auth.delegation-uris = https://,http://
- network.negotiate-auth.trusted-uris = https://,http://
Be default, these are usually restricted to just work on "https://" connections (secured by SSL). You may add non-SSL to the allowed list by setting the value to look like this: https://, http://.
You change the values in this window by double-clicking on the preference you wish to set. This brings up a window that allows you to enter a new value.
Microsoft Internet ExplorerTo configure IE to allow for SSO authentication:
- click on the "Tools" menu in the toolbar at the top.
- Select the "Internet Options" item at the bottom of the menu.
- Select the "Advanced" tab in the options window that should appear.
- Scroll down through the various options until you find the section for "security".
- Click in the box next to "Enable Integrated WIndows Authentication" so that it appears with a check in the box to indicate that it is enabled.
- Log out and log-back into Windows as a user in a Kerberos realm (either AD or SEAM/MIT) using your name and realm in the login window. Ex: wyllys@SUN.COM
This assumes your windows box is already participating in a Kerberos realm, either managed by Active Directory, or the box is configured to use a non-Windows KDC such as SEAM or MIT. Instructions for setting this up are here: Setting up Kerberos Interop on Windows.
Web Server ConfigurationThe other important part of the Web-SSO equation is having a properly configured HTTP server that supports the NegotiateAuth extension. Microsoft IIS already supports this and there are extensions for Apache that also enable this feature.
Solaris 10 Apache ConfigurationApache supports extensions to it's authentication system so third parties may add new features easily, without modifying the core Apache engine. There are a couple of extensions available that support the "NegotiateAuth" exchange.
Solaris 10 GSS Authentication Modulemod_auth_gss is an Apache module that enables support for the "NegotiateAuth" exchange on Unix/Linux systems which have GSSAPI support. It only uses GSSAPI to do send either SPNEGO or KRB5 authentication tokens. The user must have a valid Kerberos ticket in their personal credential cache in order for this to work correctly, no passwords are used by the protocol. The user is never prompted for a password and thus the authentication occurs without user interaction, thus "Single Sign On" is achieved.
The benefit of this module over the next one (below), is that it is purely GSSAPI based and does not require access to raw Kerberos libraries in order to compile or run, it only need to link with libgss.so.1. It will support GSSAPI authentication using either SPNEGO (if its available on the system) or Kerberos V5. Currently, only Solaris 10 and Microsoft Windows XP/2000/2003 have SPNEGO support. On other systems, it is assumed that GSSAPI-KRB5 tokens will be used by the client. Other open source Kerberos distributions like Heimdal will soon be (if they haven't already) be offering a SPNEGO mechanism now that the SPNEGO spec has been updated.
The module shipped in Solaris 10's Apache area supports both 1.x and 2.x versions of Apache. The use of SSL encryption is also recommended (but not required).
- mod_auth_gss is bundled with Apache in Solaris 10. By default, it is installed in /usr/apache/libexec
- Configuration Instructions
mod_auth_krb5mod_auth_krb5 is an open-source module that enables support for Kerberos SSO authentication through the NegotiateAuth extension. This module supports the standard GSSAPI + SPNEGO token exchange used in the Microsoft implementation. It also has a couple of nice "extra" features such as the ability to use the password given in the authentication exchange and have the web server request a ticket for the user. This is quite different from the GSSAPI SSO model and is not secure on a non-SSL protected connection because the password passes over the wire virtually unprotected. This method is provided merely as a convenience feature and is not recommended for security.
The downside of this module is that it does not compile on Solaris and use the native Solaris Kerberos code because Solaris does not export the raw Kerberos APIs. Thus, this module requires that the user install a third party Kerberos implementation like MIT or Heimdal in order to build the module. Doing so, the implementor loses the features of the native Kerberos and GSSAPI on Solaris.
IIS ConfigurationIf you are testing with an IIS web server, the only thing to do is go into the IIS configuration and change the security properties for the areas that you wish to protect so they are using "Integrated Windows Authentication".
1. Set up Kerberos Server (if you don't already have one). Follow basic instructions given in the SEAM documentation at docs.sun.com.
The KDC should be a protected, standalone system. But for internal testing purposes it may be hosted on the same system as the Apache web server.
2. Create a Kerberos service key for the Apache server to use for authenticating the clients. Also create a user principal testing the browser later. The "Negotiate" method used by IIS and IE looks for a principal named "HTTP/f.q.d.n@REALM" (f.q.d.n == Fully Qualified Domain Name). To create this principal for use with the Apache module do the following: [As 'root', on the Apache server]
a. /usr/sbin/kadmin - this assumes the KDC setup procedure was followed (step 1). b. kadmin: addprinc -randkey HTTP/www.foo.com c. kadmin: ktadd -k /var/apache/http.keytab HTTP/f.q.d.n d. kadmin: addprinc tester e. kadmin: quit
Testing the 'Negotiate' plugin with mozilla
1. The client system (Solaris 10) must be configured to use Kerberos. Setup /etc/krb5/krb5.conf to use the KDC created earlier
2. kinit to get a TGT as the "tester" principal created
above in step 2d.
$ kinit tester ( enter password )
3. Use mozilla (with 'negotiateauth' extension installed) to access the Kerberos protected pages on your web server.
If it doesn't work, enable the "GSSDebug" variable in the Apache configuration file (see the the Configuration Instructions) and check the Apache "error_log" to see if any messages are being generated that might help indicate the problem.
Before using GSSAPI authentication with Apache, the system must already have been configured to use Kerberos V5 authentication. All of the major Kerberos V5 implementation (MIT KRB5, Heimdal, Sun, IBM, HP, Microsoft) currently support Kerberos V5 GSSAPI mechanisms. Configuring Kerberos is beyond the scope of this document. Adding GSSAPI authentication support to the web extends Single sign on capabilities to the intranet and reduces the risks involved in having users constantly entering username/password combinations when accessing websites.
Configure a Service Principal
The default service principal that mod_auth_gss will try to use is "HTTP/f.q.d.n". The key for this principal must be stored in a keytab file that is readable by the Apache server, but it should be protected from access by anyone else, and should definitely not be stored in an area that can be browsed by clients.
Example: the Apache server is on host "www.foo.com".
Create a principal called "HTTP/www.foo.com".
Store the key for this principal in a protected keytab
file. Using MIT Kerberos V5:
$ kadmin $ kadmin> ktadd -k /var/apache/http.keytab HTTP/www.foo.com $ kadmin> quit
Once the keys are created and stored, using GSSAPI
authentication is very simple. Set up the authentication
type for the directories being protected to be "GSSAPI".
If the keytab or service name chosen is not the defaults
("HTTP" and "/var/apache/http.keytab", respectively), then
you may use the above mentioned directives to override
the default values. Example:
<Location /var/apache/htdocs/krb5> AuthType GSSAPI ServiceName HTTP KeytabFile /var/apache/http.keytab GssDebug 0 Require valid-user AllowOverride AuthConfig </Location>
GSSAPI authentication provides a more secure authentication system, but only works with supporting browsers.
It is recommended that this authentication method be combined with TLS security (mod_ssl, for example) to further secure the authentication data being exchanged.