Projet Socle ENT
Pages enfant
  • Shibboleth (esup 4)

Comparaison des versions

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

...

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

Bloc de code
...
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 :

Bloc de code
...
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 :

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

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.

...

Bloc de code
languagehtml/xml
titlesecurity.properties
...
## 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 :

...

Bloc de code
languagehtml/xml
titleuserContext.xml
...
<bean id="personManager" class="org.jasig.portal.security.provider.SimplePersonManager" />
...

Et de le remplacer par celui-ci :

Bloc de code
languagehtml/xml
titleuserContext.xml
...
<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 :

Bloc de code
languagehtml/xml
titlepersonDirectoryContext.xml
...
<!--
 | 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 :

Bloc de code
languagehtml/xml
titlecomponents.xsl
 ...
<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...

...