Limitations et TODO

La version actuelles est une version de développement et de démonstration limitée. Je liste ici les principales limitations est les développement associer à réaliser.

Support Liberty Alliance

Le support Liberty Alliance est très incomplet. Seul les fonctionnalités suivantes sont implémentées :

• Fédération via SOAP initiée depuis LAAP ;
• SSO via SOAP initié depuis LAAP ;
• SLO via SOAP intiié depuis LAAP ;
• Partage d'attributs initié depuis LAAP ;
• Fin de partage d'attributs initié depuis LAPP.

Toutes les autres fonctionnalité sont manquantes, dont en particulier :

• SSO et SLO depuis l'IdP ou un autre SP ;
• terminaison de Fédération (depuis LAAP ou l'IdP) ;
• contrôle sur le partage d'attributs ;
• possibilité d'appartenir à plusieurs cercles de confiance.

De plus, seul le mécanisme de sécurité « NULL » (i.e : pas de mécanisme de sécurité supplémentaire) est implémenté : les autres mécanismes supportés par Liberty Alliance restent à implémenter.

Configuration

L'ensemble de la configuration de LAAP a besoin d'être unifiée, ou pour le moins normalisée. Ceci passe par mettre au même endroit les fichiers de configuration que l'utilisateur est amené à toucher, créer une interface d'administration dans LAAP.

D'autre part, la configuration nécessite la création d'une API pour tout ce qui touche à la configuration Liberty Alliance. Cette API doit permettre de générer et modifier les méta-données, ajouter ou supprimer des cercle de confiance, gérer les politiques de sécurités, etc.

Tests unitaires

De très nombreux test unitaires sont manquants. Avant de poursuivre les développement, il faudrait les compléter afin de vérifier les problèmes de bugs sur l'existant et de régressions futures. Tiers « business-logic » Aujourd'hui, la partie métier et la logique associée est très simple du fait du peu de cas d'utilisation implémentés. Ceci ne sera plus vrai lorsque plus de fonctionnalités seront implémentées. Ce tiers est donc à revoir, en particulier au niveau de la gestion de la concurrence, de la robustesse des données.

Struts 2

Struts 2 est sortie en version finale avec sa version 2.0.6. Or, une grande partie du code qui utilise Struts 2 l'a été alors qu'il n'était disponible qu'en version 2.0.0 (béta). Il faudrait reprendre le code produit et le modifier pour tirer partie des (grosses) évolutions que Struts 2 a subit, comme l'utilisation de l'intercepteur « preload », de « 0 config », la validation des champs via les annotations, etc.

Gestion des Web Services et rôles des servlets

L'application LAAP a deux grand type d'interlocuteurs avec qui il communique par le web : les utilisateurs, via les pages HTML ; les autres applications, par SOAP et par re-direction, GET et POST.

Dans le premier cas, l'interaction passe par Struts 2. Dans le deuxième cas, tout n'est pas très clair : les web services sont gérés par Spring-WS, mais sans passer par les intercepteurs de Struts 2, alors que pour les redirection et accès par GET et POST, Struts 2 intervient… Et qu'en est-il des mécanismes de sécurité ?

Bref, un grand nettoyage est à faire. Il peut être intéressant d'utiliser Struts 2 partout en adaptant les sections en fonction des besoins (ceci semble pertinent, Xworks n'est pas fait que pour gérer des interfaces Web graphiques). Dans ce cas, il faudrait normaliser les interactions entre Struts 2 et Spring-WS.

D'autre part, un refactoring sur les échanges SOAP ne faisant pas partie des Web-Services ID-SIS-PP s'impose en utilisant Spring-WS.

DAO

Pour l'instant, une seule implémentation de back-end à la DAO est disponible et il est très limite : en effet, les objets sont directement stockés en mémoire, avec les limitations que cela implique (pas de vraie persistance des informations, problème de montée en charge, etc). Il faudrait réaliser un back-end SQL standard, avec (par exemple) Hibernate ou Ibatis, et une base SQL.