Dans le premier épisode article, nous avons vu comment intercepter l’accès à une ressource protégée dans Liferay (ou plus précisément comment lui laisser tout le boulot grâce aux mécanisme d’autologin), aujourd’hui nous allons réagir à cette agression évènement.
Si nous reprenons le descriptif de l’échange (oui, encore, et ça ne fait que commencer…) :
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.
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.
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)).
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.
