test

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

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