Un autre article sur Alfresco, dans celui ci juste de la modification et configuration de fichiers pour activer le SSO avec l’AD et utiliser le protocole CIFS avec le content repository d’Alfresco. SSO : Single Sign-On, Authentification unique en français. AD : Active Directory, un service de Microsoft pour centraliser l’authentification à un réseau d’ordinateur. Nous allons relier les deux ! CIFS : Common Internet File System, un protocole qui autorise la projection du content repository d’Alfresco en tant que périphérique réseau partagé natif.
La problématique est la suivante :
L’entreprise dans laquelle je travail actuellement possède un parc informatique sous Windows, même si c’est un choix discutable c’est comme ça. Chaque poste est relié au domaine de l’entreprise et donc connecté à l’Active Directory : les comptes utilisateurs ne sont pas uniques à un poste mais valable pour n’importe quel poste relié au domaine. Pour se connecter à Alfresco il faut habituellement un compte spécifique à Alfresco ou bien on relie le système d’authentification d’Alfresco à l’Active Directory. C’est justement ce que nous allons faire dans cet article. De plus nous verrons comment configurer correctement le protocole CIFS.
Choisir un sous-système adapté
L’authentification sous Alfresco est un système composé de sous-systèmes (subsystem). Chaque subsytem propose sa méthode d’authentification avec ses fonctionnalités, un joli tableau de comparaison est disponible sur le wiki d’Alfresco. Comme on peut le voir le subsystem passthru correspond parfaitement à ce que nous souhaitons : Authentication via a Windows domain server, nous choisirons donc ce subsystem en plus d’alfrescoNtlm afin de garder tout de même une authentification pour les comptes de base d’Alfresco : Native Alfresco authentication. Ces deux subsytems supportent le protocole CIFS.
Où modifier mes fichiers
Alfresco est codé en JAVA et utilise donc un serveur TomCat pour son déploiement. Deux dossiers dans le serveur TomCat sont importants : webapps et shared. Le premier, webapps, contient votre instance actuelle d’Alfresco avec ses fichiers de configuration. Le second, shared, contient les extensions des fichiers de configuration d’Alfresco. Il ne faudra donc jamais toucher au fichier de configuration contenu dans webapps mais modifier ceux dans shared afin d’étendre la configuration de base d’Alfresco. De cette façon vous garderez vos personnalisations d’une mise à jour à l’autre.
Configurer alfrescoNtlm
Comme nous l’avons vu juste au dessus il va falloir créer nos fichiers de configuration dans le dossier shared. Les fichiers ce configuration pour les subsytems doivent être dans le répertoire : » shared/classes/alfresco/extension/subsystems/Authentication » par défaut les dossiers n’existent pas, c’est à vous de les créer. Notez que je n’invente pas le chemin mais que l’on doit suivre l’arborescence définie dans le dossier webapps pour étendre correctement ce que l’on souhaite.
Chaque dossier dans Authentication doit avoir pour nom le subsytem que nous utiliserons, comme nous souhaitons configurer le subsystem alfrescoNtlm nous créeons un dossier du même nom (shared/classes/alfresco/extension/subsystems/Authentication/alfrescoNtlm). Ensuite il faut créer un répertoire pour chaque configuration différente du subsytem en question, je vais créer un répertoire que je nomme alfinst. Au final le chemin complet vers cette configuration du subsytem alfrescoNtlm est le chemin suivant : shared/classes/alfresco/extension/subsystems/Authentication/alfrescoNtlm/alfinst/ .
Tous les fichiers dans les dossiers de configuration des subsystems doivent finir en .properties pour être pris en compte, cependant le nom n’importe pas. On peut donc tout mettre dans un seul fichier ou faire autant de fichier que l’on souhaite si on veut séparer des directives.
Comme c’était indiqué dans le tableau du wiki d’Alfresco, le subsytem alfrescoNtlm utilise le protocole NTLM pour tout ce qui relate au SSO. Je vais créer un fichier à part pour toutes les propriétés qui touchent à ce protocole:
ntlm-filter.properties
ntlm.authentication.sso.enabled=false ntlm.authentication.mapUnknownUserToGuest=false ntlm.authentication.browser.ticketLogons=true
Les directives sont assez explicites, cependant il nous faut désactiver le service SSO du protocole NTLM avec le subsytem alfrescoNtlm si nous voulons l’utiliser avec le subsytem passthru : En effet une seule instance de subsytem peut être la cible du protocole NTLM, cette restriction est imposée par le protocole lui même. Maintenant je crée un deuxième fichier properties pour y écrire toutes les directives relatives au coeur de l’authentification d’Alfresco :
alfresco-authentication.properties
alfresco.authentication.allowGuestLogin=false alfresco.authentication.authenticateCIFS=false
Le protocole CIFS est soumis aux mêmes restrictions que le protocole NTLM, on le désactivera pour le subsytem alfrescoNtlm. Voila, il n’y a rien de plus à faire, on passe maintenant au subsytem passthru.
Configurer passthru
De la même façon que pour le subsytem alfrescoNtlm, on crée les dossiers qui contiendront une configuration du subsytem passthru : shared/classes/alfresco/extension/subsystems/Authentication/passthru/passthru1/ et on crée autant de fichier properties qu’on en a besoin. Je vais dans mon exemple en crée deux, répartis exactement de la même façon que pour le subsytem alfrescoNtlm.
ntlm-filter.properties
ntlm.authentication.sso.enabled=true ntlm.authentication.mapUnknownUserToGuest=false ntlm.authentication.browser.ticketLogons=true
Dans le subsytem passthru j’active le service SSO du protocole NTLM car c’est ce subsytem qui supporte l’authentification sur un domaine Windows, je peux l’activer car il n’est pas déjà demandé par une autre configuration d’un autre subsytem. Enfin je crée mon deuxième fichier qui contiendra les spécificités relatives au coeur d’Alfresco:
passthru-authentication-context.properties
passthru.authentication.useLocalServer=false passthru.authentication.domain= passthru.authentication.servers=DOMAIN\\IP,IP passthru.authentication.guestAccess=true passthru.authentication.defaultAdministratorUserNames=Administrator,kizux #Timeout value when opening a session to an authentication server, in milliseconds passthru.authentication.connectTimeout=5000 #Offline server check interval in seconds passthru.authentication.offlineCheckInterval=300 passthru.authentication.protocolOrder=NetBIOS,TCPIP passthru.authentication.authenticateCIFS=true passthru.authentication.authenticateFTP=true
Les directives sont simples à comprendre, dans les serveurs je mets deux possibilités : l’ip du serveur où est situé l’Active Directory en spécifiant le domaine, et l’ip seule. Pour les administrateurs, le compte Administrator est un compte local d’Alfresco et kizux est un compte externe de l’Active Directory. Pour finir j’active le protocole CIFS pour ce subsytem, lors de la connexion au périphérique réseau l’authentification par AD sera possible.
Configurer la chaîne d’authentification
Il faut maintenant configurer Alfresco pour qu’il utilise nos deux subsystems, pour ce faire comme souvent une chaîne d’authentification entre en jeu. Il faut la définir dans le fichier alfresco-global.properties situé dans le dossier shared/classes, si c’est la première fois que vous étendez Alfresco il faudra retirer l’extension .sample du fichier pour que celui ci soit prit en compte. Editer ou ajouter la ligne suivante :
authentication.chain=alfinst:alfrescoNtlm,passthru1:passthru
Lors de l’authentification d’un utilisateur nous vérifions d’abord si il n’est pas un utilisateur local d’Alfresco avec l’instance alfinst du subsystem alfrescoNtlm puis si ce n’est pas le cas on vérifie si l’utilisateur appartient au domaine de l’entreprise grâce à l’instance passthru1 du subsytem passthru. C’est exactement le même ordre pour le protocole CIFS que nous voyons tout de suite.
Etendre le SSO pour Alfresco Share
Maintenant que le SSO est actif pour l’interface Alfresco Explorer, nous allons l’étendre à l’interface Alfresco Share. Pour se faire vous devez modifier le fichier xml shared/classes/alfresco/web-extension/share-config-custom.xml de telle façon :
<connector> <id>alfrescoCookie</id> <name>Alfresco Connector</name> <description>Connects to an Alfresco instance using cookie-based authentication</description> <class>org.springframework.extensions.webscripts.connector.AlfrescoConnector</class> </connector> <endpoint> <id>alfresco</id> <name>Alfresco - user access</name> <description>Access to Alfresco Repository WebScripts that require user authentication</description> <connector-id>alfrescoCookie</connector-id> <endpoint-url>http://localhost:81/alfresco/wcs</endpoint-url> <identity>user</identity> <external-auth>true</external-auth> </endpoint>
C’est à vous de créer le connector, par contre il suffit juste d’éditer le endpoint qui a pour id alfresco.
Se connecter via CIFS à Alfresco
Comme les instances de nos subsytems sont bien configurées, il ne reste plus qu’à se connecter au content repository de la même façon qu’à un disque réseau, sous Windows dans Run (Executer) :
\\<nomdupc>a\
Sans les chevrons, il faut juste ajouter a à la fin du nom de l’ordinateur, la même chose pour un noyau Unix (Mac OS, Linux):
smb://<nomdupc>a
Conclusion
Les utilisateurs n’ont plus qu’à ouvrir une session Windows sur leur poste pour être identifiés, de même ils peuvent accéder sans problème au content repository via CIFS (à condition d’avoir les bonnes autorisations ;) ).
Kizux