|
|
||
| Date de création : | 31 janvier 2004 | |
| Dernière modification : | 25 octobre 2004 | |
| Diffusion : | internet | |
Ce document décrit comment personnaliser une quick-install d'uportal pour fonctionner le plus près possible d'un environnement 'esup-portail'.
Il n'est pas destiné à un environnement de production esup-portail.
Les modifs concernent en particulier les points suivants :
Il est devenu un peu obsolète, certaines procédures ayant changées à parir des releases 2.3 d'uportal.
Il part de la quick install linux déja
documentée. Il est très facile de l'extrapoler vers la quick
install windows.
Comme cette dernière installation, les modifications proposées
ne nécessitent pas un accès root.
La doc est liée à une installation de développement de Nancy 2. L'adaptation vers un environnement différent ne devrait pas être trop compliqué.
Les objectifs sont les suivants :
Donc, le pré-requis est la quick install uportal sur linux, tel que documenté.
Un 'package' reprenant l'installation quick-install d'uPortal et ajoutant les personnalisations esup-portail est proposé sur ce site. Il est installable sur Windows et Linux.
Les chapitres sont les suivants :
On va ajouter fonctionnalité par fonctionnalité, avec validation de chaque phase. Il est possible de ne pas installer l'une ou l'autre des fonctionnalités.
Le script start.sh est modifié afin de permetre éventuellement de faire du debugging à distance (validé avec jbuilder entreprise et eclipse), et de prendre en compte le certificat de l'autorité de confiance ac-racine du CRU:
!/bin/sh JAVA_HOME=/usr/java/j2sdk1.4.2_03;export JAVA_HOME # si debug : mettre MY_DEBUG a 1, et preciser le port avec JPDA_ADDRESS MY_DEBUG=0 JPDA_ADDRESS=6665;export JPDA_ADDRESS CATALINA_HOME=/home/cri/vmathieu/Tomcat;export CATALINA_HOME CATALINA_BASE=$CATALINA_HOME;export CATALINA_BASE CATALINA_OPTS="-Djavax.net.ssl.trustStore=/home/cri/vmathieu/uPortal/ca-racine.kestore";export CATALINA_OPTS if [ "$MY_DEBUG" = "1" ]; then $CATALINA_HOME/bin/catalina.sh jpda start else $CATALINA_HOME/bin/catalina.sh start fi
La prise en compte de l'autorité de confiance du CRU est utile pour
l'authentification CAS.
Pas obligatoire, mais peut servir en cas de debug.
Dans le fichier server.xml, dans le context uportal ajouter :
<Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs" prefix="uportal.access.log." suffix=".txt"
pattern="common" resolveHosts="false"/>
Le script stop.sh est modifié pour supprimer les logs :
#!/bin/sh JAVA_HOME=/usr/java/j2sdk1.4.2_03;export JAVA_HOME CATALINA_HOME=/home/cri/vmathieu/Tomcat;export CATALINA_HOME CATALINA_BASE=$CATALINA_HOME;export CATALINA_BASE $CATALINA_HOME/bin/shutdown.sh echo "on vire les logs" /bin/rm $CATALINA_BASE/logs/*
remarque : la log d'uportal va être redirigée vers ce répertoire logs après modifications
On va maintenant rediriger les logs d'uportal vers le répertoire de
logs de tomcat.
On va voir également comment modifier le niveau des logs uportal à
des fins de debugging.
On va travailler dans le répertoire des sources pour la modification du fichier de propriété de logs, puis déployer les modifs vers l'environnement d'exploitation.
On va pratiquer de la sorte dans les paragraphes suivants ,lors des modifications de fichier de configuration.
On édite le fichier uPortal/uPortal_rel-2-2/properties/Logger.properties, et on modifie la ligne suivante :
log4j.appender.R.File=Tomcat/logs/portal.log
(remarque : il serait préférable de mettre un chemin complet : ce fichier est interprêté par le moteur tomcat, mais aussi lors de différentes commandes ant (ex : ant initportal) qui ne sont pas exécutés depuis le même emplacement).
Si on a besoin d'avoir un niveau de logs plus élevé, on intervient sur la directive
log4j.rootCategory=INFO, R
On peut mettre d'autres valeurs, comme WARN, ERROR, DEBUG, ...
Et on augmente la taille du fichier log
log4j.appender.R.MaxFileSize=50000KB
On arrête tomcat, on déploie, on relance tomcat :
On contrôle que le fichier portal.log se trouve bient dans Tomcat/logs
Conseil : en cas de problème dans l'application des modifications suivantes, ne pas hésiter à regarder le log du portal, et éventuellement ceux de tomcat (en particulier, catalina.out).
L'objectif de ce paragraphe est de modifier l'environnement quick install pour utiliser un serveur mysql au lieu du hsql fourni.
On peut facilement extrapoler cette modification vers un autre SGBD supporté
Il est nécessaire de créer préalablement la base principale qui va servir de support au portail, et un utilisateur ayant tous les droits dans cette base.
On suppose ici que la base créée s'appelle uportalE, et que l'utilisateur ayant des droits dans cette base s'appelle uportalU, son mot de passe étant azerty.
Avant la manip, stop.sh et arrêt HSQL.
remarque : pour une installation 'standalone' sous windows, on peut utiliser une distribution "easy php" pour le support de mysql.
modifier le fichier conf/serveur.xml pour que les pools de connexion jdbc/PortalDb et jdbc/PersonDb pointent vers la base créée :
ceci pour les deux pools de connexion.
ATTENTION : les directives suivantes réinitialisent la base uportal. toute donnée s'y trouvant préalablement est détruite.
Il est nécessaire au préalable de 'tricher' : faire 'croire' aux librairies uportal 'source' (non déployées) de le portail n'utilise pas les pools de connexion.
start d'uportal, et contrôle de fonctionnement
Si le compte login existe, ceci permet de changer le mot de passe ; sinon,
ca créer le compte local correspondant.
ATTENTION : comme pour le ant db, il faut que les pools de connexion uportal
soient désactivés dans l'environnement 'source'.
A partir de la version 2.2, uportal supporte l'internationalisation.
La francisation est balbutiante. Les comptes par défaut sont naturellement
en langage US.
Il faut d'abord faire comprendre à uportal que le francais existe, donc
rajouter fr_FR à l'entrée org.jasig.portal.i18n.LocaleManager.portal_locales
du fichier portal.properties.
(en fait, ça ne semble pas nécessaire ? je ne sais pas à
quoi sert cette entrée).
Un utilisateur logué dans le portail peut changer la langue par défaut
:
Preferences - Language - French. Le nom des langues supportées est francisé,
c'est plutot bon signe; le francais existe donc un tout petit peu dans uportal.
Maintenant, on veut que le compte anonyme soit francais, et que les nouveau
comptes créés aussi.
Par défaut, le compte anonyme correspond au compte interne Guest, et les nouveau utilisateurs héritent du profil du compte demo (paramétrable).
On va donc se loguer en compte demo et en compte guest pour activer la langue francaise (auparavant, il faut affecter un mot de passe au compte guest).
Voir le paragraphe 'installer la librairie cas-uportal' ; il y a un tout petit exemple de francisation d'une feuille xsl, ca peut donner des idées.
J'ai rencontré les problèmes suivants, à voir :
L'authentification utilisée lors de l'installation quick-install utilise exclusivement la base uportal (en fait, le pool de connexion PersonDb).
Nous allons apporter les modifications nécessaires pour pouvoir authentifier CAS, LDAP ou base interne.
L'authentification LDAP n'est pas prévue dans esup-portail ; elle est expliquée ici à des fins didactiques.
On intervient sur 2 fichiers : ldap.properties et security.properties
On va modifier dans l'environnement 'source', puis faire un 'ant deploy' pour réperciter les modifications vers l'environnement d'exploitation.
Ces fichiers sont donc dans uPortal/uPortal_rel-2-2/properties
ldap.host=ldap.univ-nancy2.fr ldap.port=392 ldap.baseDN=ou=People,dc=univ-nancy2,dc=fr ldap.uidAttribute=uid
doit contenir ceci :
root=org.jasig.portal.security.provider.UnionSecurityContextFactory root.ldap=org.jasig.portal.security.provider.SimpleLdapSecurityContextFactory
root.simple=org.jasig.portal.security.provider.SimpleSecurityContextFactory
#root.cas=org.jasig.portal.security.provider.YaleCasContextFactory principalToken.root=userName
credentialToken.root=password
#credentialToken.root.cas=ticket #logoutRedirect.root.cas=https://auth.univ-nancy2.fr/logout?service=http://horus2.univ-nancy2.fr:8080/uPortal authorizationProvider=org.jasig.portal.security.provider.AuthorizationServiceFactoryImpl
On remarque 3 lignes en commentaire : elles concernent l'authentification CAS, a voir au paragraphe suivant
Comme auparavant, on arrête tomcat, on déploie, on relance tomcat
On tente une authentification avec son login/password LDAP. Si OK, c'est bon.
Sinon, voir la log du portail.
Le message de login est "Welcome Unrecognized person: VotreLogin".
cela vient du fait que vous être authentifié, mais que le portail
n'a pas pu recueillir d'informations relatifs à votre login (les attributs
liés).
Vous pouvez vous en apercevoir en cliquant sur l'onglet 'développeur'
: le canal "Person Attributes" n'expose aucun attribut lié
à votre login.
Il va falloir :
On suppose, dans l'exemple, que le serveur CAS est accessible à
https://auth.univ-nancy2.fr/
On contrôle avant qu'on a bien cette ligne dans le start.sh :
CATALINA_OPTS="-Djavax.net.ssl.trustStore=/home/cri/vmathieu/uPortal/ca-racine.kestore";export CATALINA_OPTS
C'est un keystore qui contient le certificat de l'ac-racine du CRU. Il permet de valider des connexions https directes vers le serveur CAS (si celui-ci a bien un certificat délivré par le CRU, et envoie correctement la chaine de certification. A contrôler avec un navigateur W3).
Il y a de telles connexions https lors des mécanismes de récupération
de Proxy Granting Ticket et de Proxy Tickets.
uportal doit pouvoir être accessible en https, au moins depuis le serveur CAS vers l'URL de callback : c'est par une connexion sécurisée que le serveur CAS envoie le PGTiOU, qui sert à récupérer le PT.
Il doit donc disposer d'un couple clé privée / clé publique pour le serveur, et d'un certificat auto-validé ou validé par une autorité de certification.
Dans cet exemple, on dispose de certificats validés par l'ac-serveur du CRU, elle même validée par l'ac-racine du CRU.
On construit donc un keystore java qui inclu la clé privée et le certtificat de notre serveur, et les certificats des ac de la chaine de certification. Il est nommé ici horus2.keystore (voir les docs java_x509 et cas_x509)
Il faut donc modifier le fichier server.xml de tomcat :
- décommenter le bloc <Connector port="8443" ...
Ajouter avant la fin de ce bloc : keystoreFile="/Cert/horus2.keystore"
keystorePass="xxxx" />
Adapter le nom du keystore et le mot de passe.
Tests : se connecter en https à uportal, (https://horus2.univ-nancy2.fr:8443/uPortal) puis cliquer sur le cadenas (en général, en bas à droite du navigateur) ; demander le détail du certificat ; on doit voir la chaine de certification.
Remarque : dans un environnement de développement, il est probable
que l'on ne dispose pas de certificats du CRU.
Dans ce cas, il faut que le certificat soit connu du serveur CAS.
On décommente les 3 lignes précédentes en commentaire :
root.cas=org.jasig.portal.security.provider.YaleCasContextFactory principalToken.root=userName credentialToken.root.cas=ticket logoutRedirect.root.cas=https://auth.univ-nancy2.fr/logout?service=http://horus2.univ-nancy2.fr:8080/uPortal
Adapter la dernière à votre environnement ; c'est elle qui permet
un logout CAS lors du logout uportal.
On peut se référer à la documentation de cette opération pour plus de détails. La partie concernant le rendu change, pour tenir compte des spécificités de la V2.2
En fait, on intègre déja la librairie cas-client
java (au jour de la rédaction, cas-client-2.0.10.tar.gz) :
cp -pr java/src/* uPortal/uPortal_rel-2-2/source/
Ensuite, la librairie cas-uPortal : cas2-uPortal.tar.gz
C'est la recopie de 2 fichiers java, plus l'ajout d'un lien sur la page d'accueil pour authentifier CAS, et la modification du logout pour forcer un logout CAS.
<a href="https://auth.univ-nancy2.fr/index.jsp?service=http://horus2.univ-nancy2.fr:8080/uPortal/Login">CAS NetID</a>
Et pour le fun, on va franciser le message d'accueil (Welcome par défaut).
Ajouter en fin de fichier les lignes suivantes :
org.jasig.portal.security.provider.YaleCasContext.CasValidateUrl=https://auth.univ-nancy2.fr/proxyValidate org.jasig.portal.security.provider.YaleCasContext.CasProxyCallbackUrl=https://horus2.univ-nancy2.fr:8443/uPortal/CasProxyServlet org.jasig.portal.security.provider.YaleCasContext.PortalServiceUrl=http://horus2.univ-nancy2.fr:8080/uPortal/Login
Ajouter les infos suivantes . ATTENTION, l'emplacement compte : "context-param" en tête de fichier, "servlet" avec les autres "servlet", "servlet-mapping" avec les autres "servlet-mapping".
<context-param>
<param-name>edu.yale.its.tp.cas.proxyUrl</param-name>
<param-value>https://auth.univ-nancy2.fr/proxy</param-value>
</context-param> <servlet>
<servlet-name>CasProxyServlet</servlet-name>
<servlet-class>edu.yale.its.tp.cas.proxy.ProxyTicketReceptor</servlet-class>
<load-on-startup>4</load-on-startup>
</servlet> <servlet-mapping>
<servlet-name>CasProxyServlet</servlet-name>
<url-pattern>/CasProxyServlet</url-pattern>
</servlet-mapping>
./stop.sh, puis ant deploy, puis start.sh
Dans la page d'accueil, on doit voir le lien permettant d'être redirigé vers le serveur CAS (et, si le compte guest a activé la langue française, le message "Welcome Guest" est changé en "Bienvenue invite").
Se loguer dans le portail via le serveur CAS. On doir voir "Welcome vmathieu" (ou "Bienvenue vmathieu).
Ce controle n'est pas suffisant : il faut contrôler qu'uportal est capable de récupérer le PGP (Proxy Granting Ticket), et donc d'être proxy CAS.
Pour celà :
- Mettre les logs en mode DEBUG
- Se loguer dans le portail via CAS
- grep -i pgt logs/portal.log : on devrait avoir un message du style :
<cas:proxyGrantingTicket>PGTIOU-23745-N0HL...SbH7e</cas:proxyGrantingTicket>
- Si la log d'accès est activée au niveau serveur tomcat, faire
grep -i pgt logs/uportal.access.log.2004-02-02.txt (adapter le nom du fichier
log)
et on devrait avoir qq chose comme :
GET /uPortal/CasProxyServlet?pgtIou=PGTIOU-23745-N0HL...SbH7e&pgtId=PGT-44390-J4i3...mgbGO HTTP/1.1" 200 78
Si vous avez ce message, vous êtes sûr que tout est bon.
Maintenant, on va faire en sorte qu'uportal interroge LDAP pour récupérer les attributs de personne (en plus de sa base locale.
Pour celà, on va éditer le fichier uPortal/uPortal_rel-2-2/properties/PersonDirs.xml
Ce fichier permet de déclarer plusieurs sources de données qui
vont être utilisés lors du login de l'utilisateur pour enrichir
ses 'attributs uportal'.
Pour chaque source de données, on va faire un 'mapping' entre un nom
d'attribut uportal et un champ SQL ou un attribut LDAP.
Chaque source données est explorée lors du login. Les attributs
liés à un utilisateur peuvent donc être extraits simultanément
de différents source.
Les sources de type base de données peuvent provenir de pools gérés
par tomcat, ou de connexions directes à la base.
Dans le PersonDirs.xml :
il y a un bloc <PersonDirInfo> par source de données ; il contient
la déclaration de la source de données ; il contient également
un bloc <attributes> composé de n blocs <attributes> qui
font le mapping recherché.
ex :
<PersonDirs>
<PersonDirInfo> <!-- recuperations d'infos de LDAP -->
<url>ldap://ldap1.univ-nancy2.fr:392/dc=univ-nancy2,dc=fr ldap://ldap2.univ-nancy2.fr:392/dc=univ-nancy2,dc=fr</url>
<logonid></logonid>
<logonpassword></logonpassword>
<uidquery>(uid={0})</uidquery>
<usercontext></usercontext>
<attributes>
<attribute>
<name>cn</name>
<alias>cn</alias>
</attribute>
<attribute>
<name>cn</name>
<alias>displayName</alias>
</attribute>
<attribute>
<name>mail</name>
<alias>mail</alias>
</attribute>
<!-- ........ -->
</attributes>
</PersonDirInfo>
<PersonDirInfo> <!-- recuperation depuis un pool de connexion tomcat -->
<res-ref-name>PersonDb</res-ref-name>
<uidquery>SELECT FIRST_NAME||' '||LAST_NAME AS FIRST_LAST, FIRST_NAME,
LAST_NAME, EMAIL FROM UP_PERSON_DIR WHERE USER_NAME=?</uidquery>
<attributes>
<attribute>
<name>FIRST_NAME</name>
<alias>displayName</alias>
</attribute>
</attributes>
<attribute>
<name>EMAIL</name>
<alias>mail</alias>
</attribute>
<!-- ........ -->
</attributes>
</PersonDirInfo>
</PersonDirs>
pourquoi on ne voyait plus les attributs des comptes locaux après avoir passé en mysql ? Tout simplement parce que le PersonDirs.xml initial utilise une connexion directe à la base uportal au lieu de pool PersonDb :
<driver>org.hsqldb.jdbcDriver</driver>
<url>jdbc:hsqldb:hsql://localhost:8887</url>
<logonid>sa</logonid>
<logonpassword></logonpassword>
<uidquery>SELECT FIRST_NAME||' '||LAST_NAME AS FIRST_LAST, FIRST_NAME, LAST_NAME, EMAIL FROM UP_PERSON_DIR WHERE USER_NAME=?</uidquery>
Et donc, uportal tente d'accéder à hsql au lieu de mysql !
Après édition du personDirs.xml, ./stop.sh - ant deploy ./start.sh
accèder au portal avec votre login (CAS ou LDAP). Vous avez le message
"Welcome Vincent".
Cliquez sur l'onglet 'Developer', et vous verrez dans le canal 'Person Attributes'
les attributs que vous aurez déclarés.
On va maintenant créer dans uportal des groupes issus de requêtes
LDAP.
Le paramétrage global se fait à l'aide du fichier properties/groups/compositeGroupServices.xml. Grace à ce fichier, il est possible de brancher différents 'gestionnaires' de groupes.
Des docs sur le site uportal expliquent le paramétrage du gestionnaire de groupes :
En standard sont livrés dans la distribution uportal les gestionnaires suivants :
Il est possible de déclarer un ou plusieurs gestionnaires de groupes dans uportal ; ceux-ci sont déclarés dans le fichier properties/groups/compositeGroupServices.xml (un peu à la manière du security.properties, en indiquant le nom de classes java chargées de gérer ce gestionnaire de groupes, ce qui offre une grande souplesse).
Pour utiliser LDAPGroupStore, il suffit de décommenter dans le fichier compositeGroupServices.xml les lignes concernant le "LDAP group service component" :
<service>
<name>ldap</name>
<service_factory>org.jasig.portal.groups.ReferenceIndividualGroupServiceFactory</service_factory>
<entity_store_factory>org.jasig.portal.groups.ldap.LDAPEntityStoreFactory</entity_store_factory>
<group_store_factory>org.jasig.portal.groups.ldap.LDAPGroupStoreFactory</group_store_factory>
<entity_searcher_factory>org.jasig.portal.groups.ldap.LDAPEntitySearcherFactory</entity_searcher_factory <internally_managed>false</internally_managed>
<caching_enabled>false</caching_enabled>
</service>
Ce service LDAP fonctionne comme celà :
Ensuite, on va paramétrer ce service LDAP dans le fichier properties/groups/LDAPGroupStoreConfig.xml
En voici un exemple :
<LDAPGroupStore>
<config>
<url>ldap://ldap1.univ-nancy2.fr:392/dc=univ-nancy2,dc=fr ldap://ldap2.univ-nancy2.fr:392/dc=univ-nancy2,dc=fr</url> <logonid></logonid>
<logonpassword></logonpassword>
<keyfield>uid</keyfield>
<namefield>cn</namefield>
<usercontext></usercontext>
<refresh-minutes>1440</refresh-minutes>
</config>
<group name="Groupes LDAP" key="allldap"> <description>Tout les groupes LDAP</description> <group name="Pers" key="allpers"> <description>Personnel de Nancy 2</description> <group name="CRI" key="cri"> <description>Centre de REssources Informatiques</description> <entity-set> <filter string="(&(objectclass=N2CLassPersonnel)(|(N2AtrPersCompCode=CRI)(N2AtrPersCompBis=CRI)))"/ </entity-set> </group> </group> <group name="Etudiants" key="alletud"> <description>Etudiant de Nancy 2</description> <group name="PLG" key="PLG"> <description>Pole Lorrain de Gestion</description> <group name="mmiage1" key="mmiage1"> <description>IUP MIAGE 1A</description> <entity-set> <filter string="(&(objectclass=N2ClassEtudiant)(n2AtrTypePeople=APO_*)(n2atrGroupe=mmiage1))" /> </entity-set> </group> </group> </group> </group> </LDAPGroupStore>
Vous pouvez maintenant consulter le contenu de ces groupes
| Création :29 janvier 2004 - Vincent Mathieu | |
|
Modifications : |