NativeSPClusteringByProxy

If you use Apache and all you need Shibboleth for is to create your application's own session you don't really need any host affinity at all.  You can use proxying to assure that all login activity occurs on the same host.

Example application

This is only a guide.  Your installation and experience will differ.

Assume an implementation like this:

• You have several hosts supporting an application.
  
  • App is: 'app.example.edu'
  • Hosts are: 'srv1.s.example.edu', 'srv2.s.example.edu', 'srv11.s.example.edu'.
• To initiate a session your app redirects users to, say, "/login/...", a Shib protected location, where you generate an application session (with cookie) and redirect users back to "/app/...".

So, the accesses during a login are:

1. (user needs login)
2. /login/...
3. (user dialog with an IdP)
4. /Shibboleth.sso/...
5. /login/...

6. (back to the app with a session)

For the shibboleth part of the login to work '4' and '5' have to be on the same host.  Starting with about version 2.4 we cannot proxy '4'.  Its verification of server name is not optional.  So we have to proxy the return to the login ('5').

SP Configuration

Enable apache rewrites

RewriteEngine on
RewriteLog /logs/rewrite.log
RewriteLoglevel 0

Disable address checking

The proxied requests will come from the peer host, not the browser.

<Sessions checkAddress="false" consistentAddress="false" ...>

Configure distinct login paths on each host in the cluster

The most common way to 'protect' a login URL is with a '<Location>' directive.  The problem is that these directives are processed even when the request is going to be proxied---not what we want.  So each host has to trigger shibboleth login on only its own login URLs.

In our example we might switch to:

• /login-srv1x/ on the srv1 host,
• /login-srv2x/ on the srv2 host, and
• /login-srv11x/ on the srv11 host.

The appended 'x' is so that '/login-srv1' doesn't accidentally match '/login-srv11'.

Choose an 'in-progress' cookie

For this example we'll use "splogin".

Notify peers when the local host processes the /Shibboleth.sso

Set the appropriate cookie.  This for host srv1:

RewriteCond %{REQUEST_URI} /Shibboleth.sso
RewriteRule ^(.*)$  - [CO=splogin:srv1x:app.example.edu:1:/:secure]

Similar configuration for the other hosts.

Proxy logins started on peer hosts

Detect both by cookie and path.  This again for host srv1.

Note that the login path might be from any of the cluster members.  We need to detect any login path but proxy to the host that processed the /Shibboleth.sso.

# login session on srv2
RewriteCond %{REQUEST_URI} /login-srv
RewriteCond %{HTTP_COOKIE} splogin=srv2x
RewriteRule ^/(.*)$  https://srv2.s.example.edu/$1 [P]

# login session on srv11
RewriteCond %{REQUEST_URI} /login-srv
RewriteCond %{HTTP_COOKIE} splogin=srv11x
RewriteRule ^/(.*)$  https://srv11.s.example.edu/$1 [P]

Place similar configurations on the other hosts.

Trigger shibboleth on the local login path

This again for srv1.  Others would be similar.

<LocationMatch /login-srv1x>
AuthType shibboleth
ShibRequireSession On
require valid-user
order allow,deny
allow from all
</LocationMatch>

Let shibboleth silently handle the other host login paths.

When handling the return from the IdP the path may have come from another host.  We need shibboleth to look at it. This again for srv1. 

<LocationMatch /login-srv2x>
AuthType shibboleth
require shibboleth
order allow,deny
allow from all
</LocationMatch>

<LocationMatch /login-srv11x>
AuthType shibboleth
require shibboleth
order allow,deny
allow from all
</LocationMatch>

Catch login starters on the wrong path.

This proxy-cluster method requires different login paths on each host.  That introduces an additional complication.  The initial redirect for login, from /app/ → /login-srv1x/, (if initial contact on srv1) might get handled by srv2.  If that happens it won't trigger a shib login.  So we need to detect that initial redirect and rewrite to the correct, local path.  This again for srv1.

# handle errant login starters
RewriteCond %{REQUEST_URI} /login-srv
RewriteCond %{HTTP_COOKIE} !splogin
RewriteRule ^/login-srv2x/(.*)$  /login-srv1x/$1 [PT]
...

Testing

I use webisoget to test the proxy setup.  Use its '-maxhop 1' option to single step through the many login redirections.  You have to use your /etc/hosts file to direct the requests to particular hosts.  The '-map' option won't work because libcurl caches mapped dns addresses and there's no way to prevent that (short of editing libcurl).  The /etc/hosts file works well, though.  You may want to increase the lifetime of your cookies during testing.

That's it!

I think.