Shibboleth SP amb múltiples VirtualHosts

Objectiu:

Ens podem trobar amb el cas que disposem de diverses aplicacions web en el mateix servidor apache, configurats mitjançant VirtualHosts i cadascun d’ells volem que autentiqui mitjançant Shibboleth. L’objectiu d’aquesta entrada és configurar Shibboleth en aquesta situació creant un host virtual a Shibboleth per a cada VirtualHost d’apache.

Introducció:

Partim de la base que disposem d’un idp i un sp configurats com s’ha explicat en entrades anteriors.

Apache2 presentarà una configuració de VirtualHosts similar a la següent:

...
<VirtualHost *:80>
        ServerName https://sp1.domain.org:443/
	UseCanonicalName on
        DocumentRoot /var/www/secure

	<Directory /var/www/secure>
		AuthType shibboleth
		ShibRequireSession On
		require valid-user
	</Directory>
</VirtualHost>

<VirtualHost *:80>
        ServerName https://sp2.domain.org:443/
	UseCanonicalName on
        DocumentRoot /var/www/secure2

	<Directory /var/www/secure2>
		AuthType shibboleth
		ShibRequireSession On
		require valid-user
	</Directory>
</VirtualHost>
...

NOTES:

  • Aquesta configuració, en el port 80, suposa que l’apache està darrere d’un servei que fa SSL offloading. S’hi accedeix pel port 80. Si no fos així es podria fer la configuració directament sobre un VirtualHost en el port 443.
  • ServerName utilitza el nom segur (https) per evitar problemes amb l’idp.
  • UseCanonicalName s’utilitza per forçar la creació de URL vàlides per l’idp.

Configuració de Shibboleth a l’SP:

Al directori /etc/shibboleth, com ja venim d’un sp configurat anteriorment, tenim el certificat i la clau per defecte creades durant la instal·lació. Canviem el nom de les credencials originals i en generem unes de noves pel nou servei:

$ mv sp-cert.pem sp1-cert.pem
$ mv sp-key.pem sp1-key.pem
$ shib-keygen -f -h sp2.domain.org -y 3 -e https://sp2.domain.org/shibboleth
$ mv sp-cert.pem sp2-cert.pem
$ mv sp-key.pem sp2-key.pem

A l’arxiu /etc/shibboleth/shibboleth2.xml modifiquem el nom de les credencials originals:

...
        <CredentialResolver type="File" key="sp1-key.pem" certificate="sp1-cert.pem"/>
...

Modifiquem l’entrada RequestMapper i afegim el nou Host:

...
    <RequestMapper type="Native">
        <RequestMap applicationId="default">
            <Host name="sp1.domain.org" authType="shibboleth" requireSession="true"/>
            <Host name="sp2.domain.org" applicationId="sp2" authType="shibboleth" requireSession="true"/>
        </RequestMap>
    </RequestMapper>
...

En aquesta configuració és important definir l’applicationId del segon servei amb un nom que utilitzarem a continuació per sobreescriure els paràmetres per defecte de l’aplicació per defecte. A l’arxiu /etc/shibboleth/shibboleth2.xml al final de l’entrada ApplicationDefaults afegim el següent:

...
        <ApplicationOverride id="sp2" entityID="https://sp2.domain.org/shibboleth">
             <CredentialResolver type="File" key="sp2-key.pem" certificate="sp2-cert.pem"/>
        </ApplicationOverride>
    </ApplicationDefaults>
...

Finalment reiniciem el servei shibd a l’sp:

$ service shibd restart;

Configuració en l’idp:

A l’idp només s’ha d’afegir la configuració per registrar un nou proveïdor de serveis com ja sabem fer-ho d’entrades anteriors. A l’arxiu /opt/shibboleth-idp/conf/relying-party afegirem:

...
        <metadata:MetadataProvider id="SP2MD" xsi:type="metadata:FileBackedHTTPMetadataProvider"
                          metadataURL="https://sp2.domain.org/Shibboleth.sso/Metadata"
                          backingFile="/opt/shibboleth-idp/metadata/sp2-metadata.xml">
        </metadata:MetadataProvider>
...

Finalment reiniciem l’idp:

$ service tomcat6 restart;