Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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 !

share|improve this question

1 Answer 1

up vote 1 down vote accepted

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.

share|improve this answer
    
One can get a certificate that is valid for multiple host names. –  cstamas Dec 2 '12 at 7:40
    
Good to know. How do they stack up cost wise against wildcard? –  mtm Dec 2 '12 at 10:26
    
I would think that a wildcard cert is more expensive, but it depends on your contract with a CA. –  cstamas Dec 3 '12 at 17:47

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.