test

Guide du mécanisme d'authentification pour l'entreprise de Sun

Chapitre 1 SEAM - Introduction

Ce chapitre donne un aperçu du produit SEAM.

Qu'est-ce que SEAM ?

SEAM (Sun Enterprise Authentication Mechanism ou mécanisme d'authentification pour l'entreprise de Sun) est une architecture client/serveur assurant l'authentification efficace des utilisateurs, en plus de garantir l'intégrité et la confidentialité des données, préservant ainsi la sécurité des transactions effectuées par l'intermédiaire de réseaux. L'authentification permet de vérifier l'identité de l'expéditeur et du destinataire entre lesquels s'effectue une transaction par réseau ; SEAM peut également vérifier la validité des données acheminées dans les deux sens (l'intégrité) et les chiffrer pendant leur transmission (la confidentialité). Grâce à SEAM, vous pouvez vous connecter à d'autres systèmes, exécuter des commandes, échanger des données et transférer des données en toute sécurité. De plus, SEAM assure les services d'autorisation, permettant ainsi aux administrateurs de limiter l'accès aux services et aux ordinateurs ; qui plus est, les utilisateurs de SEAM peuvent eux aussi réglementer l'accès d'autrui à leur compte.

SEAM est un système de type session à connexion unique, ce qui veut dire que vous ne vous identifiez auprès de SEAM qu'une seule fois par session, après quoi toute autre transaction que vous effectuez pendant la session est automatiquement sécurisée. Dès que SEAM vous a authentifié, vous n'avez plus à vous authentifier lorsque vous exécutez une commande comme ftp ou rsh ou que vous accédez aux données d'un système de fichiers NFS. Cela signifie que vous n'avez pas à transmettre votre mot de passe sur le réseau et risquer qu'il soit intercepté chaque fois que vous utilisez de tels services.

SEAM est basé sur le protocole d'authentification réseau Kerberos V5 développé par le Massachusetts Institute of Technology (MIT). Les habitués de Kerberos V5 ne devraient éprouver aucune difficulté avec SEAM. Étant donné que Kerberos V5 constitue une norme de facto de l'industrie en ce qui concerne la sécurité de réseau, SEAM met en valeur l'interopérabilité avec d'autres systèmes. Autrement dit, puisque SEAM fonctionne avec tout système utilisant Kerberos V5, il assure la sécurité des transactions entre réseaux hétérogènes. Qui plus est, SEAM assure l'authentification et la sécurité entre des domaines et à l'intérieur d'un même domaine.

Remarque :

SEAM étant basé sur Kerberos V5 et conçu pour fonctionner avec ce dernier, le présent manuel utilise presque indifféremment les termes "Kerberos" et "SEAM" -- par exemple, "secteur Kerberos" ou "utilitaire SEAM." (En outre, "Kerberos" et "Kerberos V5" sont également des synonymes.) Ce manuel établit au besoin la distinction entre ces termes.

SEAM assure la souplesse d'exécution des applications Solaris. Vous pouvez configurer SEAM pour qu'il autorise les requêtes SEAM et non SEAM au niveau des services de réseau tels que NFS, telnet et ftp. Le bon fonctionnement des applications Solaris actuelles est ainsi assuré, même lorsqu'elles sont exécutées sur des systèmes où SEAM n'a pas été installé. Bien entendu, vous pouvez également configurer SEAM de façon à ce qu'il ne permette que les requêtes basées sur SEAM.

De surcroît, il n'est pas nécessaire que les applications soient liées exclusivement à SEAM, si d'autres mécanismes de sécurité sont mis au point. SEAM étant conçu pour une intégration modulaire à l'interface GSS-API, les applications se servant de cette interface peuvent opter pour le mécanisme de sécurité répondant le mieux à leurs besoins.

Comment SEAM fonctionne-t-il ?

Voici un aperçu du système d'authentification SEAM. Pour une description plus détaillée, voir "Comment fonctionne le système d'authentification".

Une fois la session SEAM démarrée, SEAM est la plupart du temps invisible aux yeux de l'utilisateur. Quant au fonctionnement des commandes comme rsh ou ftp, il demeure à toute fin pratique inchangé. L'initialisation d'une session SEAM ne consiste guère plus qu'à se connecter et à fournir un mot de passe Kerberos.

Le système SEAM s'articule autour du concept de ticket. Un ticket est un ensemble de renseignements électroniques servant à identifier un utilisateur ou un service, par exemple le service NFS. À l'instar du permis de conduire qui comporte des renseignements sur le détenteur et les classes de véhicule permises, le ticket identifie l'utilisateur et ses privilèges d'accès au réseau. Quand vous effectuez une transaction SEAM -- par exemple lorsque vous vous connectez à un autre ordinateur par l'intermédiaire de rlogin -- vous envoyez de façon transparente une demande de ticket à un centre de distribution de clés, ou KDC, qui accède à une base de données afin d'authentifier votre identité. Le KDC retourne un ticket vous permettant d'accéder à l'autre ordinateur. Le terme "transparence" signifie que vous n'avez pas à formuler explicitement une demande de ticket ; cette demande fait partie de la commande rlogin. Étant donné que seul le client authentifié peut obtenir un ticket pour utiliser un service précis, aucun autre client ne peut se servir de rlogin en se présentant sous une fausse identité.

Certains attributs sont associés au ticket. Par exemple, il peut s'agir d'un transférable (pouvant être utilisé sur un autre ordinateur sans se soumettre à nouveau au processus d'authentification), ou d'un postdaté (non valide avant l'heure et la date indiquée). Les politiques définies au moment de l'installation ou de l'administration de SEAM régissent l'utilisation des tickets, par exemple, les utilisateurs pouvant obtenir certains types de tickets.

Remarque :

Les termes justificatif d'identité et ticket sont repris fréquemment dans le présent manuel. La grande communauté Kerberos emploie ces termes indifféremment. En principe, un justificatif d'identité est composé d'un ticket et d'une clé de session. "Accès à un service avec SEAM" établit clairement la différence entre ces deux termes.

Les sections ci-après décrivent brièvement le processus d'authentification SEAM.

Authentification initiale : le ticket d'octroi de tickets

L'authentification Kerberos s'effectue en deux étapes : l'authentification initiale permettant toutes les authentifications subséquentes, et les authentifications subséquentes elles-mêmes.

Figure 1-1 montre comment se produit l'authentification initiale :

Figure 1-1 Authentification initiale de session SEAM

Graphic

  1. Le client (un utilisateur ou un service comme NFS) ouvre une session SEAM en demandant un ticket d'octroi de tickets (TGT) au centre de distribution de clés. Cela se produit la plupart du temps de façon automatique au moment de la connexion.

    Il est nécessaire de détenir un ticket d'octroi de tickets pour obtenir d'autres tickets donnant droit à d'autres services particuliers. On peut établir une analogie entre le ticket d'octroi de tickets et un passeport. Tout comme un passeport, le ticket d'octroi de tickets vous identifie et vous permet d'obtenir de nombreux "visas" -- ces "visas" (ou tickets) ne sont pas destinés à des pays étrangers, mais plutôt à des ordinateurs distants ou à des services de réseau. À l'instar des passeports et des visas, le ticket d'octroi de tickets et les divers autres tickets ont une durée de vie limitée. La différence réside dans le fait que les commandes "compatibles Kerberos" savent que vous détenez un passeport et qu'elles peuvent obtenir les visas nécessaires à votre place -- c'est-à-dire que vous n'avez pas à effectuer les transactions vous-même.

  2. Le KDC crée un ticket d'octroi de tickets et le retourne sous forme chiffrée au client. Le client le déchiffre alors à l'aide de son mot de passe.

  3. Maintenant qu'il détient un ticket d'octroi de tickets valide, le client peut demander des tickets pour des opérations de réseau de toutes sortes, comme rlogin ou telnet, tant et aussi longtemps que dure le ticket d'octroi de tickets. En règle générale, ce dernier a une durée de vie de quelques heures. Chaque fois que le client effectue une opération de réseau unique, il demande un ticket pour cette opération au KDC.

Authentifications subséquentes

Une fois que le client a reçu l'authentification initiale, chaque authentification individuelle respecte le modèle illustré à la Figure 1-2 :

Figure 1-2 Obtention de l'accès à un service

Graphic

  1. Le client demande un ticket pour un service particulier (par exemple, pour se connecter avec rlogin à un autre ordinateur) au KDC, auquel il envoie son ticket d'octroi de tickets à titre de preuve de son identité.

  2. Le KDC envoie le ticket pour le service particulier au client.

    Supposons par exemple que l'utilisateur jean utilise le service rlogin du serveur montreal. Étant donné qu'il est déjà authentifié (c'est-à-dire qu'il détient déjà un ticket d'octroi de tickets), l'utilisateur obtient automatiquement et de façon transparente un ticket faisant partie de la commande rlogin. Ce ticket lui permet de se connecter à montreal avec rlogin autant de fois qu'il lui plaît jusqu'à ce que le ticket expire. Si jean désire se connecter à l'ordinateur denver à l'aide de rlogin, il obtient un autre ticket, comme à l'étape 1.

  3. Le client envoie le ticket au serveur.

  4. Le serveur autorise l'accès au client.

En examinant de près ces étapes, vous avez peut-être remarqué que le serveur semble ne jamais communiquer avec le KDC. Ce n'est pas le cas : il s'enregistre auprès du KDC, tout comme le premier client. Pour simplifier les choses, nous avons omis cette partie.

Commandes SEAM

Quelles sont les commandes SEAM (ou "compatibles Kerberos") qu'un utilisateur tel que jean peut utiliser ? Ce sont :

Ces applications sont semblables aux applications Solaris portant le même nom, sauf qu'elles utilisent des principaux Kerberos pour authentifier les transactions, assurant ainsi une sécurité de niveau Kerberos. (Voir "Principaux" au sujet des principaux.)

Ces commandes sont examinées plus en détail dans "Commandes de SEAM".

Principaux

Un client de SEAM est identifié par son principal. Un principal a une identité unique à laquelle le KDC peut attribuer des tickets. Un principal peut être un utilisateur, jean par exemple, ou un service, comme nfs ou telnet.

Par convention, un nom de principal se compose de trois parties : le primaire, l'instance et le secteur. Un exemple typique de principal SEAM serait jean/admin@FRA.ACME.COM, où

Voici des exemples de noms de principaux valides :

Secteurs

Un secteur consiste en un réseau logique, comme un domaine, définissant un groupe de systèmes régis par le même KDC maître (voir ci-dessous). Figure 1-3 montre la relation existant entre les différents secteurs. Certains secteurs sont de type hiérarchique (l'un constituant un surensemble comprenant l'autre). Autrement, les secteurs sont de type non hiérarchique, et le mappage entre deux secteurs doit être défini. SEAM possède la caractéristique de pouvoir assurer l'authentification entre les secteurs ; chaque secteur n'a besoin que d'une seule entrée de principal correspondant à l'autre secteur dans son KDC.

Figure 1-3 Secteurs

Graphic

Secteurs et serveurs

Chaque secteur doit inclure un serveur dans lequel est conservée une copie maîtresse de la base de données des principaux. Ce serveur porte le nom de serveur KDC maître. De plus, chaque secteur doit contenir au moins un serveur KDC esclave, contenant des copies de la base de données des principaux. Les serveurs KDC maître et esclaves créent des tickets servant à établir l'authentification.

Le secteur peut également contenir deux autres types de serveurs SEAM. Il peut s'agir d'un serveur d'applications de réseau SEAM fournissant l'accès aux applications compatibles Kerberos (comme ftp, telnet et rsh). Ce peut être également un serveur NFS assurant les services NFS à l'aide de l'authentification Kerberos.

Figure 1-4 montre le contenu d'un secteur hypothétique.

Figure 1-4 Secteur typique

Graphic

Services de sécurité

En plus d'assurer l'authentification sécurisée des utilisateurs, SEAM fournit deux services de sécurité :

À l'heure actuelle, parmi les différentes applications compatibles Kerberos intégrées à SEAM, seule la commande ftp permet aux utilisateurs de changer de service de sécurité pendant l'exécution ("en temps réel"). Les développeurs peuvent concevoir des applications RPC avec une interface de programmation RPCSEC-GSS permettant de sélectionner un service de sécurité.

Composantes de SEAM

Tout comme la version 5 de Kerberos du MIT, SEAM comprend les composantes suivantes :

SEAM inclut également les composantes suivantes :