Zork[Yy]'s log

Aller au contenu | Aller au menu | Aller à la recherche

Tag - authentication

Fil des billets - Fil des commentaires

dokuWiki et intégration : SSO, annuaire, modèles & co

Préambule

Avant de parler plus spécialement de dokuWiki , un point sur le mot intégration d'applications. Que signifie "intégrer une application ou un progiciel ou un module ou ..." et comment le permet-on ?

On peut avoir plusieurs niveaux d'intégration entre 2 applications (Web j'entends), toutes doivent être, si possible, transparentes pour l'utilisateur :

  • inclure des données d'une application A dans une application B : l'utilisateur se trouve sur la A, et des informations du site B sont incluses dans le 1er sous diverses formes : flux RSS, widget, OpenSocial, à l'aide d'une API (service Web SOAP, REST, XmlRPC, ...) ou non (fichiers, base de données ou LDAP partagés entre 2 ou N applis) de la part du site B (on peut considérer un flux comme une mini API),
  • à partir d'une application A, qu'un utilisateur puisse se connecter sur une application B pour y interagir (Google docs, Wiki, enquêtes, etc), avec bien souvent des droits bien particuliers (autorisations),

2 applications seules dans leur coin fonctionnent en général bien, mise à part tout le process de leur mise en place (développement etc), la difficulté devient exponentielle lorsqu'il s'agit d'intégrer de façon transparente pour l'utilisateur une application dans une autre pour y apporter un service supplémentaire.

L'intégration d'une application est souvent rendu possible à l'aide d'API sous forme de services Web (données, annuaire, ...) et aussi également par l'ajout d'un (Web)SSO qui permet à l'utilisateur de passer d'une application vers une application avec son même login et mot de passe et ce, sans se reconnecter s'il l'était déjà, s'authentifier qu'une seule fois est très important afin de faciliter l'usage des outils.

Lire la suite...

OpenID, Google, Yahoo, Orange, MyOpenID, Facebook, LiveID and me : l'authentification à moindre frais

Préambule

J'admets : j'ai un penchant, non pas pour la bière (quoique) mais pour les standards, protocoles et autres APIs, ouverts dans la mesure du possible.

Il reste toujours préférable de respecter les standards qui sont établis par des instances du type W3C pour ce qui concerne le Web, IETF pour tout protocole lié à Internet (TCP/IP, SMTP, ...) sous forme de RFC, ou encore les standards de fait : développé par une société qui l'a libéré afin qu'il soit adopté par la suite par le plus grand nombre, souvent sous forme d'une fondation (qui regroupe un consortium de sociétés / d'organismes).

Lire la suite...

RPXnow, OpenID ou la fédération des protocoles d'authentifications

Grand fan de la première heure d'OpenID, je trouve ce système d'authentification très prometteur. J'en avais fait une brève présentation dans ce billet avec myopenid.com, ou encore dans cet exemple pour utiliser son domaine à la place de myopenid.com.

Lire la suite...

PuTTY, SSH et autologin

Lorsqu’on est amené à gérer une dizaine de serveurs sous Linux (Debian), cela devient vite rébarbatif de devoir inscrire son login et son mot de passe pour ouvrir une session SSH, d’autant plus qu’on devra également s’authentifier pour utiliser sudo si nous le devons, autant le faire une fois de moins.

Les outils dont on a besoin

  • PuTTY : client SSH sous Windows
  • PuTTYgen pour la génération du certificat (normalement livré avec l’installeur PuTTY)
  • Pageant , un agent d’authentification sous Windows qui utilisera le certificat – sauvegarder l’exécutable dans un répertoire PATH (d:\temp par exemple)
  • ssh-keygen côté serveur du package openssh-client de Debian (apt-get install openssh-client)

Procédure d’activation de l’auto-login

Générer une clé publique et privée avec PuTTYgen en 3 étapes : Generate, bouger la souris pour générer une séquence aléatoire, puis mettre un mot de passe (Key passphrase) puis sauvegarder les 2 clés (mykey.pub et mykey.priv par exemple).

Copier le fichier mykey.priv.ppk dans le répertoire de Pageant (dans le PATH d’installation, d:\temp dans notre cas).

PuTTYgen

PuTTYgen

PuTTYgen

La clé publique (fichier mykey.pub) servira au serveur SSH, la clé privée (fichier mykey.priv.ppk) à l’agent pageant.

Sur le serveur sur lequel vous vous connectez en SSH :

  • créer sur le répertoire de travail du compte SSH utilisé un répertoire .ssh (par exemple, je me connecte avec le compte od, alors il existe /home/od/.ssh)
  • télécharger le fichier de la clé publique (mykey.pub) dans le répertoire créé précédemment (~/.ssh).
  • exécuter :

$ ssh-keygen -i -f ~/.ssh/mykey.pub > ~/.ssh/mykey2.pub

$ cat mykey2.pub >> authorized_keys2

  • sous windows, créer un fichier agentautologin.cmd avec comme contenu:

“d:\temp\pageant.exe” “d:\temp\mykey.priv.ppk”

  • puis exécuter le, l’agent se met en tâche de fond (icône dans la barre de tâche windows) – vous devrez entrer le mot de passe fixé lors de la génération des clés.

  • sous PuTTY, créer et configurer le serveur sur lequel vous souhaitez accéder, ainsi que le login d’accès (od dans notre cas), le serveur SSH mappera automatiquement sur le login et déclenchera l’authentification et l’ouverture de session, ceci à l’aide des 2 clés publique (ssh) et privée (pageant)

PuTTY

PuTTY

Logon

Il reste plus qu’à vous logguer sur le serveur, il s’authentifiera automatiquement.

Connexion SSH

Un sudo -s pour effectuer vos opérations de maintenance, et c’est parti.