Reverse proxy Alfresco Community : Nginx, HTTPS, en-têtes et AOS sans casse

Un reverse proxy Alfresco doit transmettre correctement le protocole, l’hôte, le port et les chemins externes. Une erreur sur ces éléments peut laisser Share accessible tout en cassant AOS, WebDAV, les redirections ou les liens envoyés par e-mail.

La documentation officielle Alfresco Community confirme deux points utiles. D’abord, en production, il vaut mieux utiliser un proxy pour gérer le SSL plutôt que bricoler l’application serveur. Ensuite, le proxy ne doit pas tout exposer : il faut relayer uniquement les chemins nécessaires et bloquer certains endpoints sensibles. C’est ce cadrage qui fait la différence entre une mise en ligne rapide mais fragile, et une plate-forme exploitable sur la duree.

Si vous avez déjà déployé la pile technique en suivant notre guide Installer Alfresco Community avec Docker Compose ou si vous preparez un déploiement Alfresco plus large, le reverse proxy est le point ou se rencontrent sécurité, ergonomie et interconnexion. C’est aussi un sujet a cadrer en même temps que le SSO avec Keycloak, car les deux dependent fortement des URLs externes et des bons en-tetes.

1. Pourquoi un reverse proxy est presque toujours nécessaire

Dans un environnement de production, vous avez rarement envie d’exposer Tomcat directement sur Internet. Le reverse proxy ajoute une couche de contrôle simple mais decisive : terminaison TLS, filtrage des chemins, journalisation, limitation d’accès, redirections propres et homogeneisation des URLs. Il permet aussi d’utiliser un nom de domaine clair, un certificat standard et des règles plus lisibles pour l’exploitation.

Sur Alfresco Community, ce sujet est encore plus important parce que plusieurs usages passent par des URLs générées ou relayees par la plate-forme : Share, API publiques, CMIS, WebDAV, parfois Alfresco Office Services (AOS). Si Alfresco croit qu’il sert du HTTP sur le port 8080 alors que l’utilisateur entre par un proxy HTTPS en 443, il peut produire des liens incohérents. Les utilisateurs voient alors des ressources mixtes, des retours en HTTP, ou des intégrations qui paraissent aleatoires alors que la racine du problème est structurelle.

2. Les symptômes qui indiquent un proxy mal cadre

Certains signaux reviennent très souvent sur les environnements Alfresco Community exposes trop vite :

• des liens ou redirections en HTTP alors que le site public est en HTTPS ;
• des erreurs de connexion ou d’ouverture de document dans Microsoft Office via AOS ;
• des accès WebDAV qui fonctionnent en interne mais pas depuis l’extérieur ;
• des appels API ou CMIS accessibles, mais avec des URLs externes incorrectes ;
• des endpoints internes exposes inutilement, notamment autour de Solr et de certains proxys Share.

Quand ces symptômes apparaissent, il faut resister à la tentation de corriger uniquement le navigateur, le certificat, ou un client Office. Le bon reflexe consiste a vérifier l’alignement entre l’URL publique, les règles du proxy, et les propriétés Alfresco qui definissent le host, le port, le protocole et les contextes.

3. Ce que le proxy doit exposer, et ce qu’il doit bloquer

La documentation officielle recommande une logique de liste blanche. En clair, le proxy ne doit transmettre que les chemins utiles au front, aux API publiques et aux protocoles réellement utilises. Pour un usage standard, cela couvre notamment Share, certaines URLs de l’API publique Alfresco, les chemins CMIS et l’endpoint serveur. Si vous utilisez WebDAV, il faut explicitement relayer ses chemins. Si vous utilisez Alfresco Office Services, il faut egalement autoriser les chemins AOS et les méthodes associees.

L’interet de cette approche est double. D’une part, elle reduit la surface d’exposition. D’autre part, elle rend l’infrastructure beaucoup plus lisible : on sait ce qui doit être accessible et ce qui ne doit jamais sortir. La même documentation recommande aussi de bloquer explicitement certains chemins relies au proxy Share vers l’API Alfresco et a Solr. C’est un détail qu’on saute souvent lors d’un démarrage rapide, puis qu’on paie plus tard sous forme de surface d’attaque inutile ou de comportement non maîtrise.

Ce principe rejoint d’ailleurs nos recommandations sur les habilitations Alfresco Community : on sécurisé mieux un système quand on expose moins, quand on nomme clairement les usages legitimes et quand on refuse le « tout ouvert au cas ou ».

4. Les propriétés Alfresco a aligner avec l’URL externe

Le reverse proxy ne suffit pas a lui seul. Si l’URL externe est en https://ged.exemple.fr, Alfresco et Share doivent aussi être configures pour générer cette même logique de liens. En pratique, cela veut dire vérifier dans alfresco-global.properties les valeurs du contexte, du host, du port et du protocole pour le repository et pour Share.

Le point clé est simple : même si le proxy parle en HTTPS vers le client et en HTTP vers Tomcat, les applications doivent savoir que l’URL publique de référence est bien en HTTPS sur le port 443. Sans cela, des liens internes peuvent être calcules avec le mauvais schéma. Ce decalage explique une grande partie des comportements incohérents observes après mise en ligne.

Dans un projet ou l’on veut aussi ouvrir des intégrations comme CMIS ou WebDAV, cette cohérence est non negociable. Une API qui répond n’est pas necessairement une API correctement exposee. Il faut vérifier les liens retournes, les redirections et les URLs communiquees aux clients.

5. Le cas particulier d’Alfresco Office Services et des en-tetes de proxy

AOS est l’un des meilleurs revelateurs d’un proxy mal cadre. Quand l’edition Office casse, beaucoup d’équipes pensent à une incompatibilite applicative alors qu’il s’agit souvent d’un problème d’URL externe, de redirection ou de prise en charge partielle des chemins nécessaires. La documentation Alfresco demande d’ajouter les endpoints AOS dédiés, ainsi que certaines méthodes comme OPTIONS et PROPFIND. Elle mentionne aussi, hors Apache AJP, le besoin de définir une URL AOS ecrasee côté Alfresco et de corriger les redirections du serveur applicatif.

En pratique, cela veut dire qu’un proxy Nginx propre ne se limite pas à un proxy_pass. Il doit relayer les bons chemins, respecter les en-tetes attendus, gérer correctement les retours HTTP vers HTTPS, et laisser passer les usages qui ne ressemblent pas à une simple navigation web. AOS et WebDAV demandent justement ce niveau de rigueur.

6. Une méthode simple pour valider la configuration avant production

Avant d’ouvrir largement l’accès, nous recommandons un enchainement de contrôles très concret :

• ouvrir Share via le nom de domaine public et vérifier qu’aucun lien ne revient en HTTP ;
• tester un appel simple sur l’API publique et contrôler les redirections ;
• tester l’accès WebDAV si ce protocole fait partie du perimetre ;
• tester l’ouverture d’un document Office si AOS est annonce aux utilisateurs ;
• vérifier que les chemins internes non prévus ne sont pas exposes publiquement ;
• rejouer ces tests après toute modification du certificat, du contexte applicatif ou du SSO.

Cette phase de recette évité les corrections de dernière minute juste avant mise en production. Elle permet aussi de distinguer un incident de proxy, un problème de configuration Alfresco et un besoin de parametrage client.

7. Quand faire appel à un integrateur plutôt que corriger au fil de l’eau

Si votre instance Alfresco Community sert déjà des documents critiques, le reverse proxy n’est pas un sujet cosmetique. C’est une brique d’exploitation. Un mauvais cadrage peut perturber l’accès externe, la collaboration Office, les intégrations, la sécurité perimetrique et même l’expérience utilisateur la plus basique.

Un integrateur utile n’intervient pas seulement pour « mettre du HTTPS ». Il vérifie les flux exposes, les contraintes reelles du projet, les protocoles utilises, le comportement du SSO, les besoins WebDAV ou CMIS, et la facon dont les URLs publiques sont générées par Alfresco et Share. Cette approche évité d’accumuler des règles de proxy qui semblent fonctionner individuellement mais qui se contredisent à la moindre évolution.

Chez Rainbow Integration, nous traitons ce sujet comme un point d’architecture a part entière. Si vous avez un doute sur l’exposition externe de votre GED, sur les en-tetes Nginx a poser, sur le comportement AOS ou sur le couple proxy + SSO, nous pouvons auditer l’existant, corriger la configuration et valider une recette d’accès exploitable en production.

Vous pouvez commencer par consulter nos offres Alfresco, télécharger le modèle de cahier des charges GED ou reserver un diagnostic Alfresco pour cadrer votre architecture d’exposition, vos intégrations et vos contraintes de sécurité.

Votre proxy Alfresco est-il cohérent pour tous les usages ? Faire auditer votre configuration Nginx.