IAM souverain FerrisKey (SSO OIDC)

Centraliser l'authentification de toute une organisation est confortable : un seul identifiant ouvre tous les services. Mais ce point de passage devient aussi le plus sensible de votre système d'information. Chaque connexion, chaque identité, chaque groupe y transite. Le confier à Okta, Auth0 ou Entra ID, c'est déposer cet annuaire d'identités sur une infrastructure soumise au droit américain.

France Nuage opère à la place FerrisKey, un gestionnaire d'identités et d'accès (IAM) open source écrit en Rust et publié sous licence Apache-2.0, hébergé en France. Vos identités restent sur le continent, et le service reste ré-internalisable : le logiciel comme les données peuvent repartir sur votre propre infrastructure.

Accès : un serveur FerrisKey dédié à votre projet, par exemple managed-votreslug-ferriskey-votreprojet.apps.france-nuage.fr.

Ce que fait un IAM

Un IAM (Identity and Access Management) est l'annuaire central qui répond à deux questions pour toutes vos applications : qui êtes-vous ? (authentification) et à quoi avez-vous droit ? (autorisation). Au lieu que chaque logiciel gère ses propres comptes et mots de passe, ils délèguent tous cette responsabilité à FerrisKey.

Concrètement, FerrisKey fournit :

• Un SSO (Single Sign-On) OIDC : l'utilisateur se connecte une fois, puis accède à tous les services raccordés sans ressaisir ses identifiants.
• Des realms multi-organisations : chaque organisation (ou entité, ou client) dispose de son propre espace isolé, avec ses utilisateurs, ses groupes et ses règles.
• Le brokering d'identité : FerrisKey peut déléguer l'authentification à un autre fournisseur d'identité, ce qui permet la fédération décrite plus bas.
• Une interface d'administration en self-service : créer un realm, déclarer une application (client OIDC), gérer les utilisateurs et les rôles, sans passer par un ticket.

Compatible OIDC avec Keycloak

FerrisKey expose les mêmes URLs OpenID Connect que Keycloak. Le document de découverte se trouve à l'emplacement standard :

https://managed-votreslug-ferriskey-votreprojet.apps.france-nuage.fr/realms/<votre-realm>/.well-known/openid-configuration

et les points de terminaison suivent la même convention /realms/<votre-realm>/... (autorisation, token, userinfo, JWKS). Conséquence pratique : une application déjà configurée pour Keycloak se raccorde à FerrisKey en changeant simplement l'URL de l'émetteur (issuer). Toute bibliothèque cliente OIDC standard (côté application) fonctionne sans adaptation.

Fédération hub-and-spoke

Le service managé repose sur une fédération hub-and-spoke. France Nuage opère un FerrisKey central (le hub) qui délègue l'authentification, par brokering, vers un FerrisKey dédié à votre organisation (le spoke). Chaque organisation garde son propre realm, ses utilisateurs et ses règles.

L'intérêt : vos applications ne parlent qu'à votre FerrisKey, et cet espace vous appartient. Vous pouvez à tout moment en exporter la configuration et les utilisateurs pour le ré-internaliser sur votre propre infrastructure.

Protéger un site derrière l'arête zero-trust

Les services managés sont exposés derrière l'arête zero-trust de France Nuage, construite sur le logiciel open source Pangolin. Chaque société cliente y dispose de sa propre organisation, et cette organisation s'appuie sur l'IAM de la société.

Une organisation, l'IAM de sa société

Une fois l'IAM de votre société déclaré (FerrisKey en OIDC, un realm par société, par exemple https://auth.votre-domaine.fr/realms/votre-societe), l'arête l'utilise comme fournisseur d'identité de votre organisation. Vos utilisateurs n'ont pas de compte local sur l'arête, et vous n'avez rien à régler dans l'interface de Pangolin.

Une annotation sur l'Ingress

Un site devient protégé quand son Ingress porte l'annotation zero-trust.france-nuage.fr/sso: "true" :

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mon-application
  annotations:
    zero-trust.france-nuage.fr/sso: "true"

Un visiteur qui n'est pas connecté est alors redirigé directement vers l'IAM de l'organisation propriétaire du site, sans écran de connexion intermédiaire.

Un site sans annotation garde son comportement : s'il est public, il le reste. Et l'automatisation ne fait que protéger, elle n'ouvre jamais un site déjà protégé.

Exempter les chemins d'une API

La mire de connexion ne sert qu'à un navigateur. Un script, un agent ou une sonde de disponibilité qui appelle votre API avec une clé ne peut pas s'y connecter. Si votre application authentifie elle-même ces routes, déclarez-les sur le même Ingress avec l'annotation zero-trust.france-nuage.fr/sso-bypass-paths. L'arête les laisse alors passer sans session, et le reste du site demande toujours la connexion.

metadata:
  annotations:
    zero-trust.france-nuage.fr/sso: "true"
    zero-trust.france-nuage.fr/sso-bypass-paths: "/api/*"

• Motifs : liste séparée par des virgules. Un segment * couvre zéro, un ou plusieurs segments. /api/* couvre donc /api et tout ce qui est dessous, mais pas /apix. Un * placé dans un segment couvre n'importe quels caractères de ce segment.
• Bornes : 10 motifs au plus par site (les Ingress d'un même site s'additionnent) et 200 caractères au plus par motif. Entre les /, seuls les caractères A-Z a-z 0-9 . _ ~ * - sont permis. Les segments . et .. sont refusés, tout comme un motif fait seulement de *, car /* exempterait le site entier.
• Normalisation : l'arête décode et résout le chemin avant de le comparer. Elle traite ainsi /api/../admin comme /admin, qui n'est pas exempté. Cette normalisation ne remplace pas le contrôle d'accès de votre application.
• Annotation invalide : le site reste dans son état précédent, et les autres sites ne sont pas touchés.
• Ordre : les exemptions sont posées avant la protection, pour que le passage d'un site sous SSO ne coupe pas ses chemins exemptés.
• Sans sso : l'annotation est ignorée. Retirer sso fige le site tel qu'il est, exemptions comprises.

Un chemin exempté est servi tel quel par l'arête. C'est votre application qui doit refuser une requête sans clé valide, donc n'exemptez que des routes qu'elle authentifie elle-même.

Ne verrouillez pas l'hôte de votre IAM

L'IAM ne peut pas se protéger avec sa propre mire

Poser sso sur l'hôte de FerrisKey lui-même, sans exempter son trajet de connexion, ferme l'accès à tout le monde.

L'arête renvoie un visiteur non connecté vers l'IAM de l'organisation. Si le site protégé est cet IAM, la redirection mène à une page elle-même protégée : pour atteindre la page de connexion, il faudrait déjà être connecté. Plus personne n'entre, ni vos utilisateurs, ni vos applications, ni vos administrateurs, puisque la console de FerrisKey est derrière la même protection.

Les autres erreurs décrites plus haut se rattrapent. Celle-ci non : se reconnecter ne sert à rien, et retirer sso ne rouvre pas l'hôte, puisque l'automatisation ne rouvre jamais un site déjà protégé. Il ne reste qu'à compléter l'exemption sur l'Ingress, et encore faut-il que votre accès au cluster ne passe pas lui-même par cet IAM.

Vous avez deux options.

1. Ne pas annoter l'hôte de votre IAM. C'est le choix par défaut, et le bon dans la plupart des cas. FerrisKey authentifie déjà ses utilisateurs lui-même. Le placer derrière une protection qui dépend de lui n'ajoute rien.

2. Le passer quand même sous l'arête, en exemptant son trajet de connexion. FerrisKey sert ce trajet depuis deux composants : l'API, qui porte l'émetteur OIDC (/realms/<votre-realm>/…), et l'application web, qui affiche la page de connexion sous /realms/<votre-realm>/authentication/… et charge ses ressources à la racine. Pour FerrisKey 0.9.0, le trajet complet tient en ces dix motifs :

Motif	Composant	Rôle
/realms/<votre-realm>/protocol/openid-connect/*	API	autorisation, jetons, clés publiques de signature, déconnexion
/realms/<votre-realm>/.well-known/*	API	découverte OIDC lue par vos applications
/realms/<votre-realm>/login-settings	API	réglages affichés sur la page de connexion
/realms/<votre-realm>/login-actions/*	API	mot de passe, code à usage unique, clé d'accès, réinitialisation
/realms/<votre-realm>/portal/active	API	thème de la page de connexion
/config	API	configuration publique lue par l'application web
/realms/<votre-realm>/authentication/*	application web	pages de connexion, de vérification et de retour
/assets/*	application web	scripts et feuilles de style
/config.json	application web	adresse de l'API
/logo_ferriskey.png	application web	logo de la page de connexion

Remplacez <votre-realm> par le nom de votre realm. Si votre API est publiée sous un préfixe (le chart Helm de FerrisKey la sert par défaut sous /api), ajoutez ce préfixe aux motifs de l'API. Cette liste vient des routes de FerrisKey 0.9.0 : reprenez-la à chaque montée de version, car une route oubliée donne une page de connexion à moitié servie, donc inutilisable.

metadata:
  annotations:
    zero-trust.france-nuage.fr/sso: "true"
    zero-trust.france-nuage.fr/sso-bypass-paths: >-
      /realms/votre-realm/protocol/openid-connect/*,/realms/votre-realm/.well-known/*,/realms/votre-realm/login-settings,/realms/votre-realm/login-actions/*,/realms/votre-realm/portal/active,/config,/realms/votre-realm/authentication/*,/assets/*,/config.json,/logo_ferriskey.png

Trois règles, qui ne sont pas des précautions de confort ici :

• Comptez avant de poser l'annotation. Ce trajet occupe à lui seul les 10 motifs permis par site. Si l'API et l'application web partagent un hôte, la liste entière s'impute sur ce seul site, et il ne reste aucune place pour un autre chemin, par exemple /realms/<votre-realm>/broker/* si vous fédérez un fournisseur d'identité externe. Un onzième motif rend l'annotation invalide, et l'hôte reste dans son état précédent. Mieux vaut le savoir avant que découvrir le refus après.
• L'exemption d'abord, la protection ensuite. Vérifiez la liste avant de poser sso, puis posez les deux annotations dans la même modification, jamais sso seule en premier. Pour un IAM, cet ordre décide si l'erreur se corrige ou si elle vous enferme dehors.
• Testez depuis une adresse sans passe-droit. Ouvrez une fenêtre de navigation privée, sur un réseau qui ne bénéficie d'aucune exception d'accès, et menez une connexion complète. Vérifiez aussi qu'une de vos applications obtient toujours ses jetons. Un test lancé depuis une session déjà ouverte, ou depuis un réseau autorisé d'office, réussit pour de mauvaises raisons et ne prouve rien.

L'avertissement donné pour les API vaut aussi ici : l'arête sert un chemin exempté tel quel, c'est donc à FerrisKey de refuser ce qui doit l'être. Pour un IAM, c'est précisément son métier, et c'est ce qui rend cette exemption acceptable.

Qui peut entrer

Toute personne qui a un compte dans le realm de votre société est ajoutée automatiquement à votre organisation, et à elle seule, avec le rôle membre, dès sa première connexion. Vous n'avez rien à faire de votre côté. On ne crée ni n'invite aucun utilisateur sur l'arête, et la protection d'un site se décide uniquement par l'annotation de son Ingress.

L'arête laisse donc passer tout compte du realm. Si votre realm contient aussi des comptes de clients ou de partenaires, n'annotez qu'une application qui vérifie elle-même les droits, par exemple en exigeant un rôle de l'IAM, comme le fait Paperclip. La création et la suppression des comptes du realm, comme la politique d'accès de votre application, restent sous votre responsabilité.

Pour donner accès à quelqu'un, créez son compte dans l'IAM de sa société, jamais dans celui d'une autre.

Comparatif

Critère	France Nuage (FerrisKey managé)	Okta / Auth0 / Entra ID (SaaS)	Auto-hébergement
Hébergement de l'annuaire d'identités	En France	Aux États-Unis	Selon vous
Droit applicable aux identités	Droit français	Soumis au droit américain	Selon vous
Protocole	OpenID Connect (compatible Keycloak)	Propriétaire + standards	Selon vous
Réversibilité	Open source (Apache-2.0), ré-internalisable	SaaS propriétaire	Total
Coût	Forfait au mois, utilisateurs inclus	Souvent à l'utilisateur actif	À votre charge
Mises à jour & disponibilité	Gérées	Gérées	À votre charge

Bien démarrer

1. Recevez votre realm : France Nuage vous provisionne un realm dédié sur votre serveur FerrisKey.
2. Déclarez vos applications : dans l'interface d'administration, créez un client OIDC par application à raccorder (URL de redirection, type de client).
3. Configurez chaque application : pointez la configuration OIDC de l'application vers l'URL de découverte de votre realm (ci-dessus). La plupart des frameworks ne demandent que l'URL de l'émetteur, l'identifiant du client et son secret.
4. Créez vos utilisateurs et vos groupes, ou raccordez un fournisseur d'identité existant par brokering.

Le tutoriel Première connexion détaille la mise en route d'un premier service sur France Nuage, et la page Authentification décrit le rôle de l'IAM dans la plateforme.

Cas d'usage

• Unifier l'accès à vos services managés : un seul identifiant pour vos outils raccordés en OIDC (Grafana, Metabase, et tout logiciel compatible).
• Cloisonner plusieurs entités : une filiale, un client ou une équipe par realm, isolés les uns des autres.
• Reprendre la main sur un annuaire soumis au droit américain : migrer depuis Okta, Auth0 ou Entra ID vers un IAM hébergé en France.

Limitations actuelles

FerrisKey est un projet jeune et l'offre managée est volontairement transparente sur son périmètre. À ce stade :

• OIDC uniquement : FerrisKey prend en charge OpenID Connect. SAML et LDAP ne sont pas supportés. Une application qui ne sait s'authentifier qu'en SAML, ou un service qui interroge directement un annuaire LDAP, ne peut pas encore passer par FerrisKey.
• Déconnexion par service : la déconnexion unique en canal arrière (single-logout back-channel) n'est pas encore propagée à l'ensemble des applications raccordées. Concrètement, la déconnexion se fait aujourd'hui service par service ; une session ouverte sur une autre application peut rester active jusqu'à son expiration.

Ces points font partie de la feuille de route. Si votre besoin en dépend, indiquez-le avant de démarrer : nous vous dirons où en est le support et cadrerons la mise en œuvre avec vous.

Réversibilité

Tout est open source. Vous pourriez faire tourner FerrisKey vous-même : c'est précisément ce que permet une licence Apache-2.0. France Nuage l'exploite à votre place (mises à jour, disponibilité, sauvegardes) sans vous enfermer. La configuration de vos realms et vos utilisateurs s'exportent, et vous gardez le droit de tout reprendre sur votre propre matériel le jour où vous le décidez. Vous ne troquez pas un verrouillage américain contre un verrouillage européen.

Références

• Dépôt FerrisKey pour aller plus loin sur le projet
• Spécification OpenID Connect sur le protocole d'authentification
• Authentification pour comprendre le rôle de l'IAM dans la plateforme France Nuage

---

Okta est une marque d'Okta, Inc. Auth0 est une marque d'Okta, Inc. Microsoft Entra ID est une marque de Microsoft Corporation. Keycloak est une marque de Red Hat, Inc. Rust est une marque de la Rust Foundation. France Nuage n'est ni affilié à ces sociétés ni cautionné par elles ; ces noms sont employés à titre descriptif, pour désigner les technologies mises en œuvre ou comparées.