Sécurité Alfresco : comment configurer le contrôle des accès ?

Votre Alfresco est pénétré par des personnes externes à l’entreprise qui ont accès à votre propriété intellectuelle. Un cauchemar dont vous vous réveillez en sueurs ? Le scénario du dernier film d’espionnage faisant triompher Bruce Willis ?

Pas nécessairement mais c’est un sujet fréquent d’interrogations. En effet, il existe une fonctionnalité permettant à un gestionnaire de site d’inviter un utilisateur jusque là inexistant dans Alfresco. Si cette possibilité est intéressante pour une plate-forme ouverte–dans le cas d’un projet regroupant des équipes hétérogènes–dans un environnement d’entreprise on préfère contrôler l’accès à l’application en gérant les comptes dans un annuaire LDAP. Une telle fonctionnalité constitue alors une faille de sécurité dans le système, d’où l’importance de bien configurer Alfresco en fonction de vos besoins.

Configuration par défaut

Dans l’onglet « Membres » d’un site Share, le bouton « Inviter des personnes » nous envoie vers un formulaire permettant de rechercher un utilisateur (ou un groupe) pour l’inviter sur le site. En dessous de cette interface, une boite permet de saisir le nom et prénom d’un utilisateur, ainsi que son adresse e-mail. En cliquant sur « Inviter » un compte sera créé dans Alfresco et un mail sera envoyé aux utilisateurs.

Modifier la configuration

Selon la documentation officielle1 : « Cette fonctionnalité est désactivée si l’installation de votre application ne permet pas la création de nouveaux utilisateurs2 ». Si cela ne vous paraît pas très explicite, précisons que l’authentification d’un utilisateur depuis la base interne d’Alfresco–c’est à dire ne provenant pas d’une base LDAP–doit être désactivée pour que cette fonctionnalité cesse d’être accessible. Techniquement cela correspond à désactiver le sous-système d’authentification « alfrescoNtlm » dans votre fichier de configuration alfresco-global.properties, puis à le remplacer par une authentification LDAP.

Par exemple :

authentication.chain=passthru1:passthru,ldap1:ldap,alfrescoNtlm1:alfrescoNtlm

devient :

authentication.chain=passthru1:passthru,ldap1:ldap

En savoir plus

1 http://docs.alfresco.com/4.0/index.jsp?topic=%2Fcom.alfresco.enterprise.doc%2Ftasks%2Fmembers-invite.html

2 This feature is disabled if your installation of the application does not support the creation of new users.

Vous avez besoin d’aide pour configurer correctement votre Alfresco ? N’hésitez-pas à nous contacter.

Alfresco : audit de performances d’Explorer vs Share

Alfresco Share, étant plus récent qu’Alfresco Explorer, bénéficie de nouvelles améliorations et c’est bien normal. Mais au delà des nouveautés fonctionnelles, qu’en est-il des performances ? C’est ce que StarXpert a cherché à savoir en effectuant un audit des deux interfaces.

StarXpert a donc mis face à face Alfresco Explorer, l’interface développée en JSF, et Alfresco Share, l’interface développée avec le nouveau framework Spring Surf. StarXpert a utilisé JMeter pour stresser l’application, et a étudié le comportement de la machine pendant les phases de tests grâce à des outils développés en interne.

Méthodologie

La version installée est Alfresco Enterprise 3.4. Un script JMeter a été développé pour stresser l’interface Explorer. Puis, un script équivalent a été développé pour l’interface Share. Ces scripts sont simples : Ils se contentent de parcourir une dizaine d’espaces contenant entre 4 et 866 fichiers pdf (pour un total de 2 319 fichiers). Le scénario est le suivant :

  1. L’utilisateur s’authentifie
  2. Il accède à l’espace racine d’Alfresco (My Alfresco ou Repository)
  3. Il accède à l’espace de test racine, contenant les 10 espaces de tests.
  4. Il rentre dans un espace de test et liste les fichiers.

Les étapes 3 et 4 sont répétées en boucle jusqu’à la fin du test. Le script changeant d’espace à chaque itération, au total 1000 itérations sont effectuées pour chaque test.

Le test a été lancé successivement avec 5, 10, 15, 20, 25, 30, 35, 40, 45 et 50 threads simultanés. Il faut préciser qu’un thread ne correspond pas à un utilisateur réel. On peut considérer qu’un thread impact le serveur de la même façon que 5 à 10 utilisateurs travaillant simultanément.

Le serveur utilisé pour ce test est un serveur virtualisé sur vmware avec 2 cpu et 4Go de RAM, application sur Tomcat et MySQL.

Résultat

Les deux graphiques ci-dessous présentent une synthèse des résultats pour les deux interfaces.

Les barres représentent le temps de réponse moyen d’une page en millisecondes. Le premier trait pointillé correspond à 1 seconde, le premier trait plein correspond à 2 secondes.

Les lignes représentent le débit moyen en pages par minutes. L’échelle utilisée ici est exponentielle, en moyenne le débit est compris entre 300 et 1100 pages par minutes.

On constate que l’interface Explorer s’effondre lorsque la charge est trop importante (>35 threads) alors que l’interface Share encaisse la charge de façon linéaire.

On peut voir aussi que le débit maximal de la machine (~1k pages/minutes) est atteint avec 15 threads, soit 75 à 150 utilisateurs. Au dessus de ce seuil, les performances vont naturellement se dégrader.

Cependant, le point le plus important de l’étude est de constater qu’après les tests de charge, le système se rétablit parfaitement si on utilise l’interface Share, ce qui n’est pas le cas pour l’interface Explorer. Un redémarrage de l’environnement Tomcat devient indispensable !

Ceci s’explique en regardant l’évolution de la mémoire JAVA. La région Old Generation de la pile mémoire se remplit progressivement au cours des tests, jusqu’à atteindre le seuil maximal. Ceci provoque un déclenchement disproportionné du Garbage Collector et impact très fortement les performances.

En utilisant l’interface Share, ce phénomène ne se rencontre pas.

Conclusion

Cette étude nous montre que l’interface Share gère mieux la mémoire Java que l’interface Explorer. Elle peut donc plus facilement subir un pic d’activité sans compromettre la stabilité de l’application. On peut conclure également que l’usage d’outils de stress et de supervision (tels que ceux développés par StarXpert) est necessaire pour mieux calibrer et optimiser les serveurs Alfresco.

 

Personnaliser Alfresco c’est facile

Nos clients nous demandent souvent des petites fonctionnalités supplémentaires pour personnaliser leur Alfresco. L’exemple suivant montre à quel point c’est facile.

Un de nos clients souhaitait permettre à ses utilisateurs de visualiser les membres d’un groupe avant d’inviter le groupe à rejoindre un espace. Pour cela nous avons développé un webscript, puis inséré dans l’interface d’Alfresco un script en Ajax permettant d’appeler le webscript. Le développement a été effectué en une journée.

La copie d’écran ci-dessous illustre le fonctionnement.