Blog Excilys

Cette suite d’articles a pour objectif de présenter l’intégration d’un portail Liferay en tant que fournisseur de services dans une fédération d’identité basé sur SAML 2.0 (authentification et déconnexion unique (SSO et SLO)). Le travail décrit fait partie d’un développement sponsorisé qui a été reversé à la communauté (voir LPS-8427), et devrait être disponible dans la version 6.1 de Liferay, le patch proposé supporte aussi la version 1.1 de SAML, celle-ci étant moins complète que la version 2.0, nous ne nous y intéresserons pas ici.

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

Lire la suite…

Au cour d’un projet, il m’a été demandé d’étudier la possibilité d’intégration d’une application GWT dans une portlet Liferay. Je vais vous présenter dans cet article la solution retenue.
Lire la suite…

Vous avez probablement pu voir dans la littérature, si vous êtes un Git-fanboy intéressé par Git, différents workflows décrivant une utilisation possible de Git en équipe, mais peu de concret concernant leur mise en place.

Lire la suite…

Connaissez-vous l’histoire de l’exception dont on a perdu trace ?

Vous le savez probablement, chaque service GWT-RPC est en réalité une servlet. Petit rappel :

• les appels Ajax GWT-RPC sont réalisés en POST,
• le nom de la méthode du service à appeler est spécifié dans la requête envoyée,
• l’appel est traité dans la méthode doPost(HttpServletRequest request, HttpServletResponse response), qui se charge de désérialiser les paramètres, faire appel à la bonne méthode du service par réflexion, puis sérialiser la réponse.

Que se passe t’il lorsque la méthode du service jette une exception ? Deux possibilités :

• soit l’exception est déclarée dans l’interface du service, et celle-ci sera sérialisée jusqu’au client, qui pourra la traiter correctement,
• soit ce n’est pas le cas (y compris pour les RuntimeException), et le client recevra une erreur 500, et le tristement célèbre :
  

  The call failed on the server; see server log for details

Lire la suite…

Le framework GWT met à disposition du développeur plusieurs API pour communiquer avec un serveur en HTTP.

L’une des possibilités offertes est l’utilisation du framework deRPC, présent depuis GWT 2.0. Cette nouvelle implémentation de GWT RPC est top moumoute, à tel point que Sami Jaber, dans son (très bon) livre Programmation GWT 2, considère l’ancienne API comme dépréciée et invite à utiliser uniquement deRPC.

Alors, faut-il adopter deRPC les yeux fermés ? Attention malheureux ! DeRPC peut considérablement augmenter la taille de vos requêtes HTTP.

Au cours d’une mission, j’ai ainsi découvert la multiplication par 50 de la taille d’une requête, de 200 Ko à 10 Mo.

Lire la suite…