...
| 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.
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 :
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
## 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 | ||||
|---|---|---|---|---|
| ||||
root.remote=org.jasig.portal.security.provider.RemoteUserSecurityContextFactory |
| Remarque |
|---|
Si l'authentification se fait par Shibboleth uniquement, il est préférable de commenter toutes les lignes de cette section, à l'exception de celle ajoutée et de la première ligne : root=org.jasig.portal.security.provider.UnionSecurityContextFactory. Si plusieurs méthodes sont utilisées, uPortal essayera les différentes méthodes jusqu'à ce qu'une valide l'authentification. |
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 :
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
<bean id="personManager" class="org.jasig.portal.security.provider.SimplePersonManager" /> |
Et de le remplacer par celui-ci :
| Bloc de code | ||||
|---|---|---|---|---|
| ||||
<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 | ||||
|---|---|---|---|---|
| ||||
<!--
| 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 | ||||
|---|---|---|---|---|
| ||||
<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)"/><!-- <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)"/> 
<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 .
...