apache, shibboleth, load balancing alias, ssl

Posted on

apache, shibboleth, load balancing alias, ssl – Managing your servers can streamline the performance of your team by allowing them to complete complex tasks faster. Plus, it can enable them to detect problems early on before they get out of hand and compromise your business. As a result, the risk of experiencing operational setbacks is drastically lower.

But the only way to make the most of your server management is to perform it correctly. And to help you do so, this article will share nine tips on improving your server management and fix some problem about apache-2.2, ssl, load-balancing, alias, shibboleth.

Good morning folks

Could you give me a bit of help with the following problem ?

I have a dns load balancing mechanism and an alias (hostAlias) which
may point to host01, or host02

I want to configure apache and shibboleth to work with that alias.
What happens is …

User types : https://hostAlias (it points to host01)
apache host01 : redirect to shibboleth
shibboleth host01 : redirect to **https://hostAlias.cern.ch/Shibboleth.sso/ADFS**

Now, there are two cases. Either this time hostAlias will point again to host01 ,
or it will point to host02. If it points to host02, host01 will not get the anwser
and the authentication fails.

Also, about ssl certificates, I guess that each host will need its own certificate. right ?
Should I need a certificate with DNS aliases ?

Thanks in advance !

Solution :

A small caveat first, I’m aware what shibboleth is/does but haven’t implemented this setup so although definable I can think of a few gotchas that might trip it up. I’d suggest taking the question to the shibboleth-users list, as that’s where the users are =)

What you are trying should ‘just work’ as long as you can tie the auth flow to host01 or host02, this is SSO after all. If you do want to point the user back to the main domain as a “target” then there’s a chance they would be bumped to the other host and re authorised for the local service provider. This should work, the process could potentially be a bit dodgy, user experience wise, if they get flipped straight away and go through a long wait for multiple redirects or they have a manual step in the IDP process to POST back to your site (i.e. No JavaSript or an IDP that doesn’t track sessions well). So I think you are hitting the change mid auth.

User GET requests hostalias.com/protected
User redir to idp.com/sso?shire=host01.hostalias.com/sso&target=hostalias.com/protected
<IDP auth>
User POST to host01.hostalias.com/sso
host01.hostalias.com/sso redir to hostalias.com/protected

The gotcha may be if the shibboleth spec cares about using different domains for id/shire/target. I doubt this though.

The “clean” solution is a session manager that is able to share session state between your hosts. If you were doing the auth in a java app you could use a shared database, or a remote lookup if the local lookup failed etc. You would probably need this if your planning on scaling out horizontally with X hosts. The SP daemon has some options for sharing state this looks to be dependent on if apache would makes use of the SP for sessions.

Another option if you get stuck is to change your dns failover setup. If you map any new authenticated sessions to a host name (host01 host02 host0n) Then you can keep a user on that host. Do auth for that host. Then only failover to a new host when it’s down (or overloaded..)
This setup can present a few load balancing issue’s if links to one host start being used more and might take a little management. I’d only try this if there are issues with doing the above two.

SSL Certs are based on the hostname accessed. If you have multiple host names you want to be secured for clients you probably need multiple certificates. If you have multiple subdomain host names, you may be able to get a wildcard certificate instead. For the above setup I would suggest a wildcard for publicname, host01 and host02 .HostAlias.com.
The first and third method described above would need wilcard/multiple certs to cover clients accessing the different subdomains.

Leave a Reply

Your email address will not be published.