Report of success with SP and IdP test servers, apache 1.3, nginx and SSL off-loading
Gernot Hassenpflug
ha4h-grnt at asahi-net.or.jp
Fri Apr 20 10:18:41 BST 2012
Hello,
My name is Gernot Hassenpflug. I work for a Japanese company in Tokyo,
and we are starting to use Shibboleth as an authentication provider
for some of our academic clients to whom we provide course content
management and portfolio software.
I'd like to lay out below my experience setting up several variations
of a shibboleth SP and IdP in-house on CentOS4.8 servers. Most of the
setup is on the SP side.
If it is all bog-standard as far as the developers and expert
shibboleth users are concerned, then at least it can stand as an
example for users just starting out with configuring shibboleth.
Codebase:
---------
IdP: latest IdP code 2.3.6 (previously 2.1.5 also), with Tomcat 5.5.35,
Sun JVM 1.6.0_30-b12 and apache 2.2.21.
SP: latest SP code 2.4.3 and associated packages installed from
created SRPMs; and apache 1.3.37 (yes!) with mod_perl 1.30,
mod_ssl 2.8.28, openssl 0.9.8n, and nginx (0.7.64).
Note 1: also set up to run with apache 2.0 as a test.
Note 2: the reason to install from source instead of using
available SP packages in shibboleth repository, is that
the provided apache mod_shib is only for the
system-recommended apache: so if one wishes to obtain
other versions of mod_shib, one has to compile from
scratch (or not?).
Note 3: the application we are running runs on CentOS4.8 and uses
specific software package versions (apache 1.3 and
associated modules), perl modules and MySQL 4.1. While
upgrading the application and database is underway, we
cannot ensure reliability at this stage, and plan to run
as-is for current production servers (>100).
IdP Installation/Configuration:
-------------------------------
IdP installation was largely trouble-free, using available RPMs on
shibboleth SUSE download site, and currently uses a mixture of
htpasswd file for usernames and static sources in the
attribute-resolver.xml file to provide test data (attributes) to the
SP (available in the REMOTE_USER environment variable exported by
apache on the SP side).
Next step will be to utilize an LDAP database source, already studied
on working system at NII in Tokyo (a Japanese institute closely
associated with the Japanese Shibboleth Federation).
Metadata from the IdP was simply copied to the SP server and accessed
as a backed file.
SP Installation:
----------------
SP installation was also largely trouble-free, using available RPMs
from shibboleth SUSE download site, once the method of rebuilding RPMs
from the shibboleth SRPM packages and associated software was
understood.
Important notes:
- shibboleth repository must be added to CentOS4.8.
- shibboleth repository runtime packages must *not* be installed.
- several shibboleth repository *-devel packages *must* be installed
(else either the creation of SRPMs, or installation of some of the
created shibboleth RPM packages will fail).
Changes from example-shibboleth2.xml:
1. Site element additions:
scheme="https"
port="443"
2. Site element name, and RequestMap block Host element name changed.
3. ApplicationDefaults element entityID and homeURL changed.
4. IdP entityID changed.
5. Mail address changed.
6. Metadata provider element added, with "file" set to IdP metadata
file location on local storage ("type" set to "XML").
7. CredentialResolver element key and certificate values changed.
SP configuration:
-----------------
I tried three different setups, all of which work perfectly.
Locations are protected with:
AuthType shibboleth
ShibRequestSetting requireSession 1
Require valid-user
1) apache 1.3 (+ mod_shib) with SSL as single web server (no separate
front-end and back-end servers).
This works fine, loading mod_shib in the apache configuration file,
defining a protected location (both a stand-alone location and one
whose URL is rewritten and then processed by mod_perl).
Note: In apache, the server to access is a virtual server which
uses SSL. In this simple configuration there is no need to
virtualise the port number. The name however is virtualized (but is
the same as the name in the un-virtualized part of the apache
configuration, and also the same as the server hostname). On
important setting (although not needed in this case):
- UseCanonicalName On
SP configuration is the original one modified with SP and IdP
identities, home location, metadata backing files and certificates.
Changes in References below.
2) apache 1.3 (+ mod_shib) with SSL as back-end server; with nginx
with SSL as front-end server (both servers using SSL).
This works fine also, however it requires proper virtualization in
the virtual server defined in apache.
Both servers use SSL. The front-end server (nginx), running as a
reverse proxy, listens on port 443, and proxy-passes requests to
the shibboleth-enabled back-end apache 1.3 server on port 81 over
SSL (originally our application did not use SSL for this part, so I
left the port number as-is).
The apache 1.3 server listens on port 81. The SSL-enabled virtual
server defined in the apache configuration file is virtualized:
- The server name is virtualized by setting it (as above).
- The port is virtualized by using the "Port 443" directive.
- UseCanonicalName On
The SP configuration is identical to the one for the 1st case.
3) apache 1.3 (+ mod_shib) *without* SSL as back-end server; with
nginx with SSL as front-end server (off-loading SSL to nginx,
terminating it there).
This works fine (also exposed a bug in our application which used
the schema to decide how to write URLs that it generates).
The front-end server (nginx) uses SSL, listening on port 443, and
proxy-passes requests to the shibboleth-enabled back-end apache 1.3
server on port 81 (straight HTTP now, no SSL).
The apache 1.3 server listens on port 81. The virtual server
defined in the apache configuration file (and which does not
understand HTTPS) is virtualized so that self-referencing URLs
created by the SP use the HTTPS scheme:
- The server name is virtualized by setting it (as above).
- The port is virtualized by using the "Port 443" directive (as
above).
- The scheme is virtualized using the mod_shib directive
"ShibURLScheme https" after loading mod_shib_13.so.
- UseCanonicalName On
The SP configuration is identical to the one for the 1st case.
References:
-----------
https://wiki.shibboleth.net/confluence/display/SHIB2/SPReverseProxy
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPApacheConfig
--
Gernot Hassenpflug
More information about the users
mailing list