Mettre en place un SSO avec le SAML

SAML est un standard de plus en plus répandu permettant de gérer un système de SSO. Depuis la v4, Kentika a développé un ensemble de ressources (inclues dans le kit Atomic) permettant d'utiliser ce standard.

Cette notice n'a pas vocation à expliquer le fonctionnement du SAML, mais bien à expliquer comment le mettre en place dans Kentika.

Pré-requis

SAML se base sur un système à deux agents : Le Service Provider (SP), qui est ici Kentika, et l'Identity Provider (IdP), qui gère l'identification.

Pour mettre en place une connexion SSO via SAML, vous devez donc disposer de la v4 (ou ultérieure) de Kentika, et d'un IdP.

Paramétrage initial

Un écran de paramétrage du SAML est accessible depuis Fichier > Préférences > Paramètres de connexion, onglet "GED - SSO - LDAP" :

Un clic sur l'icône indiquée permet d'ouvrir l'écran de paramétrage du SAML

Cet écran permet de paramétrer les données SP et IDP dans Kentika.

Note : Bien que le SAML soit entièrement fonctionnel, l'écran de paramétrage est encore en développement. Tous les paramètres qui s'y trouvent sont stockés dans les paramètres WsAM (paramètres SP) et WsA1 (paramètres IdP).

L"écran de paramétrage du SAML

Cet écran se découpe en deux parties. À gauche (1), les paramètres liés au SP. Outre les informations classiques liées au SAML se trouvent les options suivantes :

• Sign : Permet de signer les échanges. Dans ce cas, le chemin vers un certificat et une clé privée (formats pem) sur le serveur doivent être indiqués en-dessous.
• Generate : Ce bouton permet de générer un certificat et une clé privée si vous n'en avez pas.
• Create unknown : Permet de générer les comptes à la volée s'ils n'existent pas. (Voir plus bas pour plus d'informations).

Une fois paramétré, vous pouvez générer un fichier de métadonnées XML (3) qui peut traditionnellement être importé dans l'IdP pour déclarer le service Kentika.

À droite (2), les paramètres liés à l'IdP. Si vous avez un fichier de métadonnées XML de l'IdP, vous pouvez tenter d'extraire les informations avec le bouton 4. Sinon, vous pouvez renseigner les informations manuellement. Cet partie comprend également l'option suivante :

• User ID : Permet de définir un champ de la réponse SAML (dans la partie "AttributeStatement") à utiliser comme identifiant, au lieu de la valeur de la balise NameID.

Une fois cet écran paramétré et Kentika déclaré auprès de l'IdP, votre SSO devrait être fonctionnel !

Côté Kentika, on cherche l'identifiant dans le champ générique "Identifiant" (34) ou l'adresse email dans le champ générique "Adresse email" (284). Sauf si une rubirque de la fiche personne existe et a pour code "SAML_ID", auquel cas on se base sur cette rubrique.

Activer les jetons Kentika

Lorsque Kentika a identifié l'utilisateur, il redirige vers la page initialement demandée par l'utilisateur avec un jeton pour l'identifier. Pour que le système fonctionne correctement, il est impératif de bien activer les jetons, à l'aide des paramètres W_CT et W_TO (disponibles dans l'onglet "Atomic_special").

• W_CT doit avoir la valeur 1.
• W_TO doit avoir une valeur supérieure à 0. Si le paramètre est déjà supérieur à 0, il vaut mieux le laisser tel quel. S'il n'est pas défini, 2 permet d'assurer le fonctionnement du SSO SAML.

Tester le SSO

Vous pouvez tester facilement les réglages de votre SSO, même en production, sans gêner vos utilisateurs. Tant que vous n'avez pas mis de redirection automatique (voir le chapitre suivant), ces réglages ne font rien.

Pour tester, rendez-vous sur votre portail, sur la page SSO_SAML_Login.htm (en prenant osin de vous déconnecter du portail auparavant). Celle-ci redirige vers l'IdP, et, si tout fonctionne, devrait vous rediriger éventuellement sur votre portail Kentika, correctement identifié.

Redirection automatique ou non ?

Une fois votre SSO testé et fonctionnel, vous avez deux options pour le rendre disponible :

• La redirection automatique : Lorsque Kentika détecte un utilisateur arrivant sur le portail (sur n'importe quelle page) sans être identifié, il le redirigera vers l'IdP pour identification. Pour mettre cette solution en place, il faut activer le composant topGeneric_SSO_redirect, dans la zone topGeneric_Head.
• La redirection manuelle : Si vous ne désirez pas forcer tous vos utilisateurs à se connecter via le SSO (parce-que vous autorisez les invités, par exemple, ou que certains de vos utilisateurs ne sont pas gérés par votre IdP), vous avez l'option d'afficher un bouton "Me Reconnaître" sur l'écran d'identification. Ce bouton est géré par le composant ConnectGoSSO de la zone Connect_Form_Form (ce composant est actif par défaut si vous n'avez pas sélectionné d'autres composants).

Note : Ces deux méthodes sont communes que vous utilisez le SSO IIS ou le SSO SAML, et utilisent les même composants. Kentika détecte quel paramétrage vous utilisez pour rediriger les utilisateurs correctement en fonction de votre paramétrage.

Créer les utilisateurs inconnus

Par défaut, Kentika fait le lien entre les identifiants renvoyés par l'IdP et les identifiants dans sa propre base de données pour reconnaître l'utilisateur. S'il ne trouve pas de fiche correspondante, soit il refuse la connexion, soit il peut créer l'utilisateur avec les données renvoyées par l'IdP.

Pour cela, il faut que la case "Create unknown" soit cochée dans les paramètres SAML, et il faut paramétrer un filtre d'import. Ce dernier doit forcément avoir le code "SAML" pour être reconnu.

Kentika génère un fichier à partir des informations issues du SAML, et importe ensuite ce fichier à l'aide du filtre défini. Les informations récupérées sont l'identifiant ou l'adresse email (en fonction de ce qui est utilisé comme identifiant par l'IdP), ainsi que toutes les données de la section "AttributeStatement".

Il est possible de générer un exemple de fichier en modifiant le paramètre "createFilter" du paramètre WSAM. Ce paramètre correspond à la case "Create unknown", et a la valeur "1" si la case est cochée. En lui attribuant la valeur "$$test$$", puis en générant une connexion SAML (en provoquant une identification - échouée puisque l'utilisateur ne doit pas exister), Kentika génère le fichier à importer et le place sur le serveur dans le dossier temporaire, dans /Temp/SAMLImport/. 

Il est donc possible de récupérer ce fichier pour voir les informations renvoyées par l'IdP et générer le filtre d'import.

Note : Lorsque Kentika est paramétré pour créer ainsi les nouveaux utilisateurs, il met également à jour les utilisateurs existants lorsqu'ils se connectent via SAML, avec le même principe. Il est donc important de définir une clé de dédoublonnage dans le filtre d'import.

Attention : Il est important de penser à repasser le paramètre "createFilter" de WsAM à "1" une fois que le filtre d'import est au point. Sinon, des fichiers texte seront générés sur le serveur à chaque connexion. Cela prend (un peu) de place sur le disque, mais surtout vous avez des fichiers en clair sur le serveur avec des informations personnelles. (En plus, l'import ne se fait pas tant que "createFilter" a pour valeur "$$test$$".

Paramètres avancés

Il existe plusieurs paramètres avancés qui permettent de gérer des cas particuliers et qui ne sont pas intégrés dans l'interface.

Cette section liste et explique ces paramètres. Elle est plus technique et suppose que vous maîtrisez bien l'outil Kentika.

• WSA1 > userIDFieldFallback : Comme expliqué plus haut, Kentika permet d'utiliser un champ "identifiant" autre que le champ "NameID" de la réponse SAML. Le paramètre userIDFieldFallback, lorsqu'il est paramétré à 1, permet d'utiliser le champ "NameID" si le champ paramétré dans Kentika n'est pas trouvé. Sinon, Kentika refuse l'authentification.
• Script SAML_errorMessage : Ce script permet de personnaliser le message d'erreur renvoyé en cas d'échec d'authentification. Ce script est appelé en fin du script SAML, et peut utiliser un certain nombre de données récupérées lors de l'exécution du script. (Il permet par exemple d'utiliser un message d'erreur récupéré dans la réponse SAML si l'authentification est refusée.)
• Script principal : Le fonctionnement global du SAML passe par l'exécution du script AScript_SAML, appelé par la page SSO_SAML_Redirect.htm. En cas de besoin qui ne peut être couvert par les cas prévus, il est possible de dériver la page pour la faire appeler un autre script. Attention, dans ce cas, les améliorations et correctifs futurs ne s'appliqueront évidemment pas aux ressources dérivées.