Principe de Shibboleth

tomcatAuthentication="false"

Configuration Apache - mod_shib

La mise en place du SP Shibboleth sur le serveur Apache va se faire via l'activation du module mod_shib, fourni avec le SP.

Il conviendra donc d'ajouter le chargement du module à la configuration du serveur httpd :

LoadModule mod_shib $SP_HOME/lib/shibboleth/mod_shib_xx.so

Une fois le module chargé, on va pouvoir le configurer. On va dans un premier temps protéger le handler Shibboleth qui permettra, entre autre, d'obtenir des informations sur le SP (Session en cours, statut, metadata...) :

...
UseCanonicalName On
ServerName localhost

<Location /Shibboleth.sso>
    SetHandler shib
</Location>
...

On peut également ajouter un script qui permettra de tester l'identification par Shibboleth, et qui affichera les informations transmises dans le header :

...
ScriptAlias /secure $APACHE_HOME/cgi-bin/printenv.pl
<Location /secure>
   AuthType shibboleth
   ShibRequestSetting requireSession 1
   ShibRequestSetting applicationId default
   require valid-user
</Location>
...

L'utilisation de ce script est expliquée dans la partie Tests de fonctionnement ci-dessous.

Enfin, il reste à protéger l'URL de login du portail pour forcer une authentification via Shibboleth quand un utilisateur accèdera à cette URL :

...
<Location /uPortal/Login >
    AuthType shibboleth
    ShibRequestSetting requireSession 1
    ShibRequestSetting applicationId default
    require valid-user
</Location>
...

Configuration du SP

L'identification se fait via des attributs LDAP remontés par l'IdP. Il faut donc s'assurer que le SP est bien configuré pour transmettre dans le remote user le bon attribut. Par défaut, l'attribut servant à l'authentification est l'uid (défini par le paramètre environment.build.ldap.uidAttr du filtre esup.properties). Il convient donc de modifier la configuration du SP (shibboleth2.xml) pour l'ajouter :

<ApplicationDefaults entityID="<entityID du SP>"
                         REMOTE_USER="uid eppn persistent-id targeted-id">

Le tutoriel de la féderation Renater détaille ici certains éléments de configuration du SP, notamment les paramètres du nœud ApplicationDefaults. Parmi ceux-ci, le paramètre SSO (ancien SessionInitiator) va notamment permettre de définir la façon dont Shibboleth gère les demandes de session.

Par exemple, en définissant la balise de la façon suivante :

<SSO discoveryProtocol="SAMLDS" discoveryURL="https://services-federation.renater.fr/test/wayf">
    SAML2 SAML1
</SSO>

Ici, le SP va utiliser un procole SAMLDS (Discovery Service), qui se fera via le WAYF précisé, pour l'identification. Le protocole SAML2 sera utilisé en priorité, et s'il n'est pas supporté, c'est SAML1 qui le sera.
Plus d'informations sur les valeurs possibles pour ce paramètre sont détaillées sur le wiki Shibboleth.

Il est également possible de filtrer dans ce fichier de configuration les IdP qui auront (whitelist) ou n'auront pas (blacklist) accès à l'application. La fédération Renater décrit ici la configuration à adopter.

Configuration uPortal

Une fois le serveur frontal configuré avec le SP, il faut configurer uPortal pour l'authentification via Shibboleth. L'authentification se fait par REMOTE_USER : l'utilisateur est identifié par Shibboleth, et est transmis à uPortal. Il va donc falloir faire les changements nécessaires.

Classes d'authentification

Les premières modifications sont à faire dans uportal-war/src/main/resources/properties/security.properties. Au début du fichier sont placées les classes d'authentification :

...
## This is the factory that supplies the concrete authentication class
root=org.jasig.portal.security.provider.UnionSecurityContextFactory
root.cas=org.jasig.portal.security.provider.cas.CasAssertionSecurityContextFactory
#root.cas=org.jasig.cas3.extensions.clearpass.integration.uportal.PasswordCachingCasAssertionSecurityContextFactory
root.simple=org.jasig.portal.security.provider.SimpleSecurityContextFactory
...

On va y ajouter la ligne suivante, qui va rajouter une classe d'identification d'un utilisateur remote :

root.remote=org.jasig.portal.security.provider.RemoteUserSecurityContextFactory

Contexte utilisateur

Il va ensuite falloir préciser dans le contexte utilisateur qu'il s'agit d'un remote user. Cela se fait en éditant le fichier uportal-war/src/main/resources/properties/contexts/userContext.xml .
Il suffira d'éditer ce bean :

...
<bean id="personManager" class="org.jasig.portal.security.provider.SimplePersonManager" />
...

Et de le remplacer par celui-ci :

...
<bean id="personManager" class="org.jasig.portal.security.provider.RemoteUserPersonManager" />
...

Attributs utilisateur

Il va ensuite falloir modifier deux beans existants dans le fichier uportal-war/src/main/resources/properties/contexts/personDirectoryContext.xml pour configurer les attributs utilisés : requestAttributeSourceFilter et requestAdditionalDescriptors.
Ils doivent être modifiés de la façon suivante :

...
<!--
 | Servlet filter that creates an attribute for the serverName
 +-->
<bean id="requestAttributeSourceFilter" class="org.jasig.services.persondir.support.web.RequestAttributeSourceFilter">
    <property name="additionalDescriptors" ref="requestAdditionalDescriptors" />
    <property name="usernameAttribute" value="remoteUser" />
    <property name="remoteUserAttribute" value="remoteUser" />
    <property name="serverNameAttribute" value="serverName" />
    <property name="processingPosition" value="BOTH" />
    <property name="headerAttributeMapping">
        <map>
            <!-- MODIFY THESE MAPPINGS TO EXPOSE HEADERS FROM SHIB AS USER ATTRIBUTES -->
            <entry key="cn">
                <list>
                    <value>cn</value>
                    <value>displayName</value>
                </list>
            </entry>
            <entry key="givenName" value="givenName" />
        </map>
    </property>
</bean>
 
<!--
 | Session-scoped descriptors object. One of these will exist for each user in their session. It will store the
 | attributes from the reques set by the requestAttributeSourceFilter
 +-->
<bean id="requestAdditionalDescriptors" class="org.jasig.services.persondir.support.MediatingAdditionalDescriptors">
    <property name="delegateDescriptors">
        <list>
            <bean class="org.jasig.services.persondir.support.AdditionalDescriptors" scope="globalSession">
                <aop:scoped-proxy />
            </bean>
            <bean class="org.jasig.services.persondir.support.AdditionalDescriptors" scope="request">
                <aop:scoped-proxy />
            </bean>
        </list>
    </property>
</bean>
...

Lien de connexion

Si l'authentification est réalisée par Shibboleth uniquement, alors il convient de supprimer le lien de connexion CAS du bandeau. Pour ce faire,il convient de modifier le fichier uportal-war/src/main/resources/layout/theme/universality/components.xsl et de supprimer le bloc suivant :

...
<div id="portalCASLogin" class="fl-widget-content">
 
<a id="portalCASLoginLink" class="button" href="{$EXTERNAL_LOGIN_URL}" title=
"{upMsg:getMessage('sign.in.via.cas', $USER_LANG)}">
<span><xsl:value-of select="upMsg:getMessage('sign.in', $USER_LANG)"/><!--&#160;<span
 class="via-cas"><xsl:value-of 
select="upMsg:getMessage('with.cas',$USER_LANG)"/></span>--></span>
</a>
 
 
<p>
<xsl:value-of select="upMsg:getMessage('new.user.question', $USER_LANG)"/>&#160;
<a id="portalCASLoginNewLink" href="{$CAS_NEW_USER_URL}" title="{upMsg:getMessage('create.new.portal.account', $USER_LANG)}">
<xsl:value-of select="upMsg:getMessage('new.user', $USER_LANG)"/>
</a>.
</p>
 
 
</div>
...

Pour connecter un utilisateur, il suffira de le rediriger vers le lien /uPortal/Login défini pour le mod_shib, que ce soit via un lien, un bouton, une image, etc...

Tests de fonctionnement

Ces tests vont permettre de vérifier le bon fonctionnement et le bon paramétrage de l'IdP et du SP Shibboleth avec, successivement, la récupération d'attributs LDAP par l'IdP et la transmission de ces attributs de l'IdP au SP .

IdP

Avec l'IdP est fourni un utilitaire (aacli) qui va permettre de tester la récupération des attributs définis dans les fichiers de configuration de l'IdP attribute-resolver et attribute-filter. Il se trouve dans le répertoire /bin de l'IdP, et est décliné en deux versions : aacli.bat (Windows) et aacli.sh (Unix).

Deux paramètres sont nécessaires pour lancer l'utilitaire :
--configDir qui doit pointer vers le dossier contenant les fichiers de configuration de l'IdP (/conf en général)
--principal qui est l'identifiant utilisé pour le test.

D'autres paramètres de test peuvent être définis et sont explicités avec l'utilisation du paramètre --help.

Si un utilisateur est défini par un uid etudiant1 dans l'annuaire LDAP, et que l'IdP est configuré pour remonter les attributs uid et displayName, la commande :

(Unix) 		$aacli.sh --configDir=<Path>conf --principal=etudiant1
(Windows)	aacli.bat --configDir=<Path>conf --principal=etudiant1

devrait produire une sortie semblable à cela :

<?xml version="1.0" encoding="UTF-8"?><saml2:AttributeStatement xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion">
   <saml2:Attribute FriendlyName="uid" Name="urn:oid:0.9.2342.19200300.100.1.1" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
      <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">etudiant1</saml2:AttributeValue>
   </saml2:Attribute>
   <saml2:Attribute FriendlyName="displayName" Name="urn:oid:2.16.840.1.113730.3.1.241" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
      <saml2:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">Prenom Nom</saml2:AttributeValue>
   </saml2:Attribute>
</saml2:AttributeStatement>

Cela permet de vérifier que l'IdP peut bien se connecter au serveur LDAP et remonter des attributs.

SP

Pour vérifier que le SP est bien en état de fonctionnement, depuis la machine hébergeant le serveur Apache, on peut se rendre à l'url suivante : http://localhost/Shibboleth.sso/Status . Cette page devrait afficher des informations de métadonnées sur le SP, ce qui confirme son fonctionnement.

Pour vérifier que l'IdP transmet bien les éléments qu'il récupère au SP, on va utiliser la page de test mise en place lors de la configuration d'Apache : /secure.
Étant protégée par Shibboleth, elle va requérir une authentification, et on pourra vérifier les attributs transmis lors de cette identification.

Pour cela, il suffit d'accéder à http://localhost/secure pour afficher les attributs utilisateurs shibboleth résultant de l'exécution du script printenv.pl.

 #!/usr/bin/perl
print "Content-type: text/plain\n\n";
print "Variables d'environnement positionnées par le SP shibboleth :\n\n";
foreach my $key (keys %ENV) {
    if ($key eq 'REMOTE_USER' || $key =~ /^Shib_/ || $key =~ /^[a-z]/) {
	printf "$key=$ENV{$key}\n";
    }
}

Une fois identifié, il est également possible d'accéder à la page de Session du SP qui affiche plus spécifiquement les attributs qui lui ont été transmis par l'IdP pour la session en cours, via l'URL http://localhost/Shibboleth.sso/Session .

Si ces attributs correspondent bien à ceux attendus, alors la communication entre IdP et SP est correcte.