Suite à mon article et la création d’une imageVMWare pour démontrer l’utilisation d’EJBCA et d’OpenSSO pour faire de l’authentification X509 client, Pat ma gentiment demandé si je pouvais écrire un article à ce sujet. Et c’est maintenant chose faite, l’article est disponible ici. En route pour la deuxième partie !
Interest by OpenSSO (especially in the Access Manager part)? If yes, you should be interest by my VMWare image. The image was made to demonstrate an application protected by opensso. The application is divided in three parts, the first one is available for everyone (non authenticated users). The second part, the secure area, is available only for users authenticated in OpenSSO, and members of group employee. And finally, only users authenticated by certificates and member of group employee can access to the very secure area.
You need to give >= 1024MB of memory for the image. Indeed, lot of services are required for the demonstration. (One Tomcat, one JBoss, one OpenDS, and one Glassfish).
Boot the image, some services may take few minutes to start, depends of your configuration
Login using root account, with password root
When you opened the VMX file from VMWare, it ask if your copy or moved the virtual image. If you choose copy, you need to execute the following commands to get network working:
Execute the command ifconfig eth and identity the IP address of the image
On the host system (your desktop, NOT on the image) edit your /etc/hosts (or equivalent) file, add the following line:
172.16.19.136 opensso.local.asyd.net
Start your favorite browser, hit http://opensso.local.asyd.net:8000/ and follow instructions. The first access to each application may take some few minutes, be patient!
As usual, any feedbacks are welcome.
Notes:
In order to access to the very secure area, after importing the certificate, you usually need to restart your browser. Indeed, most of browsers use a persistent HTTP/1.1 session with server, in this case, the HTTPS negociation is made only one time.
The glassfish’s console is http://opensso.local.asyd.net:4848/ not http://opensso.local.asyd.net:4848/opensso
Suite à une petite discussion avec Tomas (de PrimeKey) sur OpenSSO, nous nous étions dis qu’un petit exemple d’utilisation conjointe d’OpenSSO et d’EJBCA serait intéressant (ne serait-ce qu’au niveau marketing , voici le résultat de mon travail.
Avant tout, voici le cas d’utilisation, assez simple en fait. Soit une application disposant de trois parties :
une partie publique, accessible à tout le monde
une partie privée, accessible uniquement aux membres d’un groupe donné
une partie super privée (oui bon, si vous avez un meilleur terme !), accessible uniquement aux membres d’un groupe (qui peut être le même que précédemment), mais dont l’authentification doit être obligatoirement effectuée par certificats.
En fait, suite aux divers billets du présent blog, cela peut paraître relativement simple, et étrangement, une fois les petits soucis réglés, ca se fais assez bien. Cela m’a permis d’aborder pas mal de nouvelles notions dans OpenSSO, notamment sur les stratégies (pour le contrôle d’URL), qui n’est pas forcément très intuitif. J’ai surtout passé du temps sur l’écriture des règles, car dans mon cas (une petite application JSF développée très rapidement avec NetBeans) l’URL que je dois préciser dans les règles sont différentes de celles visibles par le navigateur. J’imagine que l’ordre dans lequel les filtres sont déclarés dans le fichier web.xml de l’application y sont pour quelques choses.
Quelques points à retenir (surtout un pense bête personnel) :
pour la configuration de la chaîne d’authentification, j’en ai créée une nouvelle avec les deux modules (X509 et DataStore) en SUFFISANT, attention l’ordre est important, l’instance du module X509 doit donc être placé avant celle du DataStore)
l’accès aux pages publiques s’effectuent via la propriété NOT ENFORCED URI (qui permet de dire à l’agent d’ignorer certaiens URL)
définir l’URL du 403 dans le web.xml, la rajouter en NOT ENFORCED URI
si l’url du 403 est défini dans le web.xml, ne pas la définir au niveau de l’agent
j’ai attribué un score de 10 à l’authentification par certificat
j’ai utilisé deux stratégies, l’une pour autoriser l’accès à la partie sécurisée (en ayant un pattern matching d’URL assez fin). Une autre pour autoriser l’accès à tout (donc y compris la partie super sécurisée) mais en rajoutant une condition sur le niveau d’authentification
ne pas oublier de modifier le fichier bootstrap si on ne veut pas utiliser le royaume par défaut
Je mettrais bientôt en ligne une image VMWare (fusion, je ne sais pas si elles sont compatibles avec les autres) qui contient le serveur opensso, l’ejbca, et l’application. Prévoyez au moins 1GB de RAM rien que pour la machine virtuelle !
Avec un peu d’avance (la version stable d’EJBCA 3.8 n’étant encore pas finalisée) voici un bref apercu des nouvelles fonctionnalités, dont certaines très attendues par des heureux possesseurs de matériel un peu sensible, genre les ILOs des HPs (ils se reconnaitront).
Possibilité de définir l’ordre du DN (CN=blog.asyd.net,O=asyd dot net,C=FR ou C=FR,O=asyd dot net,CN=blog.asyd.net) dans le profil du certificat. Avant cette version il était nécessaire de créer une autorité spécifiquement pour ces besoins. Cela permet de générer des certificats pour des équipements acceptant uniquement un ordre particulier.
Des changements assez profonds sur la notion d’administrateur. Il ne sera désormais plus nécessaire de cocher la case « Administrateur » dans le profil d’entité. De plus, des administrateurs peuvent utiliser des certificats issus de différentes AC (dont une AC non gérée par EJBCA) pour s’authentifier dans un groupe d’administrateur. On notera également quelques améliorations au niveau ergonomie dans la partie gestion des groupes administrateurs.
Une nouvelle fonctionnalité très intéressante pour ceux qui utilisent les WebServices d’EJBCA est apparue. Elle permet l’aggrégation (merge) du DN fourni lors de l’appel au WebService editUser à celui défini dans le profil d’entité. Imaginons par exemple un profil d’entité définissant des attributs du DN tel que « O=asyd dot net,C=FR », si la fonctionnalité de mergeDN est activé, il suffira de passer le DN « CN=Bruno Bonfils » à la méthode SOAP editUser pour obtenir le DN « CN=Bruno Bonfils, O=asyd dot net,C=FR », cela évite de maintenir la méthode de construction du DN au niveau du client.
Une autre fonctionnalié, peut être moins visible, mais quelques fois tout aussi importante, est la capacité d’ajouter un administrateur par la ligne de commande, via le numéro de série du certificat.
Parce que la configuration n’est pas forcément évidente, et aussi pour ne pas la chercher à chaque fois, voici un rapide howto pour configurer apache en front d’un EJBCA avec authentification des administrateurs.
Configurer le fichier workers.properties, puis ajouter la section suivante dans la confguration de votre VirtualHost :
, voici le résultat de mon travail.