Forum Zimbra 2012 Zimbra et la SSO

Forum Zimbra 2012

MESSAGERIE & SSO

Plan

Introduction

• Problématique• SSO

CAS & Zimbra

• Principe• Mise en œuvre• Avantage /

Inconvénient

KERBEROS & Zimbra

• Principe• Mise en œuvre• Avantage /

Inconvénient

SHIBBOLETH & Zimbra

• Définition• Principe• Etat des lieux• Mise en œuvre

Cas Clients

• Inra• Univ. Tours• HCC• InstitutTelecom

2

Introduction• Problèmatique :Un SI existant sans gestion centralisée des logins

et des mots de passe1 à n applications 1 application = 1 login + 1 ⇒

mot de passesoit n application = 1 login + x mot de passesoit n application = y login + x mot de passe

Introduction• Problèmatique:Comment trouver un équilibre entre sécurité et

simplicité ?- Sécurité pour le SI- Simplicité pour la maintenance du SI- Simplicité pour l’utilisateur

Introduction

• SSO = Single Sign OnUne authentification => Accès à 1 ou plusieurs

ressourcesMise en œuvre : - d’une configuration simple à la plus

compliquée

Zimbra &

• CAS = Central Authentication Server• Plusieurs implémentations & langages :– Java (Consortium Jasig Open Source)– Ruby– Perl

Zimbra &Principe

Zimbra &

• Pré-requis– Disposer d’un référentiel utilisateurs + mots de passe(Active Directory, serveur OpenLDAP, serveur MySQL…)– Un serveur accueillant le service CAS– Un utilisateur ayant les droits de lecture sur le référentiel– Synchronisation avec un serveur de temps commun (NTP)

Mise en œuvre

Zimbra &

• Installation– Exemple à partir de l’implémentation de JASIG– Un serveur d’application JEE (ex: Tomcat)– Déploiement de l’application (cas.war)

• Paramétrage du serveur d’application :Le serveur doit fournir du https

Mise en œuvre

Zimbra &

• Paramétrage du service CASConfiguration du service CAS pour le référentiel sélectionné :– AD– Serveur OpenLDAP– MySQL– Autres …Ajout des bibliothèques correspondantes aux modules

Mise en œuvre

Zimbra &

• CASsification de Zimbra :– Importation du certificat CAS (SSL)– Installation des bibliothèques clientes CAS sur Zimbra– Modification du fichier zimbra.web.xml.in : redirection

d’URL vers l’application CAS

Mise en œuvre

Zimbra &

• CASsification de Zimbra– Génération de la clef de pré authentification du domaine

de messagerie– Création du fichier preauth.jsp

• Résultats :– Si l’utilisateur n’est pas encore connu : mire de login CAS– Si l’utilisateur est déjà connu via une application déjà

CASsifiée : l’utilisateur arrive directement dans son compte Zimbra

Mise en œuvre

Zimbra &

• Mise en œuvre simple• Possibilité de CASsifier

plusieurs domaines de messagerie avec un seul cluster Zimbra

• Faire de Zimbra un point d’entrée unique pour les autres applications CASifiées

• La CASsification est uniquement au niveau du web

• Pas possible de CASsifier la synchronisation mobile (SyncML)

• Protocole IMAP non CASsifié

Avantage / Inconvénient

Zimbra & KerberosUne association pour dépasser les limitations du Web

• CAS + Référentiel utilisateurs : limité au web• CAS + module Kerberos/SPNEGO : une authentification

unique de l’OS aux applications Web

Zimbra & KerberosPrincipe

• 1 ère phase : l’utilisateur se connecte à sa session applicative de son OS => première et unique authentification

• 2 ième phase : l’utilisateur lance son navigateur pour aller dans sa messagerie Zimbra => pas d’authentification

AUTO LOGIN

Une solution Simple dans la forme mais compliquée dans le fond

Zimbra & Kerberos

• Pré-requis– OS doit être kerbérisé– Un utilisateur ayant des droits administrateur sur l’AD– le serveur CAS doit être intégré au royaume Kerberos– Un compte utilisateur dédié pour la création de la keytab

• Installation :– Reprise de l’ensemble des opérations d’un CAS classique– Ajout d’un module supplémentaire à CAS : SPNEGO

Simple and Protected GSSAPI Negotiation Mechanism– Ajout des bibliothèques supplémentaires :

– jcifs-1.2.15.jar– jcifs-ext-0.9.4.jar

– Bibliothèques clientes Kerberos

Mise en œuvre

Zimbra & KerberosMise en œuvre

• Paramétrage :– Fichier krb5.conf– fichier smb.conf– Net join –U <user-admin> -S <IP_AD>– Module SPNEGO :

• pom.xml• cas.properties• login-webflow.xml• cas-servlet.xml• deployerConfigContext.xml• login.conf (à créer)

– AD : création d’un keytab avec service principal– Migration du fichier keytab sur le server CAS

Zimbra & Kerberos

• Paramétrage IE :– outils -> avancé -> sécurité cocher Activer l'authentification Windows

intégrée.– onglet général -> intranet local -> site -> avancé -> et ajouter l'adresse

https://cas-server– Redémarrage IE

• Paramétrage FireFox :– dans la barre d'adresse taper about:config– Modification de l’attribut network.automatic-ntlm-auth.trusted-uris :

https://cas-server– Redémarrage Firefox

Mise en œuvre

Zimbra & Kerberos

• CASsification de Zimbra (vu précédemment)

Mise en œuvre

Zimbra & Kerberos

• 1 mot de passe + 1 login = accès à tout• Basé sur des standards (RFC 4120, RFC 4537, RFC

5021, RFC 5896, RFC 6111, RFC 6112, RFC 6113 )• 1 serveur CAS => auto login sur aplications CASsifiées• Très contraignant dans l’implémentation :

– Nécessité d’avoir des accès administrateurs– Nécessité de modifier tous les postes clients– Sans AD nécessité d’installer un KDC– Maintenance

Une authentification forte au service de l’utilisateur

Zimbra & ShibbolethDéfinition

• La shibbolethisation permet d'utiliser un mécanisme de SSO afin d'accéder à des ressources dont les propriétaires ne gèrent pas les utilisateurs.

• Implémentation SAMLv2 (Security Assertion Markup Language version 2), standard soutenu par OASIS.

Zimbra & Shibboleth

• IDP : Identity Provider. Correspond à un fournisseur d'identité (nom d'utilisateur et mot de passe).

• SP : Service Provider. C'est lui qui présente le service shibbolitisé et fourni la ressource à l'utilisateur.

• WAYF : Where Are You From ? Permet de sélectionner le fournisseur d'identité auquel appartient l'utilisateur.

Principe : repose sur 2 briques + 1 optionnelle

Zimbra & ShibbolethZimbra et Shibboleth : état des lieux

• Implémentation SAMLv2 dans Zimbra = incomplète• Classe Java existantes• Assertions SAML nécessaires au niveau de Zimbra =

inconnues

Un mariage impossible ?

Zimbra & Shibboleth

• Déplacement de la problématique• Utilisation d’un reverse proxy Apache HTTP• Pré authentification déléguée => accès au compte de

messagerie Zimbra

Mise en oeuvre

Zimbra & Shibboleth

• Pré-requis :– Un serveur http dédié– Synchronisation (NTP)

• Installation : apache http • Paramétrage Apache HTTP:

– Activation mod_shib– Activation de l’interpréteur PHP (php-xml-util)– Activation SSL– vhost

Mise en oeuvre

Zimbra & Shibboleth

• Installation du service shibboleth• Paramétrage du démon shibd

– Génération clef privée + certificat– Récupération du certificat de la fédération d’identidé– shibboleth2.xml :

• Hostname du SP• URL de l’IDP• URL du WAYF• Les attributs SAML à récupérer• URL des META DATA• Certificats …

– attribute-map.xml

Mise en oeuvre

Zimbra & Shibboleth

• Création de la pré authentification– Déporté au niveau du serveur proxy– Codée en PHP

• Schéma du proxy

Mise en oeuvre

• Possibilité de transmettre des attributs• Un SSO sur des ressources tierces• Beaucoup d’interaction entre les différents acteurs• Maîtrise des chaînes de certification• Technologie faiblement déployée

Zimbra & Shibboleth

Zimbra & Shibboleth &

Zimbra & SSOConclusion

• Portail d’accès unique• Différentes techniques : CAS, Kerberos, Shibboleth, …• Un mix des différentes techniques• Souplesse de Zimbra• Une communauté Open Source innovante et réactive

Quelques exemples chez nos clients :• INRA : Yaziba.net

– 10 000 collaborateurs– 93 sites distants sur toute la France– Inscription auto avec LDAP et CAS

• Université de Tours : Zimbra sur site– 33 000 collaborateurs– Plusieurs sites sur Tours et ses environs– Intégration CAS

Quelques exemples chez nos clients :

• Hôpitaux Civils de Colmar : Zimbra sur site– 1 500 collaborateurs– CAS/Kerberos auto-login

• Institut Télécom : Zimbra sur site– 8 000 collaborateurs– 3 sites répartis sur toute la France– Service Provider Shibboleth

Des questions ?

Annexes

Ressources Web• http://www.jasig.org/cas• http://code.google.com/p/rubycas-server/• http://lemonldap-ng.org/documentation/1.1/authcas• https://wiki.jasig.org/display/CAS/CASifying+Zimbra+6.0• http://wefunction.com/2008/07/function-free-icon-set/• http://shibboleth.internet2.edu/

Bibliographie• Single Sign-On open-source avec CAS (Central Authentication Service) :

Pascal Aubry, Vincent Mathieu, Julien Marchal

<!-- CAS filter configuration begin --> <filter> <filter-name>CasSingleSignOutFilter</filter-name> <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class> </filter> <filter-mapping> <filter-name>CasSingleSignOutFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <listener> <listener-class>org.jasig.cas.client.session.SingleSignOutHttpSessionListener</listener-class> </listener> <filter> <filter-name>CasAuthenticationFilter</filter-name> <filter-class>org.jasig.cas.client.authentication.AuthenticationFilter</filter-class> <init-param> <param-name>casServerLoginUrl</param-name> <param-value>https://cas-server:8443/login</param-value> </init-param> <init-param> <param-name>serverName</param-name> <param-value>http://zimbra-server:80</param-value> </init-param> </filter>

<filter-mapping> <filter-name>CasAuthenticationFilter</filter-name> <url-pattern>/public/preauth.jsp</url-pattern> </filter-mapping> <filter> <filter-name>CasValidationFilter</filter-name> <filter-class>org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter</filter-class> <init-param> <param-name>casServerUrlPrefix</param-name> <param-value>https://cas-server:8443/</param-value> </init-param> <init-param> <param-name>serverName</param-name> <param-value>http://zimbra-server:80</param-value></init-param> <init-param> <param-name>redirectAfterValidation</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>CasValidationFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <filter> <filter-name>CasHttpServletRequestWrapperFilter</filter-name> <filter-class>org.jasig.cas.client.util.HttpServletRequestWrapperFilter</filter-class> </filter> <filter-mapping> <filter-name>CasHttpServletRequestWrapperFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <!-- CAS filter configuration end -->

Krb5.conf[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log

[libdefaults] ticket_lifetime = 24000 default_realm = DOMAIN.TLD default_keytab_name =

/var/lib/tomcat6/webapps/cas-server/spnegoaccount.keytab dns_lookup_realm = false dns_lookup_kdc = true default_tkt_enctypes = rc4-hmac des-cbc-md5 default_tgs_enctypes = rc4-hmac des-cbc-md5

[realms] DOMAIN.TLD = { kdc = srvad.domain.tld:88 admin_server = srvad.domain.tld:749 default_domain = domain.tld }

[domain_realm] .domain.tld = DOMAIN.TLD domain.tld = DOMAIN.TLD

• Net join –U <user-admin> -S <IP_AD>• ktpass.exe /out spnegocas.keytab /princ HTTP/cas-

server@REALM /pass * /mapuser spnegocas@REALM /ptype krb5_nt_principal /crypto DES-CBC-MD5