inclusion Kerberos
This commit is contained in:
parent
fa27218837
commit
2136eb1607
58
doc.md
58
doc.md
|
|
@ -39,64 +39,6 @@ TODO Paul
|
|||
Utilisé pour la plateforme FranceConnect
|
||||
Plus facile à mettre en place que des solutions basées SAML ?
|
||||
|
||||
## Kerberos (RFC1510)
|
||||
TODO bouquin o'Reilly
|
||||
|
||||
TODIG
|
||||
- Mutual Authentication :
|
||||
Le client s'authentifie auprès du serveur, et réciproquement. Cette double authentification limite les risque d'usurpation d'identité (*identity spoofing*)
|
||||
Trusted Third-Party
|
||||
SESAME's limited delegation
|
||||
|
||||
L'algorithme de chiffrement symétrique utilisé par Kerberos est DES.
|
||||
|
||||
Notion de principal
|
||||
|
||||
Chiffrement des tickets envoyés
|
||||
|
||||
Ticket delivery service
|
||||
|
||||
Les clés distribuées par le service (de délivrement de tickets) ont une durée limitée dans le temps, ce qui diminue le risque d'attaques de type *replay* (rejeu frauduleux d'une session par un tiers non autorisé).
|
||||
On parle alors de clé de session.
|
||||
|
||||
### Recommandations/spécifications de la RFC
|
||||
#### Déroulement de la phase d'authentfication :
|
||||
- Le client envoie une requête d'accès à un service donné,
|
||||
- Le serveur d'authentification Kerberos renvoie les accès, chiffré avec la clé publique du client. Ces accès contiennent un ticket initial et une clé cde session (clé temporaire).
|
||||
- Le client va utiliser le ticket pour contacter le serveur. Ce ticket contient l'identité du client et la clé de session chiffrée avec la clé publique du serveur (associé au service demandé par le client).
|
||||
- La clé temporaire initie l'authentification (pas forcément mutuelle), puis la négociation d'un paramètres de communication chiffrée entre client et serveur.
|
||||
|
||||
#### Accès à l'AS
|
||||
Deux façons de réaliser la première étape (demande d'accès du client au serveur d'authentification) :
|
||||
* D'abord un TGT (*Ticket-Granting Ticket*) pour contacter le TGS (*Ticket-Granting Server*)
|
||||
* Sinon, le TGS est un serveur d'application comme les autres, pas de méthode de communication spécifique.
|
||||
|
||||
L'accès à la base de données des principaux se fait selon le protocole KADM (Kerberos Administration).
|
||||
|
||||
#### *Realms* (Royaumes)
|
||||
A un serveur d'authentification est associé un royaume. Les royaumes représentent donc une unité organisationnelle nécessitant un mécanisme d'authentification pour ses principaux.
|
||||
On remarquera ainsi que le nom du royaume apparaît dans l'identifiant de tout principal de ce royaume.
|
||||
|
||||
Il peut cependant être intéressant de mettre en place des mécanismes de communication (et d'authentification) inter-royaume.
|
||||
|
||||
//TODO cross-realm operations
|
||||
Ces communications inter-royaumes nécessitant que l'admin sys mette en place des clés prévues à cet effet. Elles permettront les échanes chiffrés entre les royaumes.
|
||||
|
||||
Concrètement, le TGS d'un royaume est enregistré en tant que principal du second royaume. Tout client local peut alors contacter le TGS distant à l'aide un TGT classique.
|
||||
|
||||
La communication entre deux royaumes peuvent transiter par plusieurs royaumes intermédiaires, pourvu qu'une clé inter-royaume soit disponible pour chaque échange direct.
|
||||
On parle alors de chemin d'authentification (*authentication path*).
|
||||
|
||||
En conséquence, pour des raisons pratiques, on met en place une organisation hiérarchique des royaumes entre eux, selon une structure arborescente.
|
||||
Dans un tel modèle, tout royaume a un père et potentiellement plusieurs fils.
|
||||
Cette hiérarchie est déduite des chemins d'authentification usuels.
|
||||
|
||||
TODO Question : comment est mise en place la base de données de principaux ? revoir KADM dans le cas de plusieurs royaumes.
|
||||
|
||||
On remarquera enfin que le processus d'authentification n'est par nature pas transparent pour l'application. Elle connaît, à l'aide du ticket, les differents royaumes impliqués dans le chemin d'authentification. Elle peut alors en déduire la fiabilité du processus d'authentification en fonction des différents acteurs mis en jeu.
|
||||
|
||||
TODO : Section 1.2 (*Environmental Assumptions*) mérite d'être détaillée ici
|
||||
|
||||
# Identity Management
|
||||
|
||||
## Principes généraux
|
||||
|
|
|
|||
|
|
@ -704,7 +704,63 @@ pointeurs TODO
|
|||
|
||||
### Authentification et SSO
|
||||
|
||||
#### Kerberos (?)
|
||||
#### Kerberos (RFC1510)
|
||||
TODO bouquin o'Reilly
|
||||
|
||||
TODIG
|
||||
- Mutual Authentication :
|
||||
Le client s'authentifie auprès du serveur, et réciproquement. Cette double authentification limite les risque d'usurpation d'identité (*identity spoofing*)
|
||||
Trusted Third-Party
|
||||
SESAME's limited delegation
|
||||
|
||||
L'algorithme de chiffrement symétrique utilisé par Kerberos est DES.
|
||||
|
||||
Notion de principal
|
||||
|
||||
Chiffrement des tickets envoyés
|
||||
|
||||
Ticket delivery service
|
||||
|
||||
Les clés distribuées par le service (de délivrement de tickets) ont une durée limitée dans le temps, ce qui diminue le risque d'attaques de type *replay* (rejeu frauduleux d'une session par un tiers non autorisé).
|
||||
On parle alors de clé de session.
|
||||
|
||||
##### Recommandations/spécifications de la RFC
|
||||
###### Déroulement de la phase d'authentfication :
|
||||
- Le client envoie une requête d'accès à un service donné,
|
||||
- Le serveur d'authentification Kerberos renvoie les accès, chiffré avec la clé publique du client. Ces accès contiennent un ticket initial et une clé cde session (clé temporaire).
|
||||
- Le client va utiliser le ticket pour contacter le serveur. Ce ticket contient l'identité du client et la clé de session chiffrée avec la clé publique du serveur (associé au service demandé par le client).
|
||||
- La clé temporaire initie l'authentification (pas forcément mutuelle), puis la négociation d'un paramètres de communication chiffrée entre client et serveur.
|
||||
|
||||
###### Accès à l'AS
|
||||
Deux façons de réaliser la première étape (demande d'accès du client au serveur d'authentification) :
|
||||
* D'abord un TGT (*Ticket-Granting Ticket*) pour contacter le TGS (*Ticket-Granting Server*)
|
||||
* Sinon, le TGS est un serveur d'application comme les autres, pas de méthode de communication spécifique.
|
||||
|
||||
L'accès à la base de données des principaux se fait selon le protocole KADM (Kerberos Administration).
|
||||
|
||||
###### *Realms* (Royaumes)
|
||||
A un serveur d'authentification est associé un royaume. Les royaumes représentent donc une unité organisationnelle nécessitant un mécanisme d'authentification pour ses principaux.
|
||||
On remarquera ainsi que le nom du royaume apparaît dans l'identifiant de tout principal de ce royaume.
|
||||
|
||||
Il peut cependant être intéressant de mettre en place des mécanismes de communication (et d'authentification) inter-royaume.
|
||||
|
||||
//TODO cross-realm operations
|
||||
Ces communications inter-royaumes nécessitant que l'admin sys mette en place des clés prévues à cet effet. Elles permettront les échanes chiffrés entre les royaumes.
|
||||
|
||||
Concrètement, le TGS d'un royaume est enregistré en tant que principal du second royaume. Tout client local peut alors contacter le TGS distant à l'aide un TGT classique.
|
||||
|
||||
La communication entre deux royaumes peuvent transiter par plusieurs royaumes intermédiaires, pourvu qu'une clé inter-royaume soit disponible pour chaque échange direct.
|
||||
On parle alors de chemin d'authentification (*authentication path*).
|
||||
|
||||
En conséquence, pour des raisons pratiques, on met en place une organisation hiérarchique des royaumes entre eux, selon une structure arborescente.
|
||||
Dans un tel modèle, tout royaume a un père et potentiellement plusieurs fils.
|
||||
Cette hiérarchie est déduite des chemins d'authentification usuels.
|
||||
|
||||
TODO Question : comment est mise en place la base de données de principaux ? revoir KADM dans le cas de plusieurs royaumes.
|
||||
|
||||
On remarquera enfin que le processus d'authentification n'est par nature pas transparent pour l'application. Elle connaît, à l'aide du ticket, les differents royaumes impliqués dans le chemin d'authentification. Elle peut alors en déduire la fiabilité du processus d'authentification en fonction des différents acteurs mis en jeu.
|
||||
|
||||
TODO : Section 1.2 (*Environmental Assumptions*) mérite d'être détaillée ici
|
||||
|
||||
#### SAML
|
||||
#### SAML
|
||||
|
|
|
|||
Reference in New Issue