Terminologie SEAM

Cette section présente des termes utilisés dans la documentation SEAM et donne leur définition. Il importe de bien saisir le sens de ces termes afin de pouvoir comprendre le texte.

Terminologie propre à l'authentification

Les termes décrits ci-après sont nécessaires à une bonne compréhension du processus d'authentification. Les programmeurs et les administrateurs de système devraient se familiariser avec ces termes.

Un client est le logiciel exécuté sur le poste de travail d'un utilisateur. Le logiciel SEAM exécuté sur le client effectue des requêtes durant ce processus, et il importe de différencier les actions de ce logiciel et celles de l'utilisateur.

Les termes «serveur» et «service» sont souvent employés de manière interchangeable. Pour fins de clarification, le terme serveur désigne le système physique où le logiciel SEAM est exécuté. Le terme service désigne une fonction particulière prise en charge par un serveur (par exemple, ftp ou nfs). La documentation mentionne souvent des serveurs faisant partie d'un service, mais cela obscurcit le sens des termes ; par conséquent, le serveur désigne le système physique, et le service désigne le logiciel.

Le produit SEAM inclut trois types de clé. L'un deux est la clé privée. Cette clé est attribuée à chaque principal d'utilisateur, et n'est connue que par l'utilisateur du principal et le centre de distribution de clés (KDC). Pour les principaux d'utilisateur, la clé est basée sur le mot de passe de l'utilisateur. Pour les serveurs et les services, la clé est appelée clé de service. Cette clé joue le même rôle que la clé privée, mais est employée par les serveurs et les services. Le troisième type de clé est la clé de session. Il s'agit d'une clé générée par le service d'authentification ou le service d'octroi de tickets. Une clé de session est générée pour assurer des transactions sécuritaires entre un client et un service.

Un ticket est un paquet d'informations permettant de transmettre l'identité d'un utilisateur à un serveur ou service de manière sécuritaire. Un ticket n'est valable que pour un seul client et un service particulier sur un serveur particulier. Il contient le nom du principal du service, le nom du principal de l'utilisateur, l'adresse IP de l'hôte de l'utilisateur, un horodateur et une valeur définissant la durée de vie du ticket. Un ticket est créé avec une clé de session aléatoire pour son utilisation par le client et le service. Une fois un ticket créé, il peut être réutilisé jusqu'à son expiration.

Un justificatif d'identité est un paquet d'informations incluant un ticket et une clé de session correspondante. Les justificatifs d'identité sont souvent chiffrés au moyen d'une clé privée ou d'une clé de service, selon ce qui déchiffrera le justificatif d'identité.

Un authentificateur est un autre type d'informations. Lorsque utilisé avec un ticket, un authentificateur peut servir à authentifier un principal d'utilisateur. Un authentificateur inclut le nom du principal de l'utilisateur, l'adresse IP de l'hôte de l'utilisateur et un horodateur. Contrairement à un ticket, un authentificateur ne peut servir qu'une seule fois, généralement lors d'une demande d'accès à un service. Un authentificateur est chiffré au moyen de la clé de session pour ce client et ce serveur.

Types de tickets

Les tickets ont des propriétés régissant leur utilisation. Ces propriétés sont attribuées au ticket lors de sa création, mais vous pouvez les modifier ultérieurement. (Par exemple, un ticket peut passer de transférable à transféré). Vous pouvez visualiser les propriétés d'un ticket au moyen de la commande klist (voir "Comment afficher les tickets").

Les tickets peuvent être décrits par un ou plusieurs des termes suivants :

transférable/transféré

Un ticket transférable peut être envoyé d'un hôte à un autre, sans que le client doive se réauthentifier. Par exemple, si l'utilisateur david obtient un ticket transférable pendant qu'il utilise l'ordinateur de julie, il peut se connecter à son propre ordinateur sans devoir obtenir un nouveau ticket (et donc sans se réauthentifier). (La section "Exemple -- Création d'un ticket" donne un exemple de ticket transférable.) Comparez ce type de ticket au ticket à proxy, décrit plus loin.

initial

Un ticket initial est émis directement, et n'est pas basé sur un ticket d'octroi de tickets. Certains services, par exemple les applications qui changent les mots de passe, peuvent exiger que les tickets soient identifiés comme initiaux afin de s'assurer que le client connaît sa clé secrète -- car un ticket initial indique que le client s'est récemment authentifié (plutôt que de se fier à un ticket d'octroi de tickets pouvant exister depuis longtemps).

incorrect

Un ticket incorrect est un ticket postdaté non encore utilisable. (Voir postdaté, ci-après.) Il sera refusé par un serveur d'applications jusqu'à ce qu'il soit validé. Pour être validé, il doit être présenté au KDC par le client dans une requête de service d'octroi de tickets, avec l'indicateur VALIDATE activé, une fois son heure de validité atteinte.

postdatable/postdaté

Un ticket postdaté ne devient valide qu'un certain temps après sa création. Ce genre de ticket est utile, par exemple, pour les traitements par lots exécutés durant la nuit, étant donné que si le ticket est volé, il ne pourra pas être employé avant l'exécution du traitement par lots. Lorsqu'un ticket postdaté est émis, il a le type incorrect et demeure ainsi jusqu'à ce que son heure de validité soit atteinte, et que le client demande la validation par le KDC. (Voir incorrect, ci-dessus.) Un ticket postdaté est normalement valide jusqu'à l'heure d'expiration du ticket d'octroi de tickets. Toutefois, s'il est identifié comme renouvelable, sa durée de vie est généralement égale à la durée de vie totale du ticket d'octroi de tickets. Voir renouvelable, ci-dessous.

à proxy/proxy

Il peut parfois s'avérer nécessaire pour un principal de permettre à un service d'effectuer une opération à sa place (par exemple si le principal demande à un service d'exécuter une tâche d'impression sur un troisième hôte). Le service doit être en mesure d'adopter l'identité du client, mais uniquement pour cette opération. En pareil cas, le serveur agit comme proxy pour le client. Le nom du principal du proxy doit être précisé lors de la création du ticket.

Un ticket à proxy est semblable à un ticket transférable, mais il n'est valide que pour un seul service, tandis qu'un ticket transférable accorde au service l'usage complet de l'identité du client. On peut donc considérer un ticket transférable comme une sorte de super-proxy.

renouvelable

Étant donné que les tickets à longue durée de vie peuvent poser des risques de sécurité, on peut désigner un ticket comme étant renouvelable. Un ticket renouvelable possède deux heures d'expiration : l'heure à laquelle l'instance courante du ticket expire, et la durée de vie maximale de tout ticket. Si un client veut continuer d'utiliser un ticket, il le renouvelle avant sa première expiration. Par exemple, un ticket peut être valide durant une heure, et la durée de vie de tous les tickets peut être de dix heures. Si le client détenant le ticket désire le conserver plus d'une heure, il doit le renouveler au cours de cette heure. Lorsqu'un ticket atteint la durée de vie maximale des tickets (10 heures), il expire automatiquement et ne peut plus être renouvelé.

Pour savoir comment visualiser les attributs des tickets, consultez la section "Comment afficher les tickets".

Durée de vie des tickets

Lorsqu'un principal obtient un ticket, y compris un ticket d'octroi de tickets, la durée de vie du ticket est la plus petite des deux valeurs suivantes :

• La durée de vie spécifiée par l'option -l de kinit, si kinit est utilisée pour obtenir la durée de vie des tickets ou pour renouveler le ticket

• La durée de vie maximale (max_life) spécifiée dans le fichier kdc.conf

• La durée de vie maximale spécifiée dans la base de données Kerberos pour le principal de service fournissant le ticket. (Dans le cas de kinit, le principal de service est krbtgt/secteur)

• La durée de vie maximale spécifiée dans la base de données Kerberos pour le principal d'utilisateur qui demande le ticket.

La Figure 7-1 indique comment la durée de vie d'un ticket d'octroi de tickets est établie, et illustre la provenance des quatre valeurs de durée de vie. Bien que la Figure 7-1 indique comment la durée de vie d'un ticket d'octroi de tickets est déterminée, le même principe s'applique lorsqu'un principal obtient un ticket. Les seules différences sont que kinit ne fournit pas de valeur de durée de vie et que le principal de service fournissant le ticket spécifie la durée de vie maximale (plutôt que le principal krbtgt/secteur ).

Figure 7-1 Détermination de la durée de vie d'un ticket d'octroi de tickets

La durée de vie d'un ticket renouvelable est également établie en fonction du minimum de quatre valeurs, mais les valeurs de durée de vie renouvelable sont utilisées :

• La durée de vie renouvelable spécifiée par l'option -r de kinit, si kinit est utilisée pour obtenir ou renouveler le ticket

• La durée de vie renouvelable maximale (max_renewable_life) spécifiée dans le fichier kdc.conf

• La valeur renouvelable de durée de vie maximale spécifiée dans la base de données Kerberos pour le principal de service fournissant le ticket (dans le cas de kinit, le principal de service est krbtgt/secteur)

• La valeur renouvelable de durée de vie maximale spécifiée dans la base de données Kerberos pour le principal d'utilisateur qui demande le ticket

Noms de principal

Chaque ticket est identifié par un nom de principal. Ce nom peut identifier un utilisateur ou un service. Voici des exemples de noms de principal.

Tableau 7-4 Exemples de noms de principal

Nom de principal	Description
root/boston.acme.com@ACME.COM	Principal associé au compte racine sur un client NFS. On l'appelle principal racine et il est nécessaire à la réussite du montage NFS authentifié.
host/boston.acme.com@ACME.COM	Principal utilisé par les applications (telles klist et kprop) et les services compatibles Kerberos (tels que ftp et telnet). On l'appelle principal hôte ou de service.
nom_d'utilisateur@ACME.COM	Principal d'un utilisateur
nom_d'utilisateur/admin@ACME.COM	Principal admin pouvant être utilisé pour administrer la base de données KDC
ftp/boston.acme.com@ACME.COM	Principal utilisé par le service ftp. Il peut être employé à la place d'un principal hôte.
K/M@ACME.COM	Principal de nom de la clé maîtresse. L'un d'eux est associé à chaque KDC maître.
kadmin/history@ACME.COM	Principal comportant une clé permettant de maintenir un historique des mots de passe pour d'autres principaux. Il y en a un pour chaque KDC maître.
kadmin/kdc1.acme.com@ACME.COM	Principal pour le serveur KDC maître donnant accès au KDC au moyen de kadmind
changepw/kdc1.acme.com@ACME.COM	Principal pour le serveur KDC maître donnant accès au KDC lors d'un changement de mot de passe
krbtgt/ACME.COM@ACME.COM	Principal utilisé lors de la création d'un ticket d'octroi de tickets.