Paramètres de connexion : GEIDE - SSO - LDAP - SSL

Deuxième onglet des paramètres de connexion : les réglages complémentaires permettent à Kentika de communiquer avec d'autres serveurs afin de s'insérer dans une architecture informatique élargie.

Quatre sections sont réglables ici : GEIDE ; SSO ; LDAP ; SSL

Section GEIDE

Lors du calcul d'une page html, Kentika effectue un nombre important de contrôles et de calculs. Chaque éléments d'information est vérifié avant l'envoi. Lors de l'envoi d'un document archivé, il y a très peu de calcul (en dehors des vérifications) mais les temps de transfert peuvent être longs (si les documents sont volumineux et le débit faible). Afin de délester Kentika de l'envoi des archives, et ainsi libérer de la performance pour les calculs, il est possible de fonctionner avec un deuxième serveur dont la tâche sera limitée à l'envoi des archives.

Lorsque cette option est activée, si un utilisateur demande à visualiser une archive, Kentika vérifie que l'utilisateur a bien le droit de voir l'archive demandée et, si oui, crée une copie de cette archive dans un répertoire temporaire dont le nom est codé (exemple : 191143591932) en lui restituant son nom d'origine (ex : intfrcbref.pdf) et redirige l'utilisateur vers cette archive en utilisant comme nom de serveur et numéro de port ceux qui sont indiquées dans le paramétrage illustré ci-dessus. Cette optimisation peut être déclenchée pour les fichiers d'une certaine taille et les fichiers peuvent être conservés dans le répertoire temporaire pendant un nombre de jours. Kentika se charge de supprimer de ces répertoire les documents qui n'ont pas été accédés depuis le nombre de jours fixés.

Section SSO

Dans le cas où les utilisateurs peuvent être déjà identifiés et où IIS est en mesure de connaître leur identité, ce mécanisme permet à Kentika d'interroger un service afin d'éviter de demander à l'utilisateur de s'identifier à nouveau. Kentika propose plusieurs systèmes de SSO :

• Via un serveur IIS gérant une identification Windows (Kerberos ou NTLM)
• Via le standard SAML
• Via n'importe quel autre système, par exemple en utilisant un système de jetons

Section LDAP

Si un utilisateur n'est pas reconnu par le SSO (Single Sign On) tel que paramétré ci-dessus, ses identifiant et mot de passe lui seront demandés. Ces derniers peuvent être vérifiés dans Kentika et/ou transmis à l'annuaire LDAP pour vérification. Si l'utilisateur existe bien dans LDAP mais pas encore dans Kentika, sa fiche peut être créée automatiquement grâce à une interrogation de l'annuaire.

Section SSL

Kentika (via 4D Server) permet de travailler en mode sécurisé. Le cryptage peut concerner les échanges entre navigateur et serveur web et les échanges entre le client riche et le serveur d'application.

L'interface propose de générer les clés public / privés ainsi que la demande de certificat.

SSL Only

En cochant cette case, seules les liaisons sécurisées entre un navigateur et le serveur web seront autorisées. Si un utilisateur demande à se connecter en mode non sécurisé, il est systématiquement renvoyé vers la page : File://SSLOnly.htm, que vous pouvez personnaliser pour fournir des explications à vos utilisateurs.