Connexion au serveur web : LDAP-SSO

La détermination de l'utilisateur qui arrive sur le site Kentika peut faire appel à des mécanismes plus ou moins sophistiqués. Il convient de bien prendre connaissance de ce qui suit avant d'opter pour un schéma d'identification.

Un utilisateur -> un cookie

Dès qu'un utilisateur accède au site, un cookie lui est envoyé. Ce dernier sert ensuite de moyen d'identification. Si un utilisateur n'est pas reconnu de Kentika, un cookie temporaire lui est envoyé, sinon le cookie contient, de manière codée, son identifiant et la date d'émission. Le cookie est contrôlé à chaque requête.

Les invités sont-ils autorisés ?

Si les invités ne sont pas autorisés à visiter le site et que toute les méthodes d'ientification décrites ci-dessous ont échoué : l'internaute est systématiquement renvoyé vers la page "Connect.htm ", quelle que soit la page demandée. S'il n'existe pas une telle page, l'utilisateur peut voir la page d'accueil (Main.htm ) mais ne pourra exploiter aucun lien.

Invités et espaces

Si globalement les invités ne sont pas autorisés, il n'auront accés à aucun espace même s'il existe un espace autorisé aux invités.

Si les invités sont autorisés, Kentika cherche le premier espace autorisé aux invités (ce qui permet de ne proposer qu'un sous-ensemble de la base aux visiteurs anonymes).

Les liens dans les emails

Depuis la version 1.5 de Kentika, les emails peuvent contenir un jeton d'identification (si le destinataire du email est unique, non applicable dans le cas où un email est adressé à une liste de diffusion).

Exemple d'URL contenant un jeton :

http://192.168.0.xx/M_Record.htm ?record=521712434999&M_Token =470028479446478537469030470029450525447284432741448470

Lorsque l'utilisateur arrive sur la page demandée avec un jeton (paramètre : M_Token), s'il n'est pas encore connu (ie : n'a pas reçu de cookie), Kentika analyse le jeton et si ce dernier est valide (ie : les informations sont correctes et le délai n'est pas expiré, un jour par défaut), l'utilisateur est alors automatiquement renvoyé sur la page Record.htm (versus M_Record.htm qui ne propose que quelques informations et la possibilité de s'identifier) et un cookie lui est adressé, comme s'il s'était identifié. Pour que cette mécanique fonctionne, il est nécessaire d'avoir coché l'option : Token email -> Connect dans les préférences de connexion du serveur web.

Attention : ce système peut engendrer une faille de sécurité. En effet, si un utilisateur transmet son email à un autre utilisateur et que ce dernier clique sur le lien : il arrive sur le site et, s'il n'est pas encore identifié, il sera connecté avec l'identifiant du destinataire d'origine.

SSO : le serveur IIS

Ce qui suit concerne les accès en intranet. Un utilisateur Internet ne peut, a priori, pas être reconnu via IIS.

Lorsqu'un utilisateur arrive sur un site Kentika, le serveur n'a pas moyen de connaître son identité. Par contre, il peut renvoyer vers IIS et si ce dernier le reconnaît il le renverra vers Kentika qui lui fournira alors un jeton d'identification.

 

Plus d'informations sur le paramétrage SSO via Kentika sont disponibles ici.

Dans l'interface web : écran de connexion

Si vous avez coché "SSO" et que que l'adresse du serveur IIS est renseigné, une nouvelle option est proposée dans l'écran d'identification :

Lorsque l'utilisateur clique sur ce lien (http://(votre serveur)/SSO_GoConnect.htm ), Kentika le redirige vers IIS qui le redirige ensuite vers Kentika avec son identité.

Cet ensemble de ressources part du principe que les identifiants Kentika correspondent au nom retourné par IIS. Si ce n'est pas le cas, il sera nécessaire d'apporter une adaptation aux ressources fournies.

Si IIS identifie la personne mais qu'elle n'est pas encore connue de Kentika, si le paramétrage LDAP comporte un paramétrage pour une interrogation unitaire (versus : l'annuaire au complet), Kentika déclenche une requête sur l'annuaire et importe automatiquement sa fiche.

Si vous proposez, au sein d'un intranet global, un lien vers Kentika et que vous souhaitez que la reconnaissance SSO soit effectuée automatiquement, il est suggéré que le lien se fasse sur la page SSO_GoConnect.htm ou bien sur une autre page mais avec le paramètre "?GoSSO=on", exemple : "Main.htm?GoSSO=on "

SSO et les invités

Les deux possibilités peuvent tout à fait cohabiter. En effet, si l'identification SSO échoue, l'utilisateur est alors traité comme un "simple invité" et peux donc visiter le site (si ce dernier est autorisé aux invités). S'il connaît ses identifiant / mot de passe (Kentika ou LDAP, cf : ci-dessous) il peut s'identifier de manière classique.

Interroger l'annuaire LDAP

Ce qui suit n'a pour seul objectif que de vérifier si le couple utilisateur / mot de passe est correct. Il peut être complémentaire du SSO décrit ci-dessus mais n'est pas en lien direct avec la synchronisation LDAP (sauf éventuellement pour la détermination du DN).

Fenêtre de paramétrage de la validation LDAP

Avertissement : Cette fonction utilise un Plugin fourni "en l'état" gracieusement par : http://www.pluggers.nl et est téléchargeable ici : http://www.pluggers.nl/downloads/LDAP_Plugin.zip. Il est proposé de même "en l'état" par Kentika et ne fait pas l'objet d'une maintenance.

LDAP Server

Adresse IP (ou nom de domaine) du serveur LDAP. A priori, identique à celui spécifié si une synchronisation est effectuée.

Le nom complet

Lorsque la demande est formulée à l'annuaire "Le couple personne / mot de passe" est-il correct ? la personne doit être exprimée sous la forme de son nom complet. Cependant, en règle générale, les utilisateurs ne connaissent pas leur nom complet, seulement leur identifiant.

Dans cet exemple : l'utilisateur indiquerait comme identifiant "ADMIN" mais l'interrogation de l'annuaire serait effectuée en utilisant "ou=kentika,uid=admin".

A propos des mots de passe

Lors de la synchronisation de l'annuaire LDAP avec Kentika, les mots de passe ne sont pas intégrés et il est souhaitable que cela reste ainsi (afin d'éviter toute faille de sécurité). C'est pourquoi, le mot de passe Kentika peut être totalement différent de celui de l'annuaire (et parfois fixé complètement arbitrairement).

User mask

Ce paramètre permet d'indiquer comment calculer le nom complet à partir de l'identifiant.

Première méthode : si tous les noms complets sont construits sur le même schéma et que seul l'identifiant change, il suffit alors d'indiquer dans la chaîne saisie un nom complet où seul varierai l'identifiant qui serait alors exprimé sous la forme $ID.

Exemple : en indiquant "uid=$ID,ou=kentika", lors de la construction du nom complet, Kentika remplacerait $ID par l'identifiant à vérifier "uid=ADMIN,ou=kentika"

Deuxième méthode : indiquer le champ contenant le nom complet. Ce dernier est exprimé sous la forme du code de la rubrique et suppose que les correspondances aient été établies a priori dans la base Kentika (via une synchronisation LDAP par exemple).

Description de la rubrique contenant le nom complet (ou DN = Distinguished Name).

Ordre de vérification

Les informations saisies peuvent être vérifiées dans Kentika et/ou dans LDAP et l'ordre peut être précisé. Si, par exemple, vous spécifiez "Kentika ... LDAP" : la vérification id/mot de passe aura lieu d'abord dans Kentika et si les informations sont incorrectes, dans LDAP. Si vous spécifiez "LDAP", les informations seront vérifiées par rapport à LDAP mais pas dans Kentika.

NB : si le mot de passe n'est jamais vérifié dans Kentika, il est conseillé de ne pas proposer aux utilisateurs de modifier leur mot de passe (option : "Ma fiche identité) de même que "mot de passe oublié proposé par défaut sur le formulaire d'identification : ceci pourrait induire l'utilisateur en erreur.

Créer nouveaux utilisateurs

Si une personne est connue de LDAP mais pas dans Kentika, si cette option est cochée, sa fiche sera alors automatiquement créée. Le modèle sera la fiche de l'utilisateur dont l'identifiant est "GUEST", son mot de passe est mis à une valeur numérique aléatoire, aucun centre d'intérêt de lui est assigné.

Zone de test

Afin de faciliter la détermination des paramètres, la partie basse de l'écran est dédiée à des tests d'interrogation : soit avec le DN + mot de passe, soit avec l'identifiant qui sera proposé de saisir par l'utilisateur (la règle de transformation définie dans UserMask sera alors appliquée).