SSO-plus-SSL and Shibboleth: What options for sites with numerous virtual hosts?

Question

Background: Customer X is a low-budget non-profit outfit that nonetheless has a lot of activity configured on virtual hosts, and the virtual hosts multiply very frequently. Customer X also has a lot of users and is interested in getting them over to a single sign on solution. This way, all the users can use the same credentials on all the virtual hosts.

It has also pretty much been mandated that we use Shibboleth Single-Sign-on to handle the authentication.

Problem: Shibboleth Single Sign On uses SSL as part of its protocol, but getting multiple virtual hosts to use SSL is not a walk in the park. This question about virtual-hosts with SSL details some of the pitfalls.

Question: What is the best way to proceed with this scenario (summary):

• multiple virtual hosts on apache
• setting up a distinct IP and NIC for each virtual host is pretty much not an option
• SSL pretty much requires a separate IP
• they all need some kind of SSO
• we are being heavily pressured to use Shibboleth as the SSO provider

Is there anything we may be missing here or some way to resolve this, short of requiring a separate IP for all vhosts?

Answer 1

Hi drefy. I have a client with the exact same situation and the way that they solved it was to buy a wildcard domain *.xxx.com and have all the virtual hosts have a specific subdomain at xxx.com to get around this problem.

This was with Shibboleth and did work out, although you need the hosts domains to agree to fall under one parent domain for the SSO.

Answer 2

If the data itself you exchange with the given site (the Service Provider) is not security sensitive you can just turn off SSL for accessing the site.

There are two SSL channels we are talking about.

• one used when the SP communicates with the IDP
• the other is accessing the site

Only the latter one should be a "well-known" (what you have to pay for) certificate.

One can use HTTP artifacts to avoid POSTing data from the idp (which is SSL protected) to the SP which is not. This way the browsers security warning can be avoided.

This setup still protects user credentials. The data you exchange with the site will be not.