Lors de mon précédent poste sur S4U2Self, j'ai un peu utilisé les termes impersonation et délégation sans y attacher plus de précision. J'ai aussi indiqué que ce sont les applications qui doivent mettre en œuvre la transition de protocole. En fait WCF (Windows Communication Foundation – précédemment Indigo), qui fait partie du .Net Framework 3.0 et qui est disponible aussi bien sur Windows Vista/Longhorn Server que sur Windows XP/Windows Server 2003, offre la transition de protocole d'une authentification client par certificat vers Kerberos.

Mais commençons par l'impersonation et la délégation. Sur la plateforme Windows, il est courant de faire la distinction entre une impersonation qui permet l'accès à des ressources locales, et une délégation qui permet l'accès à des ressources distantes. L'API Windows reflète cette distinction par le biais du niveau d'impersonation du jeton: SecurityAnonymous, SecurityIdentification, SecurityImpersonation, et SecurityDelegation (voir SECURITY_IMPERSONATION_LEVEL sur http://msdn2.microsoft.com/en-us/library/aa489535.aspx). Je vous encourage à relire le classique Windows Programming Security (Chapitre 4 – Logon Sessions) ainsi que le Livre Wiki de Keith Brown (ainsi bien sur que le SDK Windows), mais pour moi ces distinctions sont des facilités techniques liées à NTLM/Kerberos. Très schématiquement: si le client s'est authentifié via NTLM, le niveau du jeton est SecurityImpersonation, et le serveur ne peut accéder pour le compte du client qu'aux ressources locales. Si le client s'est authentifié via Kerberos (et moyennant le fait que la délégation Kerberos soit mise en œuvre), le niveau du jeton est SecurityDelegation, et le serveur peut accéder pour le compte du client à des services distants.

Cette distinction entre impersonation et délégation ne peut être généralisée. Je m'explique: pour pouvoir accéder à des ressources ou des services distants en tant que son client, un serveur doit avoir des "network credentials" pour ce client. Cela peut être le mot de passe du client ou un ticket TGT Kerberos "forwardable". Imaginons que le serveur possède le mot de passe du client, il peut ouvrir une session de logon pour le client (LogonUser), puis impersonner ce client (ImpersonateLoggedUser) et accéder à des ressources distantes pour le compte du client. Le niveau d'impersonation du jeton n'est pourtant "que" SecurityImpersonation. C'est aussi le cas d'une session de logon obtenue via S4U2Self. La session de logon possède un ticket Kerberos "forwardable", donc des "network credentials", malgré le fait que le niveau du jeton ne soit que SecurityImpersonation, l'accès aux ressources distantes pour le compte du client est possible. Je dirais aussi que le niveau du jeton SecurityDelegation indique que l'utilisateur s'est authentifié via Kerberos, et qu'il n'y a pas eu de transition de protocole.

L'utilisation de l'impersonation et de la delegation par WCF fait l'objet d'une fiche technique http://msdn2.microsoft.com/en-us/library/ms730088.aspx. Deux méthodes sont possibles:

S4U-Based Impersonation – cette méthode couvre la transition de protocole d'une authentification client par certificat vers l'ouverture d'une session de logon Windows via S4USelf. WCF prend en charge cette transition pour l'application.

Cached Token Impersonation – cette méthode couvre les autres mécanismes. Typiquement authentification basic, authentification client SSL/TLS avec mapping du certificat sur compte AD, Kerberos avec ou sans délégation, etc…

La documentation détaille les niveaux d'impersonation du jeton Windows obtenu pour chacun des cas. Des collègues m'ont demandé si cette documentation était réellement correcte car elle indiquait un niveau "Impersonation" pour des cas où l'accès distant (scenario d'une délégation) est possible. En regard de ce que je mentionne ci-dessus, la doc est correcte. On peut admettre cependant qu'il aurait été pertinent d'indiquer, en plus du niveau d'impersonation, les cas pour lesquels l'accès distant est possible, plutôt que de laisser le développeur/architecte le déduire.

Extraits de la documentation:

Impersonation Level Obtained from UserName Credentials and Cached Token Impersonation

Allowed Impersonation Level

Service has SeImpersonatePrivilege

Service and client are capable of delegation

Cached token ImpersonationLevel

n/a

Yes

Yes

Delegation

n/a

Yes

No

Impersonation

n/a

No

n/a

Identification

 

Impersonation Level Obtained from S4U-based Impersonation

Service has SeTcbPrivilege

Service has SeImpersonatePrivilege

Service and client are capable of delegation

Cached token ImpersonationLevel

Yes

Yes

n/a

Impersonation

Yes

No

n/a

Identification

No

n/a

n/a

Identification

 

Jusqu'à présent, il fallait coder soi-même la transition de protocole dans une application de type passerelle. WCF l'offre de base. Le revers de la médaille est que la passerelle doit s'exécuter en TCB comme l'indique le tableau ci-dessus.