2.5. Tickets proxiables et mandataires (proxy)
Vue d'ensemble
Il peut être nécessaire qu'un principal autorise un service à effectuer une opération en son nom. Le service doit pouvoir prendre l'identité du client, mais uniquement à une fin déterminée.
Drapeau PROXIABLE
Le drapeau PROXIABLE dans un ticket :
- n'est en principe interprété que par le service d'octroi de tickets
- peut être ignoré par les serveurs d'application
- lorsqu'il est positionné, indique au TGS qu'il est acceptable de délivrer un nouveau ticket (mais pas un TGT) avec une adresse réseau différente
- est positionné si le client le demande lors de l'authentification initiale
- par défaut, le client demandera qu'il soit positionné lors de la demande d'un TGT, et qu'il soit remis à zéro lors de la demande de tout autre ticket
Exemple de cas d'usage
Un client d'un service d'impression peut fournir au serveur d'impression un mandataire (proxy) pour accéder aux fichiers du client sur un serveur de fichiers donné afin de satisfaire une demande d'impression.
Considérations sur les adresses réseau
- les tickets Kerberos ne sont souvent valides qu'à partir des adresses réseau explicitement incluses dans le ticket
- une option de politique autorise les tickets sans adresses réseau spécifiées
- lors de l'octroi d'un mandataire, le client DOIT spécifier la nouvelle adresse réseau ou indiquer que le mandataire est à délivrer pour une utilisation depuis n'importe quelle adresse
Drapeau PROXY
Le drapeau PROXY est positionné dans un ticket par le TGS lorsqu'il délivre un ticket mandataire. Les serveurs d'application :
- PEUVENT vérifier ce drapeau
- PEUVENT exiger une authentification supplémentaire de l'agent présentant le mandataire afin de fournir une piste d'audit
Référence
Pour les détails techniques complets, voir RFC 4120, section 2.5.