...

<ApplicationDefaults entityID="https://<IdP>/Shibboleth.sso<entityID du SP>"
                         REMOTE_USER="uid eppn persistent-id targeted-id">

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 :

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

...

Pour vérifier que l'IdP transmet bien les éléments qu'il récupère au SP, on va utiliser la servlet 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 le script d'informations 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 .

...