Protocoles de sécurité
Open ENT doit supporter différents protocoles d'authentification et d'autorisation pour pouvoir intégrer le plus grand nombre de services et modules en toute securité. Les 4 protocoles suivants sont supportés :
- protocole CAS
- protocole CAS avec proxy
- protocole Open ID Connect (OIDC)
- protocole SAML
Les protocoles CAS et CAS proxy sont utilisés pour l'accès aux ressources pédagogiques proposées par les nombreux partenaires du catalogue de ressources.
Le protocole Open ID Connect est utilisé pour l'authentification et l'autorisation des différents modules et services
Le protocole SAML est utilisé pour l'intégration avec le GAR et EduConnect
Les protocoles CAS, CAS avec Proxy et OpenID Connect (OIDC) ont des différences notables en termes de conception, de fonctionnalités et de cas d'utilisation.
Nous détaillerons leurs caractéristiques clés et leurs diagrammes de séquence.
1. CAS (Central Authentication Service)
- Fonctionnement : CAS est un protocole d’authentification qui utilise des "tickets" pour vérifier l'identité de l'utilisateur. Le client demande un ticket au serveur CAS, qui est ensuite validé par le service cible.
- Processus : L'utilisateur se connecte via une page de login unique, reçoit un Service Ticket (ST) du serveur CAS, qu’il fournit ensuite au service pour accéder aux ressources.
- Cas d'Utilisation : Utilisé principalement pour les Single Sign-On (SSO) dans des environnements avec plusieurs applications internes.
- Sécurité : Relativement sécurisé pour les applications internes, avec des sessions courtes pour limiter les risques.
- Limites : CAS ne permet pas facilement la délégation d’accès pour des services tiers.
2. CAS avec Proxy
- Fonctionnement : CAS avec Proxy étend le protocole CAS pour permettre la délégation d'accès. Il introduit le Proxy Granting Ticket (PGT) pour autoriser les services intermédiaires (proxy) à accéder à d'autres services en votre nom.
- Processus : En plus des étapes du CAS, le service initial obtient un PGT auprès du serveur CAS, qu’il utilise ensuite pour interagir avec un service tiers en tant que proxy.
- Cas d'Utilisation : Idéal pour les architectures où un service intermédiaire a besoin d'agir pour le compte de l’utilisateur pour des opérations en chaîne.
- Sécurité : Renforce la sécurité via des validations de ticket supplémentaires, bien que la délégation d’accès puisse ajouter des points de vulnérabilité.
- Limites : Complexité accrue en raison de la gestion des PGTs et de la validation entre les services.
3. OpenID Connect (OIDC)
- Fonctionnement : OIDC est un protocole d'authentification construit sur OAuth 2.0. Il permet l'authentification et l’autorisation via des "tokens" (ID Token, Access Token) et est conçu pour les applications modernes, notamment celles basées sur le web et le mobile.
- Processus : Le client obtient un code d’autorisation en se connectant via l’OpenID Provider (OP), puis échange ce code contre des tokens (ID Token pour l'identité de l'utilisateur et Access Token pour accéder aux ressources).
- Cas d'Utilisation : OIDC est utilisé pour l'authentification sécurisée avec des applications tierces et des services dans le cloud. Il convient aux applications web, mobiles et API.
- Sécurité : Très sécurisé, avec des mécanismes comme le chiffrement des tokens et la gestion des durées de vie des sessions.
- Limites : Plus complexe à mettre en œuvre et nécessite une bonne gestion des tokens et de leurs permissions.
4. SAML
Pour le protocole SAML (Security Assertion Markup Language), voici les détails concernant les principaux aspects de son fonctionnement :
Détails de SAML
| Critère | SAML |
|---|---|
| Type de protocole | Standard de Single Sign-On (SSO) et d'autorisation basé sur XML |
| Méthode d'authentification | Utilise des assertions SAML sous forme de documents XML signés pour transmettre l'identité |
| Utilisation | Fédération d'identités, SSO sécurisé entre organisations et applications d'entreprise |
| Gestion de sessions | Basée sur des assertions SAML échangées entre Identity Provider (IdP) et Service Provider (SP), souvent avec une session gérée par le SP et le IdP |
| Délégation d'accès | Non supportée directement ; conçu pour des scénarios de fédération et non de délégation de droits à des services intermédiaires |
| Déconnexion | Prise en charge de la déconnexion SSO centralisée, mais peut être complexe à gérer et coordonner entre les différents services |
| Scalabilité | Bien adapté pour les environnements avec besoin de fédération d'identités, mais moins flexible que les approches modernes sans état |
| Sécurité | Basé sur des signatures numériques, encrypte les assertions SAML ; offre un haut niveau de sécurité, mais exige une configuration et gestion plus complexes |
| Cas d'usage | Parfait pour des applications Web dans des environnements d'entreprise, ou des situations de fédération d'identité inter-organisationnelle |
Fonctionnement de SAML
-
Authentification déléguée via IdP et SP : SAML repose sur deux entités principales, l'Identity Provider (IdP), qui authentifie l’utilisateur, et le Service Provider (SP), qui fournit le service demandé. Le SP délègue l'authentification au IdP via une requête SAML.
-
Assertions SAML : Lorsqu’un utilisateur est authentifié, l'IdP génère une assertion SAML, un document XML signé contenant les informations d'authentification de l'utilisateur, telles que son identité et ses autorisations. Cette assertion est transmise au SP via le navigateur de l’utilisateur.
-
Single Sign-On (SSO) : Grâce aux assertions SAML, l’utilisateur n'a besoin de s'authentifier qu'une seule fois pour accéder à plusieurs applications dans un environnement fédéré.
-
Sécurité et complexité : Les assertions SAML sont signées et peuvent être chiffrées, assurant une sécurité renforcée mais demandant une gestion rigoureuse des clés de signature et des certificats.
Avantages et Inconvénients de SAML
-
Avantages :
- Très sécurisé avec des signatures et options de chiffrement, adapté aux environnements d’entreprise nécessitant une fédération d'identité.
- Permet une authentification unique (SSO) inter-organisationnelle.
- Compatible avec de nombreux fournisseurs de services d’entreprise et des solutions de gestion d'identité.
-
Inconvénients :
- Complexité de mise en œuvre et d’administration élevée, notamment pour gérer la synchronisation des sessions et les certificats.
- Moins adapté aux applications modernes et décentralisées, car il n'est pas pensé pour un fonctionnement sans état comme OpenID Connect.
5. Comparatif Général
| Critère | CAS | CAS avec Proxy | OpenID Connect | SAML |
|---|---|---|---|---|
| Type de protocole | Protocole propriétaire de Single Sign-On (SSO) | Extension du CAS pour déléguer l'authentification aux services en chaîne | Protocole d'authentification basé sur OAuth 2.0 | Protocole de Single Sign-On (SSO) et d'autorisation basé sur XML |
| Méthode d'authentification | Basé sur l'authentification SSO avec tickets d'accès | Authentification SSO avec délégation de tickets proxy | Basé sur des tokens (ID Token, Access Token, Refresh Token) | Basé sur des assertions SAML (documents XML signés) |
| Utilisation | SSO dans des environnements internes | Authentification SSO pour des applications internes nécessitant un accès délégué | Authentification déléguée pour des applications modernes | SSO entre applications d'entreprise et fédération d'identités |
| Gestion de sessions | Sessions maintenues sur le serveur CAS | Sessions maintenues sur le serveur CAS avec délégation | Gestion des sessions via tokens (sans état côté serveur) et déconnexion via End Session Endpoint | Sessions via des assertions SAML, gérées par le Service Provider et Identity Provider |
| Délégation d'accès | Non | Supporte la délégation d'accès avec des tickets proxy | Basé sur des tokens OAuth 2.0, incluant des scopes et autorisations spécifiques | Géré via la fédération d'identité, pas de support direct pour la délégation d'accès |
| Déconnexion | Fermeture de session centralisée via le serveur CAS | Déconnexion centralisée, mais complexe en cas de délégation | Déconnexion avec End Session Endpoint pour SSO | Déconnexion centralisée, mais plus complexe à implémenter et à coordonner |
| Scalabilité | Bien adapté aux environnements avec un serveur CAS centralisé | Bien adapté mais peut ajouter une complexité de performance en proxy | Conçu pour des applications décentralisées et adaptable aux environnements modernes | Moins flexible pour des applications modernes, mais bien adapté aux environnements SSO |
| Sécurité | Validation des tickets d’accès ; dépend de la configuration sécuritaire de CAS | Validation des tickets proxy, ajoutant une sécurité via délégation | Tokens signés et encryptés, gestion du consentement, scopes d’accès et révocation de token | Signatures numériques et assertions SAML protégées ; sécurité élevée, mais complexe |
| Cas d'usage | Authentification SSO pour les applications internes | SSO pour les applications nécessitant une chaîne d'accès déléguée | Accès sécurisé aux applications Web et mobiles ; API RESTful | Authentification fédérée entre organisations ; SSO sécurisé pour des applications Web |