Ça y est votre API REST est en place, vous avez rédigé une belle documentation et même mis en place un client swagger pour aider vos clients à l’utiliser.

Puis arrive le temps des premiers retours d’utilisation de vos clients, certains trouvent que votre API met trop de temps à répondre sur telle ou telle requête.

En général c’est à ce moment là qu’on commence à mettre en place un système pour logguer la durée de traitement de vos requêtes. En général vous utiliserez la notion de Filter ou d’Interceptor (si vous utilisez Spring MVC) ou tenterez d’utiliser des outils plus avancés tels que JavaMelody (il faut vraiment que j’essaye ce truc d’ailleurs).

En fait il y a beaucoup plus simple, il suffit de demander cela non pas à votre application mais à votre conteneur de servlets (ici Tomcat). Il existe déjà dans les fichiers de log de Tomcat les localhost_acces_XXX.log qui tracent chaque requête (la méthode HTTP, l’URL demandée, le code retour etc…).

Le format de ces logs se configure dans le server.xml, par défaut la “Valve” utilisée est AccessLogValve qui permet de tracer tout un tas d’informations mais pas le temps que Tomcat a pris pour fournir une réponse à la requête, pour cela il vous faut utiliser l’Extended Access Log Valve et faire apparaître dans le pattern de log le “time-taken”.

Ci dessous un exemple de server.xml :

<Valve className="org.apache.catalina.valves.ExtendedAccessLogValve" directory="logs"
  prefix="localhost_access_log." suffix=".txt"
  pattern="date c-ip cs-method cs-uri cs-uri-query sc-status time-taken" />

OpenAm est un véritable couteau suisse du SSO, à première vue son côté “usine à gaz” peut en rebuter certains (qui lui préféreront sans doute CAS) mais je vous invite à effectuer le tutoriel Getting Started With OpenAM pour vous faire un avis. Le système extensible d’authentication module d’OpenAM vous permettra d’adapter la mécanique d’authentification si le mode username + password n’est pas suffisant. Le seul point de difficulté que j’ai personnellement rencontré est la personnalisation de la page de login. Depuis la version 12.0.0, OpenAM propose un système appelé XUI (basé sur des templates javascript et le framework CSS “Less”) qui me paraît plutôt compliqué à prendre en main. Concrètement, si votre projet nécessite un mode d’authentification “exotique” comme par exemple :

• un premier écran avec un nom d’utilisateur et un password
• un second écran avec un second password ou code à saisir

Le système d’authentication module vous permettra de décrire et d’implémenter cette logique d’authentification, en revanche vous serez assez limité en ce qui concerne la personnalisation de la partie présentation de vos écrans d’identification sans parler des modes de saisies que vous auriez peut être envie de modifier comme par exemple les claviers virtuels (à la mode sur les sites bancaires) où l’on saisie son code à la souris.

Heureusement OpenAM expose ses services d’authentification (et d’autres) au travers de web services REST,et d’appeler avec les données saisies par votre utilisateur le web service d’authentification. Ci dessous l’exemple avec la commande cUrl fourni dans la doc :

curl \
 --request POST \
 --header "X-OpenAM-Username: demo" \
 --header "X-OpenAM-Password: changeit" \
 --header "Content-Type: application/json" \
 --data "{}" \
 https://openam.example.com:8443/openam/json/authenticate
{ "tokenId": "AQIC5w...NTcy*", "successUrl": "/openam/console" }

Si les identifiants sont valides, le service retourne le fameux jeton d’identification qu’il vous suffit d’attacher en tant que cookie à la session de votre utilisateur. Ceci nécessitera bien sûr que votre instance d’OpenAM tourne sur le même domaine que vos applicatifs (si ce n’est pas le cas sur l’environnement de développement, pensez à faire une correspondance dans votre fichier Host de manière à ce que cela soit le cas) : Si votre OpenAM tourne sur openam.mycompany.com il suffit de modifier votre hosts :

127.0.0.1    localhost mypc.mycompany.com

Ainsi votre application locale tournera sur le même domaine (mycompany.com) que votre SSO et le partage du cookie sera possible.

Jeremy Passeron

Senior Java Developer, Iot (aka Internet Of Things), Connected-Health

Download PDF (comming soon…) [jpasseron AT gmail DOT-COM]

Profile

…comming soon…