As a new owner of an yubikey, I was looking the best way to integrate it with the web application I already use. While there is already an available OpenID provider which support Yubikey authentication, I prefer to manage my own system, using OpenSSO for sure
First, let me introduce the yubikey. This USB key act as an OTP (One Time Password) device, each time you press the button, the key compute a new password. This pasword must be verify, in the case of Yubikey, this is done by query a Webservices on a yubico (the company) server. Yubikey offers a lot of advantages than others classical OTP devices, including:
The yubikey is see as an USB keyboard (class HID), no driver required!
No battery, more longlife than anothers devices
Very cheap, around 20 euros (ordered by 10, from France), transport and taxes included
So, why choose OpenSSO? For few years know, OpenSSO provides an extension to act as an OpenID provider, and an authentication class is available for the Yubikey.
Most of system administrators use OpenSSL (which is not a good idea, but it’s an another story) to manage their PKI. While OpenSSL is good to create/convert X509 certificates from PEM/DER to PKCS#12 (and vice versa, for sure) it doesn’t understand the JKS (Java KeyStore) format. JKS are used in Java world, for example Glassfish application server, OpenDS and so more. In this post, I’ll explain how to convert a PKCS#12 to a JKS using portecle. portecle is a small, but very useful application (written in Java) to manipulate keystores.
Download portecle, extract it, and lauch it using java -jar portecle.jar (note that Java 6 seems required for version 1.4.x)
Open your PKCS#12 file, provide the password
Click on Tools/Change KeyStore Type/JKS menu
If you don’t want to use the default password (which is password), click on the menu keystore password
Save it, that’s all folks!
You can know list the contents of your JKS using keytool:
Comme tout le monde, vous entendez parler du cloud computing, mais vous ne savez pas forcément ce qui se cache derrière ce terme ? Vous connaissez déjà, mais vous voulez en savoir plus ? Bref, dans tous les cas, si ce sujet vous intéresse, je vous invite à participer à la soirée organiser par cloudcamp. Cette soirée aura lieu le 11 Juin, à partir de 18h30. Pour ma part, je dois y intervenir pour parler de la sécurité.
Je me permet de rappeler, pour mes fidèles lecteurs, que Solaris/OpenSolaris est très proche du concept de cloud computing notamment grâce aux containers (zones + resource shapping), et OpenStorage.
As a member of the LSM staff, I organize a track about IAM. The schedule is almost closed, including:
Pat Patterson, from OpenSSO, the famous Access Manager (SSO) of Identity Federation tool from Sun (english)
Ludovic Poitou, from OpenDS, the future Sun’s Directory Server (english or french)
Clément Oudot, from LemonLDAP::NG, an opensource Web SSO (english or french
Tomas Gustavsson, from EJBCA, the most famous opensource PKI product (english)
Jonathan Clarke, from LSC, a tool to synchronize directory from JDBC or LDAP (english or french)
Myself, introducing about IAM, especially the provisionning (french)
This day is planned for July, the 10th, at Nantes. Check LSM website to register in a near future (registration are not opened yet). For OpenDS, LemonLDAP::NG and LSC talks, the language will be choosen according the audience.
Un rapide poste qui je l’espère fera suite à d’autres pour exposer une petite surprise que j’ai eu avec LDAP (enfin de manière plus précises avec les serveurs). Lors d’un projet pour mon nouvel employeur, on me demanda d’installer un OpenSSO pour authentifier des utilisateurs et obtenir leurs attributs LDAP. Bon, jusqu’ici rien d’anormal. Néanmoins, dans les attributs utilisateurs, il est demandé un attribut fournissant la date de la dernière connexion d’un utilisateur (en pratique la date d’un dernier bind opéré avec succès). Sur le moment, je n’ai pas percuté. Ce n’est qu’au moment de revenir sur mon poste, et par acquis de conscience, que j’ai commencé à me renseigner.
Et quelle ne fut pas ma surprise lorsque je me suis rendu que :
OpenSSO ne le permet pas de base. Après une rapide rechercher, il semblerait qu’une manière simple (c’est tout relatif) est d’écrire une classe (Java) qui sera exécutée après une authentification utilisateur.
Active Directory semble fournir cette fonctionnalité de base (via l’attribut lastlogon)
Sun Directory Directory Server Entreprise Edition (DSEE pour faire court) ne semble à priori pas le supporter dans toutes ses versions (>= 6.2 de mémoire, à prendre avec grande précaution) (tests en court)
OpenDS le supporte (tests en court)
Sun iPlanet 5.x ne le supporte tout simplement pas
Je n’ai pas regardé pour les autres serveurs, si jamais vous avez des retours dessus, je suis preneur.
Évidemment, je vous laisse deviner quel serveur j’utilise. Donc, je me suis retrouvé à écrire un plugin (en C) pour iPlanet, j’avoue que cela est assez intéressant (enfin il y a bien pire comme tâche . Je vais mettre à disposition le code de ce plugin d’ici quelques jours, même si je doute qu’en Avril 2009 cela intéresse encore beaucoup de gens !
Pour information, pour obtenir cette fonctionnalité avec DSEE et OpenDS, il faut utiliser les password policies, et n’activer que la partie concernée. Cela va mettre à jour le champ ds-pwp-last-login-time(au moins vrai pour OpenDS).
Néannmoins, j’avoue que je suis assez surpris que cela ne soit pas de base, partout, dans tous les serveurs LDAP. Certes, cela demande un minimum de performances supplémentaires. En effet, cela provoque une écriture (opération considérée comme lente sur un annuaire LDAP) à chaque opération d’authentification réussie (mais on pourrait imaginer de vouloir l’équivalent pour un last failure). Mais au point de vue gestion d’identité, c’est quand même une information qui peut être très intéressante. Au hasard, sur un portail public, d’obtenir rapidement, et simplement, la liste des utilisateurs qui ne se sont pas connectés depuis une année.
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 !
Malgré une santé économique plus ou moins bonne, des licenciements, (mais a contrario une bonne publicité) ça bouge beaucoup chez Sun, notamment dans le domaine de l’IAM. Pour preuve, il suffit de regarder l’activité autour d’OpenSSO, et de WebSpaces
Pour OpenSSO, comme le montre la roadmap, il y a des choses fort intéressantes en prévision. Comme par exemple un mandataire inverse (reverse proxy) avec la possibilité de gérer des accréditations secondaires. En pratique, cela permet de protéger une application où il est impossible d’installer un agent, et qui ne supporte pas SAMLv2. De manière concrête, cela se traduit par de l’injection de formulaires (fillform) du login/mot de passe de l’utilisateur. La solution d’un mandataire inverse permet de rendre plus faible (et surtout plus quantifiable avant vente) les coûts d’intégration d’une application dans un SSO.
D’autres points notables concernant OpenSSO résident dans l’avancé du support d’OpenDS (avec reset du mot de passe), et la création d’une fedlet en .Net.
WebSpaces
Je n’ai encore pris longtemps pour faire un billet sur WebSpace, mais je tacher de résumer de manière rapide. Glassfish WebSpace est le fruit du partenariat entre Sun et Liferay, avec pour objectif de créer une nouvelle version de Sun Portal Server (ce qui d’ailleurs, ne fais pas que des heureux parmi les clients actuels, à juste titre). WebSpace est fourni avec un certain nombre de porlet existantes, dont certaines orientées enterprise. Je m’intèresse particulièrement à la porlet Workflow, qui permet de créer des petits processus (workflows) simples, comme par exemple la gestion des notes de frais (c’est l’exemple fourni). Pour ma part, j’ai comme objectif de créer une porlet de demande de congé (avec double approbation). J’en dirais plus dans un prochain billet !
Maintenant que tout le monde utilise SMF (enfin je l’espère ! ), voici quelques informations qui pourront vous être utiles, autour du cas d’utilisation suivant :
Soit un glassfish (serveur d’application) qui – pour une obscure raison qui n’a pas d’intérêt ici – doit écouter sur les ports 80 et 443, mais ce service étant administré par un consultant métier, je ne veux en aucun cas donner le moindre droit root à cette personne, que ce soit pour démarrer ou arrêter glassfish, ou même encore pour son exécution. Cela semble difficile à réaliser au premier abord, mais SMF va nous sauver !
La gestion des privilèges
SMF permet d’assigner des priviléges (vous pouvez obtenir la liste des privilèges ainsi qu’une courte description en utilisant la commande ppriv -l -v) à un service. Pour cela, il faut éditer son manifest, puis rajouter la portion de code suivant :
Maintenant que nous avons notre glassfish qui écoute sur le port 80 et 443 sans avoir besoin du moindre processsus root, il nous reste à déléguer l’administration du service à l’utilisateur approprié. Pour cela, effectuer les modifications suivantes :
le fichier auth_attr définit la liste des attributs étendus qu’un utilisateur, dans ce cas, on créer un nouveau attribut que l’on nomme solaris.smf.manage.glassfish
Les deux lignes suivantes autorise les utilisateurs disposant de l’attribut solaris.smf.manage.glassfish à administrer le service (vous pouvez consulter la page de manuel smf_security pour avoir plus de détails)
Et finalement, on assigne le privilège solaris.smf.manage.glassfish à l’utilisateur glassfish
Désormais, l’utilisateur glassfish peut démarrer et éteindre le serveur d’application sans jamais disposer du moindre droit root (pas de sudo ou équivalent nécessaire). Dites merci SMF !
Few days ago, I thought it was a pity there is no place to discuss about IAM. Well, ok, there are some places like Sun IDM’s forums, the #opensso channel, etc. however all this place are related to a specific product. For example I don’t think the Sun IDM’s forum is a good place to ask question about pros and cons of Sun IDM vs Novell IDM Well, you can, but there is a big chance that all answers leads you on Sun IDM !
So, as you probably ever guessed, I create an IRC channel, so you can join us (there are already some very interesting people!) on the freenode network (irc.freenode.net), on the channel ##iam, note the double # is not a typo.
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
