1.2. Opération Inter-Domaines
1.2. Opération Inter-Domaines
Le protocole Kerberos est conçu pour fonctionner au-delà des frontières organisationnelles. Un client dans une organisation peut être authentifié auprès d'un serveur dans une autre. Chaque organisation souhaitant exécuter un serveur Kerberos établit son propre "domaine" (realm). Le nom du domaine dans lequel un client est enregistré fait partie du nom du client et peut être utilisé par le service final pour décider s'il faut honorer une demande.
En établissant des clés "inter-domaines", les administrateurs de deux domaines peuvent permettre à un client authentifié dans le domaine local de prouver son identité aux serveurs dans d'autres domaines. L'échange de clés inter-domaines (une clé distincte peut être utilisée pour chaque direction) enregistre le service d'octroi de tickets de chaque domaine en tant que principal dans l'autre domaine. Un client est alors capable d'obtenir un TGT pour le service d'octroi de tickets du domaine distant auprès de son domaine local. Lorsque ce TGT est utilisé, le service d'octroi de tickets distant utilise la clé inter-domaines (qui diffère généralement de sa propre clé TGS normale) pour déchiffrer le TGT; ainsi il est certain que le ticket a été émis par le TGS du client lui-même. Les tickets émis par le service d'octroi de tickets distant indiqueront au service final que le client a été authentifié depuis un autre domaine.
Sans opération inter-domaines, et avec la permission appropriée, le client peut organiser l'enregistrement d'un principal nommé séparément dans un domaine distant et s'engager dans des échanges normaux avec les services de ce domaine. Cependant, même pour de petits nombres de clients, cela devient fastidieux, et des méthodes plus automatiques comme décrites ici sont nécessaires.
On dit qu'un domaine communique avec un autre domaine si les deux domaines partagent une clé inter-domaines, ou si le domaine local partage une clé inter-domaines avec un domaine intermédiaire qui communique avec le domaine distant. Un chemin d'authentification est la séquence de domaines intermédiaires qui sont traversés lors de la communication d'un domaine à un autre.
Les domaines peuvent être organisés de manière hiérarchique. Chaque domaine partage une clé avec son parent et une clé différente avec chaque enfant. Si une clé inter-domaines n'est pas directement partagée par deux domaines, l'organisation hiérarchique permet de construire facilement un chemin d'authentification.
Si une organisation hiérarchique n'est pas utilisée, il peut être nécessaire de consulter une base de données afin de construire un chemin d'authentification entre les domaines.
Bien que les domaines soient typiquement hiérarchiques, les domaines intermédiaires peuvent être contournés pour réaliser une authentification inter-domaines via des chemins d'authentification alternatifs. (Ceux-ci pourraient être établis pour rendre la communication entre deux domaines plus efficace.) Il est important pour le service final de savoir quels domaines ont été traversés lors de la décision de la confiance à accorder au processus d'authentification. Pour faciliter cette décision, un champ dans chaque ticket contient les noms des domaines qui ont été impliqués dans l'authentification du client.
Le serveur d'application est ultimement responsable d'accepter ou de rejeter l'authentification et DEVRAIT vérifier le champ transité. Le serveur d'application peut choisir de s'appuyer sur le Centre de Distribution de Clés (KDC) pour le domaine du serveur d'application pour vérifier le champ transité. Le KDC du serveur d'application définira le drapeau TRANSITED-POLICY-CHECKED dans ce cas. Les KDC pour les domaines intermédiaires peuvent également vérifier le champ transité lorsqu'ils émettent des TGT pour d'autres domaines, mais ils sont encouragés à ne pas le faire. Un client peut demander que les KDC ne vérifient pas le champ transité en définissant le drapeau DISABLE-TRANSITED-CHECK. Les KDC DEVRAIENT honorer ce drapeau.