Un Electron Libre...

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

Tag - authentification

Fil des billets - Fil des commentaires

samedi 11 octobre 2008

Suite de "Apache : authentification intégrée sauf pour certains clients dont on ne connait pas la provenance réseau"

Dans le billet Apache : authentification intégrée sauf pour certains clients dont on ne connait pas la provenance réseau, je pensais arriver au résultat de ne pouvoir déclarer que les IP des filiales en SSO pour que le reste du monde puisse se connecter en anonyme. Grave erreur et elle était même inscite dès le départ dans ma configuration.

Cette méthode, même si elle a le mérite de montrer comme utiliser mod_setenvif, ne répond pas à mon besoin dans la mesure où elle me force en fait à déclarer tout le monde. Déclarer le réseau de chaque filiale dans un groupe qui est présent dans 54 pays et ensuite maintenir ces déclarations à chaque évolution du réseau est clairement rédibitoire pour l'exploitabilité de la solution.

La solution, certes moins élégante, mais qui marche a été de mettre en place deux virtual hosts au niveau d'apache qui consulte la même instance eZ Publish. Le premier sur le port 80 n'est paramétré que pour accéder avec une authentification SSO et le second en anonyme. Pour faire la répartition des filiales suivant si elles doivent attaquer une instance SSO ou anonyme se fait au niveau des routeurs internes vu que des règles similaires étaient déjà en place pour une autre application.

Dès lors, l'exploitabilité est simplifiée et en plus centralisée au niveau des routeurs. Cela évitera/limitera des oublis à l'avenir...

Pour revenir à ce que je voulais faire dans Apache, je pense que cela n'est pas possible à peu de choses près en l'état actuel. Peut être que l'évolution de la directive Require et de mod_authz_host dans Apache 2.3 aurait pu me fournir ce qu'il me manquait pour tout gérer au niveau d'apache et n'avoir qu'un seul virtual host en place.

jeudi 21 août 2008

Apache : authentification intégrée sauf pour certains clients dont on ne connait pas la provenance réseau

Cas d'étude : une application auxquels les collaborateurs d'une entreprise accèdent via une authentification intégrée. Pour les filliales ne disposant pas du SSO ou pour permettre à des utilisateurs extérieurs de se connecter à l'application, une connexion anonyme doit être mise en place.

Solution retenue :

Principe : par défaut, le serveur va chercher à authentifier l'utilisateur par authentification intégrée.

Exception : pour l'indexation de l'application, il faut autoriser l'accès anonyme au serveur

Problématique : seuls les plages IP des pays utilisant l'authentification intégrée est connue. Il faut donc permettre l'accès en anonyme à tout le monde sauf ces IP là.

L'importance ici tient dans la directive Order, Allow , Deny, Satisfy et SetEnvIf.

LoadModule auth_ntlm_winbind_module modules/mod_auth_ntlm_winbind.so
LoadModule setenvif_module modules/mod_setenvif.so
 
<Location />
    Order Deny,Allow
    Deny From All
 
    <IfModule mod_auth_ntlm_winbind.c>
        AuthName "NTLM Authentification"
        NTLMAuth on
        NTLMAuthHelper "/usr/bin/ntlm_auth --helper-protocol=squid-2.5-ntlmssp"
        NTLMBasicAuthoritative on
        AuthType NTLM
    </IfModule>
 
    Require valid-user
	<fModule mod_setenvif.c>
		# Declaration des clients utilisant l'authentification intégrée
		SetEnvIf Remote_Addr "10\.(10|13|14|19|20|44|45|49)\.[0-9]{1,3}\.[0-9]{1,3}" pays # Pays 1
		SetEnvIf Remote_Addr "10\.(70|18|48)\[0-9]{1,3}\.[0-9]{1,3}" pays # Pays 2
 
		# Declaration de l'IP du robot indexant le site
		SetEnvIf Remote_Addr "10\.135\.255\.(1|44|35|244)" indexation
	
		# Declaration de la machine pour generation du cache statique
		SetEnvIf Remote_Addr "(127\.0\.0\.1|10\.135\.255\.45)" local
		
		# Sont autorises en anonyme "tout le monde" sauf les pays avec authentification intégrée.
		Allow from env=local env=indexation !env=pays
	</IfModule>
	Satisfy any
</Location>

vendredi 13 avril 2007

OpenID, le LDAP pour PME/TPE ?

OpenID est un système d'authentification unique (SSO ou Single Sign On en anglais) et décentralisé. Le système permet donc à un utilisateur d'utiliser son compte OpenID dans différentes applications web (sous réserve qu'elles intègrent cette fonctionnalité d'authentification) en lieu et place d'avoir un compte par application. Génial, non ?

Dans de nombreuses entreprises, ce système de compte unique est généralement mis en oeuvre via un annuaire LDAP (que ce soit avec la solution Microsoft Active Directory, ou la solution libre OpenLDAP par ex). Même si les fonctionnalités d'un annuaire LDAP vont plus loin que le simple stockage de compte (on peut l'utiliser comme un annuaire "pages blanches", stocker des droits applicatifs, etc), force est de constater que beaucoup d'entreprises (et en particulier les TPE/PME) n'utilisent que cette fonctionnalité d'authentification unique.

Dès lors, plutôt que de se doter d'un serveur ActiveDirectory ou OpenLDAP requérant des compétences en la matière, il peut être plus économique pour une entreprise de déployer un serveur OpenID (il existe une implémentation dans tous les langages ou presque). Ainsi, l'entreprise peut implémenter cette solution d'authentification unique sans impacter sensiblement son parc informatique, ni se doter de compétences particulières.

C'est trop beau pour être vrai et vous n'avez pas tout à fait tort. Les réserves tiennent pour le moment aux éléments suivants :

  • L'authentification via OpenID est encore faiblement implémentée, même si cela bouge très vite à ce sujet et des acteurs importants du web ont déjà implémenté ce système dans leur infrastructure (AOL, Microsoft, LiveJournal, Verisign, Zoomr, etc)
  • Pour les applications non web, OpenID ne peut pas être utilisée à ma connaissance. Là encore, des solutions techniques doivent pouvoir être trouvées pour contourner ce problème (webservices, etc).
  • Si vous voulez faire plus que de l'authentification, ce n'est pas prévu (à ce jour du moins).

Bref, tout ça pour dire qu'OpenID est à mon avis une alternative crédible face aux annuaires LDAP pour des besoins d'authentification simples et pour des applications web.Il serait bête de ne pas évaluer et prendre en compte dès maintenant, même si sa généralisation devra attendre un petit peu (sauf si vous avez la chance d'utiliser des outils disposant déjà de "connecteurs" OpenID...)

Quelques liens utiles (liste non exhaustive) :

lundi 26 février 2007

Djangoseries du matin...

Pour celles et ceux qui voudraient un dépôt de code (snippets) un peu comme les snippets de Symfony ou "Les petits bouts de code à Niko" mais en Django en lieu et place de Symfony, ils vont être ravis de l'annonce de la sortie de Django Snippets et du logiciel servant à faire tourner ce dépôt : Cab.

Toujours au passage, le module d'authentification a été sorti du projet cab et peut donc être réutilisé à outrance : Django-Registration.

Sinon, la version 0.96 avec notamment les newforms et le framework de test devrait sortir d'ici peu.