Et les tests fonctionnels ?

Justement, ils permettent d’effectuer de manière automatique, une série de clics et de saisie clavier pour effectuer un scénario fonctionnel. L’avantage, c’est qu’ils sont lancés automatiquement à chaque build et testent l’application de manière transverse via l’interface graphique. En effet, si les tests unitaires de deux classes isolées passent bien, le rendu de l’assemblage de ces deux briques peut ne pas être celui attendu.

Mais comment ça marche ?

Selenium, of course !

Des bibliothèques existent pour commander le navigateur, comme Selenium : il suffit de programmer son scénario avec Selenium API (existe en module Firefox ici : http://seleniumhq.org/download/), et d’exporter le test dans son langage de prédilection : nous illustrerons par la suite un cas de test en Java.

Grâce à la bibliothèque Selenium, il suffit d’étendre SeleneseTestCase ou d’utiliser un objet de type Selenium. L’inconvénient de SeleneseTestCase est d’ouvrir et fermer le navigateur avant et après chaque test alors que ce n’est pas forcément utile. Il n’y a pas de distinction entre les annotations @Before et @BeforeClass.

Pour pallier à ce problème, on peut coder un test Selenium de cette manière :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
package com.excilys.monprojet.monportlet.selenium;



import static org.junit.Assert.assertTrue;



import org.junit.After;

import org.junit.AfterClass;

import org.junit.Before;

import org.junit.BeforeClass;

import org.junit.Test;



import com.thoughtworks.selenium.DefaultSelenium;

import com.thoughtworks.selenium.Selenium;



public class NavigationIT {



    private static final String TIMEOUT_PAGE = "30000";

    private static Selenium selenium;



    @BeforeClass

    public static void setUp() throws Exception {

        String url = "http://localhost:8080/liferay/";



        selenium = new DefaultSelenium("localhost", 4444, "*firefox", url);

        selenium.start();

    }



    @AfterClass

    public static void tearDown() {

        selenium.close();

        selenium.stop();

    }



    @Before

    public void beforeLogin() {

        selenium.open("");

        selenium.waitForPageToLoad(TIMEOUT_PAGE);

    }



    @After

    public void afterLogout() {

    }



    @Test

    public void testPorletAffiche() {

        assertTrue(selenium.isTextPresent("Portlet Agenda"));

    }



}

Nous venons donc de coder un test fonctionnel qui à travers le navigateur Firefox, ouvre une nouvelle page, accède à l’URL http://localhost:8080/liferay/, attend que la page soit chargée, se logge, et vérifie que le texte “Portlet Agenda” est bien présent.

Et une fois le scénario écrit, comment automatiser les tests ?

Pom Maven, Surefire, Ant, et autres douceurs…

Avec Maven, on configure un nouveau profil spécifique aux tests fonctionnels. En effet, on s’arrange pour ne pas effectuer ces tests un peu longs dans le profil par défaut du build Maven. Cela permet de gagner du temps dans le développement et de ne pas être dérangé par des fenêtres Firefox intempestives…

Dans le pom du projet, on ajoute donc le profil “integration-test” :

1
2
3
4
5
6
7
8
9
10
<profiles>

    <profile>

        <id>integration-test</id>

        <activation>

            <activeByDefault>false</activeByDefault>

        </activation>

        <build>

        </build>

    </profile>

</profiles>

Le build prend en compte cette configuration quand on lance le build Maven via la commande :

1
mvn clean install -Pintegration-test

Plugin maven-surefire

On utilise Surefire pour lancer les tests situés dans un certain package. Si ce plugin est utilisé pour exécuter les tests unitaires JUnit, rien n’empêche de l’appliquer aux tests Selenium qui seront traités de la même manière.

Entre les balises <build></build>, on ajoute :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<plugins>

    <plugin>

        <groupId>org.apache.maven.plugins</groupId>

        <artifactId>maven-surefire-plugin</artifactId>

        <version>${surefire.plugin.version}</version>

        <executions>

            <!-- Tests d'integration -->

            <execution>

                <id>surefire-integration-tests</id>

                <phase>integration-test</phase>

                <goals>

                    <goal>test</goal>

                </goals>

                <configuration>

                    <skip>false</skip>

                    <includes>

                        <include>**/selenium/**IT.java</include>

                    </includes>

                </configuration>

            </execution>

        </executions>

    </plugin>

</plugins>

On va donc, pendant la phase integration-test, lancer les tests situés dans src/test/java/…/selenium/ dont le nom de classe se termine par IT.

Plugin selenium-maven

Avant de pouvoir lancer les tests d’intégration fonctionnels, il faut démarrer Selenium RC de manière automatique, et ensuite l’arrêter. En effet, Selenium “Remote Control” agit comme un proxy HTTP pour exécuter les requêtes navigateurs.

Entre les balises <plugins></plugins>, on ajoute :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<plugin>

    <groupId>org.codehaus.mojo</groupId>

    <artifactId>selenium-maven-plugin</artifactId>

    <version>${selenium.plugin.version}</version>

    <executions>

        <!-- Demarrage du serveur SeleniumRC -->

        <execution>

            <id>start</id>

            <phase>pre-integration-test</phase>

            <goals>

                <goal>start-server</goal>

            </goals>

            <configuration>

                <background>true</background>

            </configuration>

        </execution>

        <!-- Arret du serveur SeleniumRC -->

        <execution>

            <id>stop</id>

            <phase>post-integration-test</phase>

            <goals>

                <goal>stop-server</goal>

            </goals>

        </execution>

    </executions>

</plugin>

Plugin maven-antrun

Pour effectuer les tests fonctionnels, on a souvent besoin de déployer ses applications web au sein d’un conteneur de servlets de type Apache Tomcat, dont on doit pouvoir gérer le démarrage et l’extinction. C’est le cas pour une application se basant sur le portail Liferay, pour laquelle il faut aussi gérer le redéploiement de tous les plugins développés.

Pour cela, on crée un script de tâches Ant. Le gros avantage est de maîtriser l’ordre des commandes exécutées, alors que ce n’est pas forcément le cas lorsqu’on utilise des plugins dédiés différents dans une même phase.

Voici un exemple d’utilisation des tâches Ant dans un script pour Tomcat, qui démarre le serveur, attend le déploiement de la webapp Liferay, déploie une autre webapp qui est en fait un plugin Liferay, et arrête finalement le serveur. En phase de post-integration-test, on effectue les tâches contraires :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
<properties>

    <antrun.plugin.version>1.7</antrun.plugin.version>

    <monprojet.monportlet.it.tomcat.dir>/opt/tomcat-liferay</monprojet.monportlet.it.tomcat.dir>

    <monprojet.monportlet.it.liferay.auto.deploy.dir>/opt/tomcat-liferay/liferay-deploy</monprojet.monportlet.it.liferay.auto.deploy.dir>

    <monprojet.monportlet.it.liferay.version>6.0.6</monprojet.monportlet.it.liferay.version>

    <monprojet.monportlet.it.url.liferay>http://localhost:8080/liferay</monprojet.monportlet.it.url.liferay>

</properties>



<plugin>

    <groupId>org.apache.maven.plugins</groupId>

    <artifactId>maven-antrun-plugin</artifactId>

    <version>${antrun.plugin.version}</version>

    <executions>

        <!-- Demarrage de Tomcat, deploiement du portail Liferay, deploiement des portlets -->

        <execution>

            <id>start-liferay</id>

            <phase>pre-integration-test</phase>

            <configuration>

                <target>

                    <echo>Starting Tomcat and Liferay server...</echo>

                    <echo>Tomcat directory : ${monprojet.monportlet.it.tomcat.dir}</echo>

                    <echo>Liferay auto-deploy directory : ${monprojet.monportlet.it.liferay.auto.deploy.dir}</echo>

                    <echo>Liferay version : ${monprojet.monportlet.it.liferay.version}</echo>

                    <exec dir="${monprojet.monportlet.it.tomcat.dir}/bin" executable="${monprojet.monportlet.it.tomcat.dir}/bin/startup.sh"

                        failonerror="true" />

                    <echo>Start signal send</echo>

                    <echo>Waiting for Liferay portal to be deployed...</echo>

                    <waitfor maxwait="5" maxwaitunit="minute" checkevery="1000">

                        <http url="${monprojet.monportlet.it.url.liferay}/" />

                    </waitfor>

                    <echo>Liferay deployed !</echo>

                    <echo>Copying ${artifactId}-${version}.war into Liferay auto-deploy directory...</echo>

                    <copy file="${basedir}/target/${artifactId}-${version}.war" tofile="${monprojet.monportlet.it.liferay.auto.deploy.dir}/${artifactId}.war" />

                    <echo>${artifactId}.war copied !</echo>

                    <echo>Waiting for ${artifactId} to be deployed...</echo>

                    <waitfor maxwait="5" maxwaitunit="minute" checkevery="5000">

                        <http url="${monprojet.monportlet.it.url}/${artifactId}/" />

                    </waitfor>

                    <echo>Portlet deployed !</echo>

                </target>

            </configuration>

            <goals>

                <goal>run</goal>

            </goals>

        </execution>

        <!-- Arret de Tomcat -->

        <execution>

            <id>stop-liferay</id>

            <phase>post-integration-test</phase>

            <configuration>

                <target>

                    <echo>Shutting down Tomcat server...</echo>

                    <exec dir="${monprojet.monportlet.it.tomcat.dir}/bin" executable="${monprojet.monportlet.it.tomcat.dir}/bin/shutdown.sh"

                        failonerror="true" />

                    <echo>Stop signal send</echo>

                    <echo>Waiting 15 seconds for Tomcat to stop...</echo>

                    <waitfor maxwait="15" maxwaitunit="second" checkevery="15000">

                        <available file="inexistant.log" />

                    </waitfor>

                    <echo>Undeploying portlet ${artifactId}...</echo>

                    <delete includeemptydirs="true" verbose="false" failonerror="true">

                        <fileset dir="${monprojet.monportlet.it.tomcat.dir}/webapps/" includes="${artifactId}/**" />

                    </delete>

                    <echo>Portlet undeployed !</echo>

                </target>

            </configuration>

            <goals>

                <goal>run</goal>

            </goals>

        </execution>

    </executions>

</plugin>

Et si je souhaite lancer mes tests fonctionnels en local et/ou sur la machine d’intégration ?

Profil Maven

Il suffit de paramétrer deux configurations différentes, et de rendre le projet indépendant de ces paramètres qui seront eux propres à chaque machine.

Pour cela, on configure le fichier settings.xml (dans C:\Users\Nom\.m2\, /home/user/.m2 ou /opt/maven/conf) chargé avant chaque build Maven. Après avoir repéré le profil par défaut, on ajoute nos propriétés : elles se nomment convenablement pour ne pas mélanger les configurations entre projets.

On doit obtenir quelque chose du type :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
<settings>

    <mirrors>

        ...

    </mirrors>

    <profiles>

        <profile>

            <id>BLR</id>

            <activation>

                <activeByDefault>true</activeByDefault>

            </activation>

            <properties>

                <monprojet.monportlet.it.propriete1>valeur1</monprojet.monportlet.it.propriete1>

                <monprojet.monportlet.it.propriete2>valeur2</monprojet.monportlet.it.propriete2>

            </properties>

            <repositories>

                ...

            </repositories>

            <pluginRepositories>

                ...

            </pluginRepositories>

        </profile>

    </profiles>

    <servers>

        ...

    </servers>

</settings>

Dans notre cas on déplace le bloc des propriétés définissant l’environnement Liferay du pom vers settings.xml :

1
2
3
4
5
6
<properties>

    <monprojet.monportlet.it.tomcat.dir>/opt/tomcat-liferay</monprojet.monportlet.it.tomcat.dir>

    <monprojet.monportlet.it.liferay.auto.deploy.dir>/opt/tomcat-liferay/liferay-deploy</monprojet.monportlet.it.liferay.auto.deploy.dir>

    <monprojet.monportlet.it.liferay.version>6.0.6</monprojet.monportlet.it.liferay.version>

    <monprojet.monportlet.it.url.liferay>http://localhost:8080/liferay</monprojet.monportlet.it.url.liferay>

</properties>

Dans le pom, on peut alors faire appel aux variables qui sont disponibles pour tous les projets en utilisant la syntaxe :

1
${monprojet.monportlet.it.tomcat.dir}

Il reste l’URL en dur dans le test Selenium !

Filters et properties

Parfois, on a également besoin d’utiliser une propriété de settings.xml dans une classe de test Selenium : pour définir l’adresse où s’effectuent les tests Selenium par exemple :

1
2
selenium = new DefaultSelenium("localhost", 4444, "*firefox", url);

selenium.start();

Ici on veut que “url” prenne la valeur de la propriété qui est définie dans settings.xml et qui est prise en compte lorsque le pom du projet est parsé.

Pour cela, on crée un fichier it.properties dans src/test/resources, qui contient par exemple :

1
projet-url=${monprojet.monportlet.it.url}

(monprojet.monportlet.it.url est une propriété définie dans settings.xml)

On définit ensuite un filtre dans pom.xml, qui permet d’assigner les variables dans ce fichier lors des phases de tests. Entre les balises <build></build> du profil “integration-test”, on ajoute :

1
2
3
4
5
6
<testResources>

    <testResource>

        <directory>src/test/resources</directory>

        <filtering>true</filtering>

    </testResource>

</testResources>

Dans la classe de test, on peut alors écrire :

1
2
3
4
5
6
Properties props = new Properties();

props.load(ClassLoader.getSystemResource("it.properties").openStream());

String url = props.getProperty("projet-url") + "/";



selenium = new DefaultSelenium("localhost", 4444, "*firefox", url);

selenium.start();

Tout ça pour rien, ma machine d’intégration ne dispose pas d’environnement graphique…

Xvfb et jargon d’admin

Que nenni ! Il est possible de configuer un serveur xvfb pour rediriger la sortie graphique et effectuer vos tests dans un navigateur “invisible”.

Ce sera une étape obligatoire si, en lançant le build Maven avec le profil d’intégration, vous obtenez l’erreur frustrante :

java.lang.RuntimeException: Timed out waiting for profile to be created!
Failed to start new browser session: Error while launching browser on session null

Cette erreur s’accompagne d’un warning en jaune dans la console de Jenkins :

Waiting for Selenium Server...
[WARNING] OS appears to be Unix and no DISPLAY environment variable has been detected. Browser maybe unable to function correctly. Consider using the selenium:xvfb goal to enable headless operation.

Cela signifie que la machine sur laquelle vous tentez de lancer les tests fonctionnels ne dispose pas d’environnement graphique. On ne peut donc pas lancer la commande “firefox” pour ouvrir un navigateur.

Il faut demander à un administrateur d’effectuer les modifications suivantes sur la machine :

• installer le package xvfb (un X11 server)
• installer le package iceweasel (firefox pour une Debian)
• configurer le display pour pouvoir exécuter des applications graphiques comme firefox : export DISPLAY=:99 (ou autre valeur), dans le contexte utilisé au lancement de Jenkins par exemple.
• tester en lancant la commande Xvfb (il choisit le DISPLAY automatiquement), et lancer firefox en ligne de commande. Cela doit être fait avec le même utilisateur que celui qui lance Jenkins.

 
 
C’est fini ! Lancez autant de build maven en profil “integration-test” que vous souhaitez pour vous féliciter

Parce que tout a un début…

Et en l’occurrence, le début est ici une besoin fonctionnel. Vous me direz tous que c’est normal, mais on a parfois tendance à oublier que la solution technique n’existe que pour répondre à un besoin fonctionnel.
Dans notre cas, nous avions besoin de mettre en place une plateforme permettant à des éléments d’un système informatique (que nous appellerons par la suite “consommateurs”) d’appeler des services, traitements ou ressources distantes (que nous appellerons systèmes externes).
Cette plateforme doit présenter un nombre limité de points d’entrées (d’interfaces) à ses consommateurs. Chacun de ces points d’entrées doit faire correspondre une requête du consommateur à un appel de processus métier. Ces processus peuvent alors orchestrer des appels de services distants puis traiter et agréger les données retournées par ces appels. Les processus et services doivent être faciles à ajouter dans la plateforme et doivent avoir un couplage faible avec leurs interfaces. De plus, les systèmes externes sollicités par la plateforme exposent des services et interfaces qui leurs sont propres et qui ne doivent pas impacter le format des requêtes des consommateurs.

Le tout, c’est d’avoir un plan

Tenant compte de tous les éléments énoncés ci-dessus, j’ai modélisé (dans un premier temps) notre plateforme de la façon suivante:



Jusque là, rien de transcendant me direz-vous. J’y ai représenté différents cas pouvant se produire :

• Nous avons une boite noire qui reçoit une requête de la part d’un consommateur X et appelle la “source de données” A.
• La requête du consommateur Y donne lieu à des appels aux sources B et C. La plateforme héberge un processus qui orchestre les deux appels.
• La requête du consommateur X ne déclenche aucun appel de service (on pourrait imaginer que les services correspondants n’ont pas été écrits).

Par la suite, nous allons préciser peu à peu ce modèle pour faire apparaitre les différentes briques de notre plateforme et leurs responsabilités. Les fonctions à implémenter sont les suivantes :

Distribuer les appels de services

Une requête provenant d’un consommateur doit déclencher le processus métier adéquat. C’est pour cela que la première étape du traitement de la requête sera son analyse par un annuaire de services.

Traiter les processus métiers

Une fois le bon processus identifié, celui-ci est appelé. Son rôle est de contacter les différents services nécessaires à son fonctionnement, organiser leurs appels, rassembler et agréger les résultats pour les retourner au consommateur.

Traduire les paramètres

Les systèmes externes auxquels les processus métiers font appel exposent leurs propres services et APIs. Les paramètres transmis dans la requête d’un consommateur ne doivent en aucun cas être contraints par ces interfaces. C’est pour cela qu’un composant appelé “connecteur” propre à chaque service externe aura la responsabilité de transcrire les paramètres dans un format attendu par le service. Les classes de ces paramètres (transmis à la plateforme) seront définies dans l’API de la plateforme.

Contacter les services

Les paramètres transcrits et intégrés dans la requête du service (sous forme d’objets JAXB, chaîne de caractères, etc…), le connecteur a la charge d’établir la connexion vers le système distant et d’en appeler le service ciblé.

Traduire les réponses

Comme pour les paramètres, nous allons devoir traiter les réponses des appels de services en les transcrivant dans des objets transverses. La transcription aura lieu dans le connecteur associé au service. Les classes d’objets transverses seront définies dans l’API de notre plateforme.

Nous avons maintenant un découpage plus précis de notre plateforme qui la fait ressembler à ceci :

J’aime quand un plan se déroule sans accroc.

Maintenant que nous avons fait apparaître les différents composants de notre plateforme, nous devons choisir les solutions techniques qui vont intervenir dans leur réalisation. Différentes problématiques sont apparues :

L’accès à la plateforme

La plateforme doit être accessible d’une machine distante et la solution la plus évidente est de lui faire exposer des web services. Dans notre cas, j’ai eu une préférence pour des services RESTful. Cette solution nous permettra de simplifier la détection du processus à appeler en tenant compte de la méthode HTTP comme premier filtrage de la requête. De plus, l’entête HTTP peut nous permettre de transmettre des meta-données nécessaires à la désérialisation des objets paramètres transmis (par exemple). Pour cela, nous avons choisi d’utiliser la librairie Jersey (implémentation de référence de la JSR 311).
Parmi les formats de retour disponibles, nous avons retenu le JSON pour sa concision et sa légèreté. En effet, certains services devront retourner des quantités de données conséquentes qu’il est inutile d’alourdir avec des balises XML.

Instanciation, initialisation et découplage

Le découplage est ici essentiel puisque les composants tels que les connecteurs sont censés pouvoir être interchangés. Imaginons un processus de recherche de contenu qui interroge une GED via un connecteur conçu à cet effet. Si pour une raison quelconque on décidait de changer de GED, il faudrait ne réécrire que le composant connecteur.

La plupart des objets de notre plateforme ne devront être instanciés qu’une seule fois. Je pense en particulier aux clients Jersey définis dans les couches DAO de certains connecteurs et dont l’instanciation coûte cher.

Vous vous en doutez, la solution à ces deux problèmes est Spring Framework qui nous permet de contrôler l’instanciation de nos classes et d’assurer le découplage de nos composants. Entre autres bienfaits, le découplage par Spring nous permettra aussi de faciliter la mise en place de tests unitaires (en pratiquant la programmation par interface et pourquoi pas le TDD). Nous verrons par la suite que Spring nous permettra de résoudre d’autre problèmes plus spécifiques.

Implémenter l’annuaire de services

Nous avons besoin d’une implémentation souple permettant l’ajout (fréquent) de processus métiers supplémentaires identifiés par des “clés”. Ces clés nous permettront de faire correspondre une requête de l’un de nos consommateurs à un processus métier à exécuter.

La solution d’un bourrinisme achevé consisterait en un immonde gigantesque switch. Cette solution nous ferait modifier le code java et rajouter inutilement de la complexité cyclomatique à chaque ajout de nouveau processus métier dans notre plateforme.
M’inspirant de cet article, j’ai eu l’idée de définir mes processus métiers dans Spring (jusque là c’était prévu) et de les regrouper dans une map instanciée et gérée par ce même Spring. Ainsi, en une poignée de lignes de codes, je récupère et exécute le processus correspondant à ma requête et ces lignes ne changeront jamais pourvu que les interfaces de mes processus soient bien pensées avec des paramètres génériques (merci java 5.0 ^_^°). Voici à quoi ressemble la configuration de tout ceci dans l’applicationContext.xml:

Ainsi, l’implémentation du point d’entrée (avec Jersey) avec son annuaire de service est écrite de la façon suivante :

Une implémentation possible de processus métier pourrait avoir la forme suivante :

Construction d’un connecteur

Compte tenu du rôle joué par un connecteur, sa structure sera presque toujours articulée en 3 parties :

• Un interpréteur de critères qui transcrit les entrées du service en un format que pourra traiter le service distant.
• Un DAO qui gère la connexion au service et l’envoi de la requête.
• Un constructeur de réponses qui initialise une structure d’objets à partir de la réponse du service appelé.

Regardons par exemple le fichier applicationContext-customerConnector.xml:

Avec pour implémentation du bean customerConnector :

La transcription des paramètres et des réponses

Là encore la transcription des POJOs de l’API de la plateforme en POJOs de l’API d’un service externe peut être faite de façon peu subtile :

Cette solution serait à la fois fastidieuse à écrire et à maintenir. C’est pour cela que nous préférons utiliser Dozer qui a le bon goût de s’intégrer simplement dans la configuration Spring de notre connecteur:

Ce qui nous donne l’implémentation suivante :

En conclusion

• Tissage d’aspects à la compilation (par exemple pour générer des logs de statistiques).
• Intégration de frameworks, ORM et webservices.

Ceci conclut cet article. Vous voilà maintenant prêts à monter votre propre ESB maison.

Tous les cris, les S O S…

Nous voulons envoyer une demande d’authentification, en voici un exemple :

1
2
3
4
5
6
7
8
9
<samlp:AuthnRequest

                xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

                xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"

                ID="sk3k82Vt5uJamRNo1DgtgoKikrLH"

                Version="2.0"

                IssueInstant="2011-07-07T20:46:09Z"

                IsPassive="true">

        <saml:Issuer>http://blog.excilys.com</saml:Issuer>

</samlp:AuthnRequest>

Notre cas est simple, si nous excluons  le formalisme (notamment les déclarations d’espace de noms), nous n’envoyons que quatre informations :

• ID, qui permet d’identifier le message
• IssueInstant, la date de génération du message
• IsPassive, optionnel, permet de demander que le fournisseur d’identité réponde sans interagir avec l’utilisateur
• Issuer, qui permet d’identifier l’expéditeur du message

Et là ? Révélations ! IsPassive résout notre problème (mais si, vous vous souvenez…), lorsqu’un utilisateur arrivera sur le portail, nous ferons systématiquement la demande d’authentification. Pour savoir si l’utilisateur tente de se connecter, il nous suffira de tester si l’url contient le fameux « /portal/login », dans ce cas, il ne faut pas envoyer IsPassive à true, ainsi le fournisseur d’identité affichera sa page de connexion. Cependant, il ne faut pas oublier de placer un indicateur en session pour éviter que les deux serveurs ne se mettent à jouer au ping pong (En effet, si l’utilisateur n’est pas déjà connecté sur l’IdP, celui-ci renverra une réponse négative (pas de cookie) sans proposer de page de connexion (à cause du isPassive) , et le SP renverra une demande…). Pour générer le message, nous allons profiter de l’API XML intégrée dans Liferay (en fait, c’est une encapsulation de dom4j) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
        public static String generateAuthnRequest(

                        HttpServletRequest request, String loginUrl,

                        String samlEntityId, String relayState, String signAlg,

                        Boolean isPassive)

                throws Exception {



                String messageID = generateMessageID();



                // on stocke l'id pour tester la correspondance de la réponse



                request.getSession().setAttribute(

                        SAMLConstants.MESSAGE_ID, messageID);



                Document document = SAXReaderUtil.createDocument();



                Namespace samlp = SAXReaderUtil.createNamespace(

                        SAMLConstants.SAMLP, SAMLConstants.PROTOCOL_NAMESPACE);

                Namespace saml = SAXReaderUtil.createNamespace(

                        SAMLConstants.SAML, SAMLConstants.ASSERTION_NAMESPACE);



                Element authnRequest = document.addElement(

                        SAXReaderUtil.createQName(

                        SAMLConstants.AUTHN_REQUEST, samlp));



                authnRequest.add(samlp);

                authnRequest.add(saml);



                authnRequest.addAttribute(SAMLConstants.ID, messageID);

                authnRequest.addAttribute(

                        SAMLConstants.VERSION, SAMLConstants.VERSION_2_0);

                authnRequest.addAttribute(

                        SAMLConstants.ISSUE_INSTANT, formatDate(new Date()));

                authnRequest.addAttribute(SAMLConstants.DESTINATION, loginUrl);



                if (isPassive != null) {

                        authnRequest.addAttribute(

                                SAMLConstants.IS_PASSIVE, isPassive.toString());

                }



                Element issuer = authnRequest.addElement(

                        SAXReaderUtil.createQName(SAMLConstants.ISSUER, saml));

                issuer.setText(samlEntityId);



                String xmlString = document.asXML();

                if (_log.isDebugEnabled()) {

                        _log.debug("send : " + xmlString);

                }



                return getHTTPRedirectBindingUrl(

                        loginUrl, true, xmlString, relayState, signAlg);

        }



        public static String generateMessageID() {

                // l'id doit être unique, dans le cas d'une technique

                // aléatoire, le standard recommande une longueur de plus de

                // 160 bit (moins de 2^-160 chances de collision)

                // l'encodage en base 64 rallonge d'1/3, en octets pleins, la longueur supérieure la plus

                // approchante est 21 (21*8=168 > 160), on aura donc en sortie un id sur 28 caractères.

                byte[] randomBytes = new byte[21];

                _random.nextBytes(randomBytes);

                return Base64.encode(randomBytes);

        }



        public static String formatDate(Date date) {

                return _getDateFormat().format(date);

        }



        private static DateFormat _getDateFormat() {

                return new SimpleDateFormat(_DATE_PATTERN);

        }



        private static final String _DATE_PATTERN =

                "yyyy-MM-dd'T'HH:mm:ss'Z'";



        private static Log _log = LogFactoryUtil.getLog(SAMLUtil.class);



        private static Random _random = new Random();

Une boite aux lettres

Si nous reprenons notre descriptif de l’échange (ça vous avait presque manqué, non ?) :

Nous avons envoyé la <AuthnRequest>, le fournisseur d’identité va s’occuper de l’étape 3) d’identification de l’utilisateur, puis ensuite à l’étape 4), il va nous renvoyer une <Response>, celle-ci pouvant comporter de nombreuses informations sur l’utilisateur. Pour pouvoir recevoir cette réponse, nous allons mettre en place un endpoint de type assertion consumer service supportant le HTTP Post Binding (étant donné que le standard spécifie que l’on ne doit pas utiliser le HTTP Redirect Binding), autrement dit une url qui va pouvoir recevoir un paramètre Response, celui-ci étant encodé en base64 (et non, pas de DEFLATE dans ce binding). Pour cela, il faut indiquer à Liferay de reconnaitre l’url en ajoutant celle-ci à la propriété virtual.hosts.ignore.paths (situé dans portal.properties) pour éviter une redirection qui nous ferait perdre les paramètres du post (lorsque Liferay ne trouve pas de page associée à l’adresse par son mécanisme de « friendly URL », il redirige vers la page par défaut).

A ce moment, l’utilisateur n’étant pas encore authentifié par Liferay, le système d’AutoLogin va se déclencher, ce qui va nous permettre de simplement tester la présence du paramètre Response au niveau de notre SAMLAutoLogin :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public static boolean isAuthenticated(

                HttpServletRequest request, String loginUrl,

                String samlEntityId, String samlIdentityProviderId,

                String signAlg, HttpServletResponse response)

        throws Exception {



        String samlResponseParameter =

                request.getParameter(SAMLConstants.SAML_RESPONSE);

        if (samlResponseParameter != null) {

                String samlResponse = getSamlFromHTTPPostBindingParameter(

                        samlResponseParameter);



                // TODO lecture de la réponse

        }

        else {

                sendAuthnRequest(

                        request, response, samlEntityId, loginUrl, signAlg);

        }



        return false;

}

C’est fini pour aujourd’hui

Nous sommes désormais capable d’envoyer une demande d’authentification, et nous avons mis en place un endpoint pour recevoir la réponse, dans le prochain article nous analyserons la réponse afin de connecter l’utilisateur à Liferay (ou pas).

A bientôt pour de nouvelles aventures sur le blog Excilys…

Nate Cavanaugh et Liferay

Nate Cavanaugh a commencé sa carrière professionnelle en tant que designer graphique. Il est à l’origine du développement de nombreux sites internet mais a aussi travaillé à la construction de son propre CMS (Content Management System). Sa rencontre avec Michael Young, directeur technique de Liferay, lui a permis d’intégrer le projet Liferay. Ses premiers pas sur le projet ont consisté à repenser l’architecture du système mis en place pour les thèmes.

De JQuery à AlloyUI

Liferay est le premier portail à avoir proposé le “drag and drop” pour ses portlets. Dans la version 4.3, l’implémentation de cette fonctionnalité a été repensée pour utiliser JQuery. Suite à cela, JQuery est devenu le framework standard de l’interface utilisateur dans la version 5.7.

Mais la version 6 de Liferay a apporté un énorme changement : l’interface utilisateur n’est plus gérée par JQuery mais par AlloyUI ! Pourquoi ce choix ? Parce que développeurs et clients étaient trop souvent confrontés à des problèmes avec JQuery. En effet, l’intégration de JQuery à Liferay est gérée par des plugins. A chaque mise à jour de JQuery les développeurs devaient résoudre des bugs avec les plugins mais devaient aussi pouvoir répondre des bugs rencontrés par les utilisateurs de Liferay. Pour pouvoir sécuriser les clients utilisant la version entreprise, mais aussi pour faciliter le développement, il était nécessaire d’utiliser un framework sur lequel ils auraient plus de contrôle. Toutes ces constatations ont mené à l’abandon de JQuery.

Il a fallu alors se pencher sur l’adoption d’un autre framework. Les membres de Liferay voulaient un framework plus flexible et plus fiable que JQuery pour l’interface utilisateur. Ils ont donc fait le tour des frameworks javascript disponibles sur le marché, et deux d’entre eux ont spécifiquement retenu leur attention : Dojo et YUI (de Yahoo). Les tests en interne de Dojo n’étant pas concluants, YUI a été retenu semblant plus facile d’utilisation et mieux adapté à leur besoin.

Si YUI a été retenu, un dernier choix a dû être fait : quelle version utiliser ? En effet, à l’heure où ce problème s’est posé, deux versions étaient disponibles : la 2, stable et utilisée en entreprise, et la 3 pas encore complètement publiée et jamais utilisée encore en entreprise. Malgré les risques que comportait le choix de la version 3, c’est bien cette dernière que Liferay a choisi d’utiliser, faisant le pari de l’innovation et se disant que si nécessaire, ils développeraient leurs propres plugins. Mais cette nouvelle version ne présentant pas assez de fonctionnalités pour les développeurs, ces derniers ont décidé de construire leur propre framework au dessus de YUI : AlloyUI.

Ainsi est né AlloyUI, ne laissant aujourd’hui plus aucune place à JQuery dans Liferay. Les équipes de Liferay ont travaillé main dans la main avec les équipes de Yahoo pour intégrer ce nouveau framework basé sur YUI 3 à Liferay, faisant d’eux la première entreprise à utiliser la version 3 d’YUI.

Prendre en main AlloyUI

Nate Cavanaugh recommande aux débutants d’aller voir la librairie YUI (http://yuilibrary.com/yui/docs/examples/). En changeant les Y par de A dans les exemples, il y a tout ce qu’il faut à cette adresse pour débuter avec AlloyUI. Cependant AlloyUI a aussi ses propres spécificités, documentées bien sûr (http://alloy.liferay.com/deploy/api/index.html).

On retrouve notamment dans ces spécificités les fonctionnalités que Liferay aimait dans JQuery et qu’ils n’ont pas retrouvées dans YUI. Le module AutoComplete en fait partie par exemple, bien qu’il ait été ajouté à YUI postérieurement.

L’avantage principal avec AlloyUI et YUI, est l’utilisation d’un objet central appelé AUI avec AlloyUI et YUI avec YUI. Cette objet retourne une nouvelle instance d’YUI à chaque fois qu’il est appelé permettant notamment l’utilisation du module AutoComplete d’AlloyUI et de celui de YUI dans une sandbox sans créer de conflit particulier. Cet exemple n’aurait pas été aussi facile avec JQuery car il utilise le même objet, il aurait alors été conflictuel d’utiliser deux modules d’AutoComplete différents dans une même sandbox. Ce mécanisme de retourner une nouvelle instance est d’autant plus pratique que les portails sont des environnements dans lesquels beaucoup d’applications peuvent tourner, il est important de minimiser les conflits entre ces dernières.

Une difficulté lorsque l’on commence avec AlloyUI (et que l’on ne connait pas bien les modules disponibles) est de choisir le module adapté à son application. Pour pouvoir faciliter ce choix et répondre un maximum aux besoins simples des applications, Liferay a un créé module “AUI” qui regroupe la plupart des fonctionnalités (node, event, creation de composant). Faire appel à ce module vous offrira donc tout ce dont vous avez besoin. Si vous souhaitez répondre à un besoin bien particulier, il vous faudra alors vous lancer dans la recherche du module adapté.

Liferay 6.1 propose aussi l’utilisation de taglib pour n’importe quel widget. Mais il est parfois pénible d’utiliser les taglibs car cela impose la création d’un fichier XML, d’une JSP et d’une classe Java à faire fonctionner ensemble. C’est pourquoi Liferay a voulu proposer un “TaglibBuilder”. Ce dernier prend un fichier XML, il faut lui spécifier l’attribut et le namespace voulu et le TaglibBuilder s’occupera de la génération de la JSP et de la classe Java. Si toutefois vous devez rajouter un attribut plus tard, il vous suffira de l’ajouter au fichier XML, de relancer le TaglibBuilder et ce dernier fera les mises à jour dans les JSP et les classes. Cet outil construit l’implémentation de base d’une taglib en se basant sur la documentation du système YUI. Ainsi, plus les composants seront documentés (Javadoc), plus il sera facile d’en générer les taglibs.

Les améliorations à venir

L’équipe en charge de l’interface utilisateur prévoit d’améliorer la communication en général, c’est-à-dire aussi la documentation. Nate Cavanaugh rappelle que le projet est Open Source donc que personne ne doit hésiter à partager son expérience, ses difficultés, ajouter de la documentation, poser des questions… Une page github du projet est également disponible.

L’équipe a aussi le projet de mettre à disposition des exemples voués à montrer la différence entre JQuery, YUI et AlloyUI en proposant des fonctionnalités implémentées avec ces trois outils. Ainsi, l’utilisateur pourra comparer ces trois technologies et peut-être être aidé dans sa migration de l’un à l’autre.

Conclusion

Cette interview de Nate Cavanaugh permet de mieux comprendre les choix des technologies faits pour l’interface utilisateur. AlloyUI a été créé pour répondre au besoin de faciliter le travail des développeurs mais aussi de sécuriser les clients de Liferay. Il semble être l’outil le plus adapté pour proposer beaucoup de fonctionnalités au niveau de l’interface et faciliter la gestion d’applications multiples dans une même page. Des efforts sont faits pour proposer plus de documentation, cependant le projet étant Open Source, tout le monde est invité à participer s’il le souhaite. Pour écouter l’interview (en Anglais), suivez ce lien : http://feeds.feedburner.com/RadioLiferay. Vous pourrez vous inscrire ou bien écouter l’article directement en cliquant sur Play now sous l’article concerné : RL003 Nate Cavanaugh – Radio Liferay Episode 3.

Qu’est-ce que la Droidcon ?

Business Design Center de nuit

La Droidcon, c’est une conférence autour de la plateforme mobile de Google, elle a une renommée européenne et est organisée dans 4 grandes villes chaque année : Amsterdam, Berlin, Bucarest et Londres. Les 6 et 7 octobre 2011, ce sont près de 600 personnes qui se sont réunies lors de la Droidcon au Business Design Center, à Islington, au coeur de Londres.

Le premier jour s’est organisé à la façon d’un barcamp. Lors de la keynote d’ouverture, toutes les personnes qui souhaitaient aborder des sujets particuliers ont proposé leurs idées. C’est ainsi qu’une trentaine d’ateliers ont été créés autour de sujets tant pour les développeurs –  comme la performance et la sécurité – que pour les non développeurs avec des sujets autour de la monétisation des applications Android par exemple.

Les présentations de la seconde journée étaient quant à elles déjà prévues, on a aussi retrouvé divers sujets autour du développement, du business, de l’entreprise etc.

Les organisateurs de cet événement étaient Skills Matters, société londonienne spécialisée dans la formation informatique, et Wireless Industry Partner connector (WIP), société canadienne spécialisée dans la mise en relation d’entreprises dans le domaine mobile.

Les exposants

En parallèle de ces ateliers et conférences, divers exposants sont venus présenter leurs produits ou services. Voici une liste non exhaustive des exposants présents lors de cette conférence et les raisons de leur présence.

Les constructeurs

Stand HTC Dev

La société taïwanaise HTC est venue pour présenter plusieurs nouveautés :

• Un nouveau smartphone, le Sensation XL équipé de la technologie beats by dre qui offre une qualité sonore supérieure ;
• Une nouvelle tablette sous honeycomb : la Jetstream avec son stylo. HTC en a profité pour nous présenter son API nommée Pen permettant d’utiliser ce stylo sur la tablette afin de transformer la tablette en véritable papier électronique.

La société japonaise Sony Ericsson était également présente pour nous présenter son dernier smartphone le Xperia Play, qui est un mélange de console de jeu et de smartphone.

Enfin, un dernier constructeur était présent, et, bien que pouvant surprendre, il s’agissait de RIM. En effet, la société canadienne est venu courtiser les développeurs Android car leur tablette Playbook embarquera une nouvelle technologie nommée Android player. Ce player permettra aux applications Android de fonctionner sur la tablette Blackberry.

Les solutions à destination des professionnels

L’entreprise Cisco était présente afin de montrer sa tablette Cius à destination des professionnels. Celle-ci dispose d’un OS basé sur Android et est vendue avec les services de communication de Cisco pré installés (Webex par exemple). A destination des professionels, elle dispose d’une connectivité plus importante que les tablettes grand public, on notera particulièrement le support de la 4G et la connectivité filaire.

Autre technologie représentée, Mobile Infrastructure by Sybase qui permet de réaliser de la haute disponibilité pour les données d’applications mobiles au sein d’une entreprise.

Autres stands

Photo d'autres stands

Un des grands thèmes de la Droidcon était la monétisation des applications Android : comment gagner de l’argent grâce à son application ? Plusieurs plateformes publicitaires sont donc venues faire leur promotion : Inneractive, VServ, …

L’éditeur O’Reilly était présent le deuxième jour et proposait aux participants de la Droidcon des rabais sur ses livres. Les organisateurs possédaient également leurs stands afin de promouvoir leurs activités, Skills Matters propose d’ailleurs gratuitement un magazine trimestriel sur les technologies open source. Stackoverflow.com, site web très connu chez les développeurs, est venu présenter son site Careers 2.0, plateforme de recrutement pour les métiers de l’informatique.

Enfin, deux solutions technologiques étaient représentées, il s’agit de Testdroid (dont je parlerai dans un prochain article) et de Mopapp. La première est une solution de test pour les applications Android, la seconde, quant à elle, est une solution de suivi des ventes d’applications mobiles.

Voila pour la présentation de la Droidcon, promis, les prochains articles seront plus croustillants, et on y trouvera peut-être même des lignes de code

Une bouteille à la mer

Si nous reprenons le descriptif de l’échange (oui, encore, et ça ne fait que commencer…) :

Nous en sommes au 2), maintenant nous devons envoyer une demande d’authentification au fournisseur d’identité, avant de vouloir aller trop vite en s’intéressant à la demande d’authentification, j’attire votre attention sur le fait que nous ne savons pas envoyer de message !

Comme je l’ai indiqué, plus tôt, le standard SAML utilise des « bindings » pour décrire les différents modes de transmission des messages, il en existe six, cependant le « web browser SSO profile » auquel nous nous intéressons peut être basé sur le HTTP Redirect, le HTTP Post ou le HTTP Artifact.

Le HTTP Redirect Binding, comme son nom l’indique, consiste à envoyer au navigateur le code HTTP Redirect avec une URL dont les paramètres contiendront le message encodé. En pratique, les limitations des navigateurs sur les longueurs des URLs peuvent poser des problèmes pour des messages longs, ce binding sera donc réservé à des messages courts.

Le HTTP Post Binding, consiste à répondre à la requête de l’utilisateur par une page contenant un formulaire ayant pour cible le destinataire, pour plus de transparence, la page contient généralement un script pour valider automatiquement le formulaire.

Le HTTP Artifact Binding se base sur l’un des deux précédents pour transmettre un « artifact », cet identifiant va ensuite être utilisé par le destinataire dans le cadre du protocole de résolution d’artifact pour récupérer le message initial via un appel direct, pouvant par exemple utiliser le binding SOAP. Ce qui a l’avantage d’éviter de faire transiter le message par le navigateur, et l’inconvénient de supposer qu’il existe un chemin de communication direct entre les deux correspondants.

Il est aisé de constater que le plus long à mettre en œuvre est le HTTP Artifact, puisqu’il a parmi ses pré-requis l’existence de l’un des deux autres, ce qui n’est pas très encourageant. Notre requête étant courte, nous allons privilégier le binding Redirect.

En regardant plus en détail, le fonctionnement de ce binding, nous constatons que, outre la requête (ou la réponse), il existe un paramètre RelayState que le fournisseur  d’identité doit nous renvoyer tel que nous l’avons renseigné, cela va nous permettre de nous « souvenir » de la page à laquelle l’utilisateur voulait accéder. Pour envoyer un message par ce mécanisme, nous devons le compresser en utilisant DEFLATE (RFC1951), puis l’encoder au format base 64 et pour finir placer le résultat dans un paramètre nommé SAMLRequest ou SAMLResponse. Malheureusement pour nous Liferay ne fournit pas d’API pour gérer la compression DEFLATE, donc on va devoir la faire nous même, en fait, on va simplement se doter d’une classe utilitaire pour simplifier les appels à Deflater et Inflater de java.util.zip :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
package com.liferay.portal.kernel.util;



import java.io.UnsupportedEncodingException;



import java.util.ArrayList;

import java.util.List;

import java.util.zip.DataFormatException;

import java.util.zip.Deflater;

import java.util.zip.Inflater;



/**

 * @author Denis Vaumoron

 */

public class Deflate {



        public static byte[] encode(String string)

                throws UnsupportedEncodingException {



                Deflater lDeflater = new Deflater(Deflater.DEFAULT_COMPRESSION, true);

                lDeflater.setInput(string.getBytes(StringPool.UTF8));

                lDeflater.finish();



                int deflateLength;

                byte[] deflateBuffer = new byte[_BUFFER_SIZE];

                List bufferList = new ArrayList();

                while ((deflateLength =

                        lDeflater.deflate(deflateBuffer)) == _BUFFER_SIZE) {



                        bufferList.add(deflateBuffer);

                        deflateBuffer = new byte[_BUFFER_SIZE];

                }



                byte[] deflate =

                        new byte[bufferList.size() * _BUFFER_SIZE + deflateLength];



                for(byte[] buffer : bufferList) {

                        System.arraycopy(buffer, 0, deflate, 0, _BUFFER_SIZE);

                }



                System.arraycopy(deflateBuffer, 0, deflate, 0, deflateLength);



                return deflate;

        }



        public static String decode(byte raw[])

                throws UnsupportedEncodingException, DataFormatException {



                Inflater inflater = new Inflater(true);

                inflater.setInput(raw);



                int resultLength;

                byte[] valueBytes = new byte[_BUFFER_SIZE];

                StringBundler inflateBuffer = new StringBundler();

                while ((resultLength = inflater.inflate(valueBytes)) != 0) {

                        inflateBuffer.append(

                                new String(valueBytes, 0, resultLength, StringPool.UTF8));

                }

                inflater.end();



                return inflateBuffer.toString();

        }



        private static final int _BUFFER_SIZE = 1024;



}

Pour l’encodage base 64, on peut utiliser com.liferay.portal.kernel.util.Base64, ce qui donne le bout de code suivant :

1
2
3
byte[] samlDeflate = Deflate.encode(saml);



String samlBase64 = Base64.encode(samlDeflate);

Plutôt simple non ? C’est probablement parce que je n’ai pas mentionné que pour le profile web browser SSO, il est recommandé d’utiliser https (bon ok, c’est une fausse difficulté, cela se configure au niveau du serveur d’application), et de signer les messages (dans le cas où l’identification du fournisseur de service doit être vérifiée (ce n’est pas toujours le cas ? je me demande à quoi sert cette précision, si le fournisseur d’identité répond à « n’importe qui » avec toutes les informations sur l’utilisateur…)). Pour signer le message, il faut rajouter deux paramètres, SigAlg pour indiquer l’URI  de l’algorithme de signature utilisé et Signature pour la signature (que de surprise dans cet article) qui doit être encodé en base 64. La signature s’effectue sur les paramètres classés dans l’ordre SAMLRequest (ou SAMLResponse), RelayState (le paramètre ne doit pas apparaitre si la valeur est vide), puis SigAlg. Les algorithmes de signature DSAwithSHA1 et RSAwithSHA1 doivent être supportés, pour nous faciliter la vie nous allons utiliser java.security.Signature :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
        public static String getHTTPRedirectBindingUrl(

                        String serviceUrl, boolean isRequest,

                        String saml, String relayState, String signAlg)

                throws SystemException, IOException, GeneralSecurityException {



                byte[] samlDeflate = Deflate.encode(saml);



                String samlBase64 = Base64.encode(samlDeflate);



                StringBundler url = new StringBundler(7);

                url.append(serviceUrl).append(StringPool.QUESTION);



                StringBundler urlParamBuffer = new StringBundler(11);

                if (isRequest) {

                        urlParamBuffer.append(SAMLConstants.SAML_REQUEST);

                }

                else {

                        urlParamBuffer.append(SAMLConstants.SAML_RESPONSE);

                }

                urlParamBuffer.append(StringPool.EQUAL)

                        .append(HttpUtil.encodeURL(samlBase64));



                if (Validator.isNotNull(relayState)) {

                        urlParamBuffer.append(StringPool.AMPERSAND)

                                .append(SAMLConstants.RELAY_STATE)

                                .append(StringPool.EQUAL)

                                .append(HttpUtil.encodeURL(relayState));

                }



                urlParamBuffer.append(StringPool.AMPERSAND)

                        .append(SAMLConstants.SIG_ALG)

                        .append(StringPool.EQUAL)

                        .append(HttpUtil.encodeURL(

                                _getURIFromSignAlg(signAlg)));

                String urlParameters = urlParamBuffer.toString();



                url.append(urlParameters);



                url.append(StringPool.AMPERSAND)

                        .append(SAMLConstants.SIGNATURE)

                        .append(StringPool.EQUAL)

                        .append(_signUrlParameter(urlParameters, signAlg));



                return url.toString();

        }



        /**

         * Cette  méthode doit être utilisée avant l'envoi de la réponse,

         * afin d'initialiser les en-têtes corrects.

         *

         * @param response

         */

        public static void initHTTPHeader(HttpServletResponse response) {

                response.setHeader("Cache-Control", "no-cache, no-store");

                response.setHeader("Pragma", "no-cache");

        }



        private static String _signUrlParameter(

                        String urlParameter, String signAlg)

                throws SystemException, IOException, GeneralSecurityException {



                // les noms d'algorithme ne suivent pas la même nomenclature

                // dans SAML et dans java.security, donc on doit convertir.



                Signature signature = Signature.getInstance(

                        _getAlgorithmFromSignAlg(signAlg));

                signature.initSign(SAMLMetadataManager.getSPPrivateKey());



                signature.update(urlParameter.getBytes(StringPool.UTF8));

                return HttpUtil.encodeURL(Base64.encode(signature.sign()));

        }



        private static String _getURIFromSignAlg(String signAlg) {

                if (_DSA_WITH_SHA1.equals(signAlg)) {

                        return SignatureMethod.DSA_SHA1;

                }

                return SignatureMethod.RSA_SHA1;

        }



        private static String _getAlgorithmFromSignAlg(String signAlg) {

                if (_DSA_WITH_SHA1.equals(signAlg)) {

                        return _SHA1_WITH_DSA;

                }

                return _SHA1_WITH_RSA;

        }



        private static final String _DSA_WITH_SHA1 = "DSAwithSHA1";



        private static final String _SHA1_WITH_DSA = "SHA1withDSA";



        private static final String _SHA1_WITH_RSA = "SHA1withRSA";

Remarque : la méthode getSPPrivateKey de la classe SAMLMetadataManager (comme son nom ne l’indique pas) me permet de récupérer la PrivateKey associée au KeyStore qui contient ma clé. En attendant le sublime final de la troisième saison la troisième partie de cette série d’articles (qui concernera la gestion des métadonnées), vous pouvez lire la clé dans votre keystore de la manière suivante :

1
2
3
4
5
6
7
8
KeyStore keystore = KeyStore.getInstance(“jks”);

keystore.load(

        new FileInputStream(“chemin/vers/monkeystore.jks”),

        “MotDePasseDuKeyStore”.toCharArray());



PrivateKey spPrivateKey = (PrivateKey) keystore.getKey(

        “aliasDeLaClePrivee”,

        “MotDePasseDeLaClePrivee”.toCharArray());

Pour générer le fameux keystore et la clé correspondante, vous n’avez qu’à utiliser la commande suivante (keytool fait partie des outils fournit avec le JDK, faites un keytool –help si besoin) :

keytool –genkey -keyalg RSA -alias aliasDeLaClePrivee –keypass MotDePasseDeLaClePrivee –keystore monkeystore.jks
    –storepass MotDePasseDuKeyStore

C’est fini pour aujourd’hui

Et voila, nous avons notre bouteille, autrement dit nous sommes maintenant capable d’envoyer un message, vous en savez aussi un peu plus sur les « bindings » de SAML, nous verrons dans le prochain article comment générer la demande d’authentification, après tout on jette rarement à la mer une bouteille vide.

A bientôt pour de nouvelles aventures sur le blog Excilys…

Quésako

Vous avez sûrement déjà vu les pubs à la télé qui mettent en scène des nudistes en train de chercher leur portefeuille. Mais pourquoi ? Tout simplement parce qu’avec Kwixo, plus besoin de portefeuille, on peut payer avec son téléphone mobile pour rembourser un ami nudiste (ou pas d’ailleurs^[a]).

Mais ce n’est pas tout, Kwixo c’est également une solution pour payer sur internet chez des e-commerçants. Elle propose entre autres le paiement après réception mais aussi le paiement à crédit. Un login, un mot de passe et dites adieux aux numéros de cartes de crédit à rentrer sur un site dont vous ne savez même pas ce qu’ils vont en faire.

En bref, vous l’aurez compris, Kwixo s’annonce comme un sérieux concurrent du célèbre Paypal et nous sommes très fiers d’avoir pu contribuer par notre expertise technique.

Kwixo en chiffres

Une équipe de 20 personnes, dont 10 développeurs JavaEE, a sué sang et eau pendant deux années pour mettre au point ce projet qui, du point de vue technique, est parti de ZÉRO. En plus des problématiques techniques liées au démarrage, nous avons rencontré des problématiques d’intendance : pas de serveur pour le SCM^[b], une connection internet filtrée qui bloquait certains repository maven, des changements de locaux inopinés mais ce n’est pas ce qui nous a arrêté.

Au bout de deux ans, que dire ? Que nous avons effectué plus de 17 000 commits avec Git, environ 5 000 builds incassables avec Hudson/Jenkins, 210 000 lignes de Java (hors imports), 600 fichiers XML… Cela commence à donner une bonne idée de ce qu’est Kwixo. Derrière ces chiffres (magie des mathématiques), on trouve d’autres chiffres: 7 webapps, une base de données classique (sybase), une base de données NoSQL (CouchDB), 40 webservices REST/JSON, 30 batches, et 30 flows spring-webflow. Ça se précise.

Ajoutez enfin des processus fonctionnels compliqués, par exemple celui de l’inscription sur le site. 5 écrans.

	Validations classiques : Nom, Prénom, Âge
	Vérification de l’unicité de l’e-mail Vérification de l’unicité du mobile Vérification des transactions en attente Validation par One-Time Password du mobile
	Vérification de l’unicité du moyen de paiement Utilisation d’iframe pour PCI-DSS
	idem point (3)
	Création du compte Affichage des données saisies Envoi du mail de confirmation avec lien de validation

Comme vous pouvez le constater, lorsqu’on ajoute les différents contrôles, tout se complexifie.

Au point d’en arriver ici. Voici une bonne idée de ce qu’est Kwixo d’un point de vue technique.

Kwic-flow

Pourquoi Webflow plutôt qu’un moteur de BPM “classique” ? Parce que Webflow s’intéresse essentiellement à la gestion des enchaînements Web. Il s’agit d’une version “survitaminée” de SpringMVC. C’est pourquoi Kwixo (avec ses nombreuses procédures pas-à-pas) en fait une utilisation massive.

Nous avons d’abord tâtonné en nous penchant sur la (maigre) documentation officielle. Mais force a été de constater que la documentation n’est pas maigre mais bien rachitique. Et les articles de blogs et autres présentations ne vont que rarement au delà de la découverte du framework.

C’est pourquoi nous vous présenterons un retour d’expérience sur Webflow au travers d’une série d’articles sur les différentes techniques que nous avons mises en oeuvre, parmi lesquelles :

• Gestion du bouton précédent du navigateur. Sur le papier, cette fonctionnalité est déjà offerte par webflow. En réalité, bien que webflow embarque toute la mécanique pour le détecter “out of the box”, charge au développeur de faire en sorte que l’utilisateur soit prévenu de manière un peu plus claire que “Une erreur est survenue”.
• Réutilisation de code et factorisation : les subflow et l’héritage. Webflow propose des méthodes pour réutiliser des parties de cinématique d’écrans. Nous verrons comment les mettre en oeuvre au travers d’une validation par OTP d’un mobile.

Et comme un bon retour d’expérience ne saurait être exempt de toute critique, nous nous prendrons à rêver aux alternatives que nous aurions pu trouver à Webflow.

Les messages so quick

Kwixo envoie aussi des e-mails, des SMS et affiche des alertes et des notifications à droite à gauche. Un bombardement continu de messages très différents les uns des autres, sur plusieurs canaux (SMS, web, e-mail) et aux contenus délicatement ciselés et régulièrement revus par les services marketing et juridique.

Pour faire fonctionner tout ça de manière transparente, non-bloquante pour les processus métier et accessible par le commun des mortels, Kwixo s’est bien creusé la tête. Il a étudié diverses options séduisantes (“j’ai une idée! on va mettre des annotations partout”), et après refactoring intense a fini par porter son choix sur son architecture de messaging actuelle.

Parmi les ingrédients du cocktail final, on trouve de l’évènementiel, du JMS, du NoSqL et des processus démoniaques.

Recette à suivre …

L’icône du mail est sous licence GPL et a été crée par Alessandro Rei

Dans les premiers articles, nous allons voir comment gérer l’authentification unique, la deuxième partie aura pour sujet la déconnexion centralisée, et la série s’arrêtera avec une apothéose pour la fin de la saison 3 une troisième partie pour traiter d’une pierre deux coups, la correspondance entre les attributs et l’utilisation des métadonnées.

Bien que cette série d’articles soit une application au portail Liferay, elle traite essentiellement de SAML 2.0, et fournit les bases pour l’intégration de ce standard à une application JEE.

Rappel sur les protagonistes

Liferay est un portail JEE top moumoute (où donc ai-je pris ces mauvaises habitudes de langages ???) très abouti, il est compatible avec les spécifications portlets 1.0 et 2.0 (respectivement JSR 168 et JSR 286), et fournit nativement un grand nombre de fonctionnalités (CMS, forum, wiki, blog, etc. …). I

SAML (pour Security Assertion Markup Language) est un standard développé par l’OASIS pour la fédération d’identité, basé sur des échanges de messages XML, qui comporte des assertions (les fameux messages XML), des protocoles (autrement dit des échanges de messages, avec format des requêtes et des réponses), des « bindings » (comprendre un mode de transmission des messages) et des « profiles » (scénario s’appuyant sur les éléments précédents pour décrire un cas concret, par exemple l’authentification unique d’un navigateur (Web Browser SSO Profile)).

L’authentification unique

Avant de pouvoir se déconnecter de manière centralisée, il faut déjà s’être connecté, pour cela, regardons plus en détail le « Web Browser SSO Profile ».

Ce scénario comporte 3 acteurs, l’utilisateur (via son navigateur), le fournisseur de services (ou SP, Service Provider, Liferay dans notre cas) et un fournisseur d’identité (ou IdP, Identity Provider, pour mes tests j’avais mis en place SimpleSAMLphp sur un server WAMP) :

1. L’utilisateur tente d’accéder à une ressource protégée du fournisseur de services sans contexte de sécurité
2. Le fournisseur de service envoie une demande d’authentification au fournisseur d’identité (message <AuthnRequest>) à travers le navigateur (redirection ou page générant un POST automatique)
3. Le fournisseur d’identité identifie l’utilisateur (page de connexion ou utilisation d’une session pré-existante)
4. Le fournisseur d’identité envoie une réponse au fournisseur de services (message <Response>, toujours en passant par le navigateur)
5. Le fournisseur de service peut se baser sur la réponse du fournisseur d’identité pour créer un contexte de sécurité, et ensuite accorder ou refuser l’accès à la ressource demandée initialement.

Premier pas dans Liferay

Maintenant que l’on a une idée un peu plus claire de ce que l’on souhaite faire, regardons le portail Liferay, et essayons de comprendre comment fonctionnent ses mécanismes d’authentification. Liferay s’intègre déjà avec plusieurs solutions de SSO (dont notamment CAS et OpenSSO (voir aussi OpenAM)) grâce au système d’AutoLogin.

La propriété « auto.login.hooks » du fichier portal.properties (qui peut être surchargé par le fichier portal-ext.properties à la racine du serveur Liferay, ou par plugin hook ou ext) contient une liste de classes qui implémentent l’interface AutoLogin, ces classes sont appelées successivement pour les utilisateurs non connectés jusqu’à ce que l’une d’entre elles renvoie un couple valide identifiant d’utilisateur et mot de passe. Dans ce cas, l’utilisateur sera automatiquement connecté au portail (Non, bien sûr ce n’est pas magique, pour plus de précision jetez un coup d’œil à la classe AutoLoginFilter). C’est aussi ainsi qu’est implémenté le « Remember me » (voir RememberMeAutoLogin qui fonctionne avec un cookie).

Nous allons donc créer une classe SAMLAutoLogin implémentant AutoLogin (comme c’est original…) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
package com.liferay.portal.security.auth;



import com.liferay.portal.kernel.log.Log;

import com.liferay.portal.kernel.log.LogFactoryUtil;



import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;



public class SAMLAutoLogin implements AutoLogin {



        @Override

        public String[] login(

                        HttpServletRequest request, HttpServletResponse response)

                throws AutoLoginException {



                // TODO Auto-generated method stub



                return null;

        }



        private static Log _log = LogFactoryUtil.getLog(SAMLAutoLogin.class);



}

Si nous reprenons notre descriptif de l’échange, nous avons presque notre 1), en effet, l’AutoLogin va nous permettre de laisser le soin à Liferay de savoir quand est accédée une ressource protégée. Pour cela, il suffit de constater que lorsque l’utilisateur tente de lire un contenu restreint, le portail affiche le formulaire d’authentification par le biais d’une action Struts d’url « /portal/login », qui redirige vers la portlet Login (je suis sûr que vous ne vous attendiez pas à celle là), qui est une portlet Struts.

Avant de me mettre à répéter Struts sans arrêt, petite piqure de rappel, Liferay est basé sur Struts, et la majorité des portlets natives utilisent le bridge Struts de Liferay. Pour les curieux, ça se passe dans portlet-custom.xml (où se trouve portlet-class), liferay-portlet.xml (voir struts-path), et le classique struts-config.xml. Nous allons donc pouvoir, en testant la présence de « /portal/login/ » dans l’url, savoir que l’utilisateur doit se connecter, vous l’aurez peut-être remarqué, cette astuce fonctionne aussi si l’utilisateur utilise le lien de connexion.

Et là, les petits malins ceux qui sont attentifs se disent : « Lorsqu’on fait du SSO, l’objectif n’est pas de connecter automatiquement l’utilisateur déjà authentifié auprès du fournisseur d’identité dès qu’il arrive sur le site ? Sans qu’il ait besoin de cliquer sur le lien de connexion, ou qu’il ne tente de lire un document privé (qui ne devrait pas être affiché puisqu’il n’est pas connecté). », ce n’est pas faux, mais nous rectifierons plus tard.

Je rappelle (sait-on jamais) que voulant mettre en place une authentification unique, la portlet Login doit être bannie de vos pages…

C’est fini pour aujourd’hui

Nous voilà déjà arrivé à la fin de ce premier article, je vous ai présenté le mécanisme de l’authentification unique dans SAML, et nous avons commencé à l’intégrer dans un portail Liferay en interceptant les utilisateurs non connectés. Dans le prochain article, nous aborderons l’envoi de message via les « bindings ».

A bientôt pour de nouvelles aventures sur le blog Excilys…

Une pointe de GWT dans un monde de JSP

Pour rappel, une portlet comporte un ensemble de vues associées à des états. Pour afficher une application GWT dans une portlet, il suffit de l’insérer dans les vues en question sous forme de widget. Dans notre exemple, nous travaillerons sur une vue implémentée en JSP.
Dans une JSP d’une application web ordinaire, nous aurions écrit ceci :

et le code java de notre entryPoint inclurait la ligne de code suivante :

Cependant, nous préférerons laisser à Liferay le soin d’importer les fichiers javascript et css dans la page qui abrite la portlet. Pour cela, nous déclarons l’import dans le fichier liferay-portlet.xml :

Le fichier JSP de notre vue ne contiendrait plus que la div.

Communiquer avec le back (in black) par ACD… non, je veux dire RPC

Notre application GWT est désormais affichable dans une portlet. Nous devons maintenant lui faire afficher des données provenant du back-end et notamment des données associées à l’utilisateur actuellement connecté (donc dépendantes de la session HTTP en cours). Nous avons deux solutions possibles pour permettre au front-end de récupérer ces données :

• La première solution consiste à inscrire ces données dans la JSP en utilisant des scriptlets ou les taglibs de liferay (liferay-theme) pour ensuite les récupérer par JSNI.
• La seconde solution est la mise en place d’un service RPC entre le front et le back.

Je ne détaillerais pas plus la première solution qui peut se révéler contraignante si on essaie de transporter des objets complexes et qui risque de faire intervenir du code métier dans la couche de présentation (notamment à cause des potentiels scriptlets).

Nous allons donc mettre en place un service RPC. Cette solution est plus simple, plus standard et par conséquent plus facilement maintenable.
Cependant, un problème va se poser au moment de récupérer la session HTTP. Notre implémentation de service est définie dans une servlet (RemoteServiceServlet) qui vit sa vie indépendamment du portail et n’a donc pas accès à une éventuelle HttpSession.

Pour répondre à ce problème, Liferay nous met à disposition la classe PortalDelegateServlet qui permet de partager (ou déléguer) les sessions du portail avec celles d’une autre servlet (en l’occurrence l’implémentation de notre service RPC). Pour cela, nous devons déclarer la servlet déléguée dans le fichier web.xml de notre portlet de la façon suivante :

Ensuite, nous redéfinissons dans la partie cliente de notre service l’url où contacter l’implémentation :

Enfin, dans l’implémentation de notre service RPC, il est possible d’accéder à la requête HTTP qui a permis l’affichage de la portlet grâce à la méthode getThreadLocalRequest de l’api GWT-RPC. Nous pouvons alors récupérer l’utilisateur actuellement connecté en utilisant la classe PortalUtil de l’api de Liferay.
Notre implémentation ressemble à ceci :

Serializable or IsSerialisable, that is the question

Tant que le service RPC transmet des types simples, la solution décrite plus haut ne pose aucun problème. Malheureusement, si votre service envoie des objets (DTO) plus complexes, c’est une autre histoire.
Le problème est que notre passage par le PortalDelegateServlet fausse le contextPath des requêtes et empêche GWT de charger le fichier définissant la politique de sérialisation. En conséquence, GWT utilise la politique par défaut qui consiste à ne supporter que les classes implémentant IsSerializable.
Pour rappel, indépendamment de l’intégration dans Liferay, un objet DTO transmis par RPC doit implémenter les interfaces IsSerializable de l’API GWT ou Serialisable de java (depuis la version 1.4 de GWT) si la politique de sérialisation est correctement chargée.

Tout ceci ne nous laisse que deux options:

• Se résigner à utiliser l’interface IsSerializable qui reste spécifique à GWT.
• Forcer le chargement de la politique de sérialisation en travaillant sur le contextPath manipulé par le service RPC.

Dans notre cas et malgré les recommandations de Google, nous avons préféré implémenter java.io.Serializable (plus standard). Ainsi, pour contourner notre problème, j’ai réimplémenté la méthode doGetSerializationPolicy du service RPC :

Le fin mot de l’histoire

Intégrer GWT dans une portlet Liferay s’effectue aussi simplement que dans une page JSP. Il faut cependant tenir compte du partage de session du portail, du chargement des fichiers javascripts et css et de l’éventuel accès au contextPath. Notez que la portlet dans laquelle nous avons travaillé n’est pas instanciable et que les solutions énoncées ne seraient pas suffisantes pour faire fonctionner plusieurs instances d’une même portlet GWT dans une même page (notre div d’ancrage étant chargée 2 fois avec le même identifiant). Il existe des solutions pour remédier à cela mais je ne les ai pas mises en pratique.