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.
...
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
| Info |
|---|
This is a much simpler implementation than my original. I think it works better all around. |
Enable apache rewrites
| Code Block |
|---|
RewriteEngine on RewriteLog /logs/rewrite.log RewriteLoglevel 0 |
...
| Code Block |
|---|
<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.
...
Choose a login path
For this example we'll use "/login". You could also use "/secureloign", for example, for 2-factor logins. Note that we don't protect the 'logiin' path with shibboleth. Instead we protect a hidden path. Call it "/login-shib".
Choose an 'in-progress' cookie
...
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 the login path but and proxy to the host that processed the /Shibboleth.sso.
| Code Block |
|---|
# 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
...
Rewrite unproxied logins to the protected path
This is to catch the initial redirect to login.
| Code Block |
|---|
RewriteCond %{REQUEST_URI} /login
RewriteCond %{HTTP_COOKIE} !splogin
RewriteRule ^/login/(.*)$ /login-shib/$1 [PT] |
Protect the real shib login path
Any require lines should be OK.
| Code Block |
|---|
<LocationMatch /login-srv1x>shib> 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. redirect from /Shibboleth.sso we need to gather the shib attributes. This has to be just "require shibboleth".
| Code Block |
|---|
<LocationMatch /login-srv2x>login> 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.
| Code Block |
|---|
# 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.
...