...

...
<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 :

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

<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 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/userContextsecurity.xml .
Il suffira d'éditer ce bean properties. Au début du fichier sont placées les classes d'authentification :

...
<bean id="personManager" class="## This is the factory that supplies the concrete authentication class
root=org.jasig.portal.security.provider.SimplePersonManager" />UnionSecurityContextFactory
root.cas=org..

Et de le remplacer par celui-ci :

...
<bean id="personManager" class="jasig.portal.security.provider.cas.CasAssertionSecurityContextFactory
#root.cas=org.jasig.cas3.extensions.clearpass.integration.uportal.PasswordCachingCasAssertionSecurityContextFactory
root.simple=org.jasig.portal.security.provider.RemoteUserPersonManager" />SimpleSecurityContextFactory
...

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 :

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..
<!--
 | 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>
...

...

<?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>
/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:AttributeAttributeValue FriendlyNamexmlns:xs="displayNamehttp://www.w3.org/2001/XMLSchema" Namexmlns:xsi="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 servlet 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 le script d'informations.

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 .

...