Best Practices pour la Sécurité Applicative

Note: This document looks at identity management and access control (IAM) inside applications. It contains recommendations for those in charge of conceiving access control systems, organizing access rights and administering applicative security on the long term. This document does not look at access control outside of business software (for example, physical, system, and network security). Nor does it cover other risks related to applicative security (SQL Injection, network eavesdropping, cookie or HTTP header manipulation, denial of service...).

Supprimer les SILOS - Unifier le contrôle d’accès

Qu’est-ce qu’un Silo ?

Les systèmes d’information se construisent progressivement et comportent souvent plusieurs applications indépendantes. Chaque application inclut sa propre solution pour gérer les droits fins (fine-grained permission), et gère même parfois ses propres comptes utilisateurs, se comportant alors comme un “SILO” indépendant.

Pourquoi les Silos ne fonctionnent pas :

1. La propagation des règles de sécurité est trop complexe: lorsqu’une nouvelle règle  doit s’appliquer, toutes les applications ne peuvent être modifiées de façon cohérente et simultanée car elles reposent sur des systèmes de sécurité différents.
2. Les contrôles ne sont pas exhaustifs: les auditeurs ne sont pas autonomes et doivent demander à chaque équipe des informations sur leur application. Ils sont parfois confrontés à des développeurs peu enclins à répondre à leurs demandes. De plus les informations transmises utilisent des formats différents d’une application à l’autre, les rendant difficiles à analyser et à consolider par les auditeurs..
3. La gestion de la sécurité devient très coûteuse : plus les systèmes sont nombreux et hétérogènes, plus leur administration consomme de ressources.
4. Certaines organisations tentent des solutions d’intégration qui ne résolvent rien : des connecteurs permettre d’échanger des informations sur les utilisateurs et leurs droits d‘accès. Mais la synchronisation de systèmes hétérogènes est très coûteuses et manque de robustesse. De plus, les coûts et les risques d’erreurs liés à la gestion de plusieurs systèmes de sécurité en parallèle demeurent inchangés.

Bénéfices attendus d’un contrôle d’accès centralisé :

1. La mise en œuvre d’une règle de sécurité sera effective instantanément à travers tous les systèmes sécurisés. Par exemple, si les commerciaux ne doivent plus consulter les adresses des employés, il suffira de retirer la permission fonctionnelle correspondante au groupe d’utilisateurs regroupant les commerciaux. Cette permission fonctionnelle se propagera immédiatement via les actions techniques prédéfinies au sein de chaque application (voir plus haut “permissions fonctionnelles”).
2. Les comptes utilisateurs, leurs droits d’accès et l’historique des opérations réalisées seront centralisés dans un stockage indépendant. Les auditeurs seront autonomes pour contrôler la sécurité en temps réel. Ils auront une visibilité transversale à toutes les applications, sans devoir consolider des données de formats différents.

Contrôle d'Accès Centralisé



Bénéfices Attendus

• Chaque action de l'administrator met à jour immédiatement et de façon uniforme la sécurité de toutes les applications de l'entreprise
• Les coûts d'administration et les risques d'erreurs sont réduits
• Les audits sont facilités, transversaux et contrôlent la sécurité en temps réel


3. Les opérations d’administration de la sécurité, n’étant plus redondantes entre systèmes, consommeront moins de ressources et généreront moins d’erreurs.

Permission Based vs. Role Based Access Control

En matière de contrôle d’accès, on parle souvent de Role Based Access Control (RBAC). Le principe consiste à attribuer des droits d’accès en fonction du rôle de l’utilisateur. Les organisations définissent alors des comptes utilisateurs et des rôles communs à plusieurs applications, supprimant ainsi une partie des silos applicatifs.

Dans la plupart des cas, elles laisseront cependant chaque application interpréter les rôles pour définir leurs propres permissions. Une partie du Silo demeure concernant la gestion des permissions fines (fine-grained permissions). Chaque application pourra ainsi développer une access control logic spécifique et implémenter les règles de sécurité indépendamment des autres applications.

A contrario, le “Permission Based Access Control” consiste à uniformiser les permissions fines pour toutes les applications. La gestion des permissions est ainsi confiée à l’équipe en charge du contrôle d’accès, et sort du périmètre des équipes de développements.

Dans ce cas, les permissions seront de type "fonctionnelles" (voir access right granularity). Exemple: un système d’information gère l’entité business “client”. On définit les permissions “CanViewClient”, “CanCreateClient”, “CanUpdateClient”... et on les applique à toutes les applications manipulant les clients. Cette solution permet d’appliquer instantanément les mêmes règles de contrôle d’accès à toutes les applications, éliminant ainsi l’effet négatif des SILOS applicatifs.

Séparer les règles de gestions et les règles de sécurité

Il existe plusieurs raisons de gérer les permissions en dehors des applications :

Réduction des coûts

En sortant le contrôle d’accès du périmètre applicatif, les temps et les coûts de développement sont considérablement réduits (pas de code de sécurité dans chaque application). Vous pouvez alors déployer une solution de contrôle d’accès unifiée, commune à toutes les applications et technologies de votre organisation.

Agilité

Les règles de sécurité et les applications ont des cycles de vie très différents :

• De nouvelles versions d’une application sont publiées tous les X mois.
• Tandis que les règles de sécurité peuvent changer d’un jour à l’autre !

Gérer les règles de sécurité dans l’application pose alors les problèmes suivants :

• Impossible de combler rapidement les failles de sécurité, car il faut attendre qu’une nouvelle version de l’application soit déployée.
• Changer une règle de sécurité coûte très cher : un cycle complet de développement, test et déploiement est alors nécessaire.

Si vous choisissez de sortir le contrôle d’accès des applications, pour le gérer dans un système externe, vous aurez alors 2 options pour définir les permissions :

1. Permissions dynamiques : certains outils peuvent activer ou désactiver des fonctionnalités dynamiquement, sans toucher au code de l’application. Dans ce cas, les développeurs ne s’occupent pas de la sécurité : elle sera gérée par l’équipe responsable de la sécurité après le développement, et appliquée dynamiquement quand l’application sera exécutée.

2. Permissions statiques : les développeurs anticipent le contrôle d’accès en plaçant des points de contrôle dans leur code. On utilisera ensuite ces points de contrôle pour mettre en œuvre des règles de sécurité sans modifier davantage le code:

Choisir soigneusement la granularité des permissions

Toutes les permissions définies à l’intérieur d’une application sont considérées comme des droits fins (“fine-grained permissions”). Pour autant, il existe deux types de permissions applicatives, chacun ayant une granularité et une utilité différente :

Permissions techniques (“application-level permission”).

La permission est liée à un élément physique de l’application : menu, bouton, liste de données, champs, attribut ou méthode d’un service, etc. Les permissions techniques sont définies par les développeurs, et sont spécifiques à une application, un site web ou un service.

Permissions fonctionnelles (“Enterprise-level permissions”):

La permission est associée à une opération et une entité métier (créer une facture, consulter un contrat...). Les permissions fonctionnelles peuvent être communes à plusieurs applications. Elles sont définies par des spécialistes du métier et/ou du contrôle d’accès.

Chaque équipe de développement décompose ensuite les permissions fonctionnelles en actions techniques. Par exemple, la permission “CanViewContract” pourra agir sur des formulaires, menus, boutons, etc. permettant de consulter des contrats dans plusieurs applications.

Quelle option choisir ?

Pour commencer, il est déconseillé de combiner les deux types de permissions. Cela rendrait plus complexe la maintenance de la sécurité et augmenterait la probabilité de conflits entre permissions et l'apparition de failles de sécurité.

On choisira donc un seul type de granularité en fonction des besoins de l’organisation :

Les permissions techniques peuvent convenir à des cas simples, comportant un faible volume de droits d’accès. C’est pourquoi elles sont principalement utilisées lorsque le contrôle d'accès se limite à une seule application (“application-level security”).

Les permissions fonctionnelles sont recommandées pour des volumes plus importants (“enterprise-level security”). Elles permettent de remonter les droits d’accès au niveau fonctionnel, indépendamment du découpage du système d’information par applications.

Les permissions fonctionnelles offrent les bénéfices suivants :

• Elles correspondent aux nouveaux scénarios et règles de gestions auxquels l'entreprise doit s'adapter en permanence. La traduction des permissions en actions techniques sera traitée a posteriori par les développeurs, et n’entrave pas la vision business du contrôle d’accès. Les décisions sont prises de façon transversales pour toute l’entreprise. Les règles de sécurités sont cohérentes pour tout le SI et plus faciles à auditer.
• Elles sont également moins nombreuses que les permissions techniques. Ce point est fondamental pour conserver le contrôle des règles de sécurité, un volume trop important étant impossible à maîtriser par les administrateurs (voir “beware the volume”).
• L’administration quotidienne de la sécurité est beaucoup plus réactive : une seule action de l’administrateur sécurise instantanément toutes les applications.
  Exemple : on ajoute la règle “Les commerciaux peuvent consulter les factures”. On donne alors la permission fonctionnelle “CanViewInvoice” au rôle “Sales”. Cette règle se propage instantanément à tout le SI. Aucune action n’est nécessaire de la part des développeurs : toutes les applications connaissent la permission “CanViewInvoice” et se sécurisent automatiquement.

Préférez ouvrir des portes, plutôt que les fermer

Il y a deux philosophies possibles pour définir des droits accès:

1. Fermer des portes : par défaut, toutes les fonctionnalités sont accessibles. On donne alors des restrictions à certains utilisateurs, pour limiter leur accès aux fonctionnalités sensibles.
2. Ouvrir des portes : par défaut, aucune fonctionnalité n’est accessible. On donne alors l’autorisation à certains utilisateurs d’accéder à certaines fonctionnalités.

Par défaut, les développeurs tendent à utiliser des restrictions (fermer des portes):

1. Dans un premier temps, ils créent et testent leur application sans se préoccuper des droits d’accès. Toutes les fonctionnalités sont alors accessibles. Ils définissent ensuite des restrictions pour ajouter une couche de sécurité et protéger certaines fonctionnalités sensibles avant de déployer l’application.
2. Il y a en général beaucoup plus de fonctionnalités à autoriser (toutes sont utilisées tôt ou tard) que de fonctionnalités à interdire (seulement les plus sensibles). Il est donc plus long de définir des autorisations que de définir des restrictions.

Par contre, l’utilisation d’autorisations (ouvrir des portes) offre un meilleur niveau de sécurité:

1. Failles de sécurité : Une stratégie de type “ouvrir des portes” limitera les failles de sécurité et facilitera leur détection : si l’administrateur oublie d’autoriser une fonctionnalité, l’utilisateur ne pourra pas l’utiliser et le signalera immédiatement au support. A l’inverse (fermer des portes), si l’administrateur oublie de donner une restriction, il laissera l’utilisateur accéder à une fonctionnalité sensible et créera une faille de sécurité. Ces failles seront difficiles à détecter, car l’utilisateur ne s’en rend pas compte (ou ne le signale pas).  Elles peuvent donc se multiplier et perdurer longtemps avant que les équipes IT ne les détectent.
2. Conflits de droits d’accès : les droits d’accès sont en général regroupés par paquets (rôles ou sets de permissions) avant d’être assignés aux utilisateurs. Il existe souvent des recouvrements entre deux paquets (lorsque tous les deux contrôlent une même fonctionnalité). Il pourra en résulter des conflits - par exemple un paquet autorise l’accès à une fonctionnalité, alors qu’un autre le restreint - le résultat est alors imprévisible et incohérent, et pourra créer de nouvelles failles de sécurité.
   Parmi toutes les combinaisons possibles, seuls les paquets d’autorisations ne créent jamais de conflit. Dans le pire des cas, on autorise plusieurs fois l’accès à la même fonctionnalité, ce qui n’a aucune incidence sur la sécurité, ni sur l'expérience utilisateur.

En conclusion:

1. Si le niveau de sécurité requis est faible, que les permissions sont peu nombreuses (une seule application par exemple) et mutuellement exclusives (pas de risque de conflit), vous pouvez utiliser des restrictions.
2. Dans tous les autres cas - et en particulier si vous n’êtes pas certains des besoins à venir - il est fortement recommandé d’utiliser des autorisations.

Minimiser le volume des données de sécurité

Quand on pose les bases d’un nouveau système, on cherche souvent à couvrir tous les besoins, présents ou à venir, ce qui tend à le complexifier. Les développeurs se focalisent alors sur des questions de court terme - la faisabilité technique du système - au détriment des obstacles de long terme, tels que le poids de son administration quand le système montera en charge.

C’est pourquoi le coût d’administration d’un système de sécurité est souvent supérieur à celui de sa création : il gère un volume de règles et de données de sécurité important, dont la maîtrise à long terme sera un véritable challenge pour les administrateurs : ils risquent en effet d’en perdre le contrôle et de laisser apparaître des failles de sécurité...

Comment éviter ce problème ?

• Impossible d’éviter l’intervention humaine : elle seule permet d’analyser tous les cas de la vraie vie, prendre les bonnes décisions et trouver le meilleur compromis entre sécurité du système et productivité des utilisateurs.
• On pourra réduire le volume des données de sécurité sans dégrader l’efficacité du système. C’est l’objectif des suggestions proposées dans ce chapitre.
• On pourra aussi les répartir parmi plusieurs administrateurs, pour réduire le volume géré par personne (voir le chapitre sur la délégation de l’administration).

Simple is beautiful

Prenons un exemple simple :

• Un système composé de 10 applications (desktop, sites web ou service web)
• 100 formulaires ou fonctions par application
• 10 permissions par formulaire ou fonction

Le nombre total de permissions pour ce système sera de 10*100*10 = 100,000. Si le système sert 1,000 utilisateurs, l’administrateur devra donc superviser 100 millions de relations possibles entre utilisateurs et permissions! Difficile à imaginer dans un contexte où la liste des permissions et des utilisateurs évolue constamment...

Il est donc critique de réduire le volume d’informations à surveiller.

On pourra procéder de la façon suivante :

1. Regrouper les droits d’accès en paquets cohérents :
1. Rôles pour les cas simples
2. Hiérarchie de permission sets + rôles pour les cas complexes
2. Regrouper les utilisateurs selon des critères organisationnels (par département ou par fonction par exemple).  Il est important que la hiérarchie des groupes utilisateurs reflètent leur répartition réelle au sein de l’organisation. Le travail des administrateur pour les placer dans des groupes en sera facilité, réduisant ainsi les risques d’erreur et les failles de sécurité.
3. Affecter des droits d’accès en donnant des rôles à des groupes utilisateurs. Les relations rôles/groupes seront incomparablement moins nombreuses que les relations permissions/utilisateurs, donc plus faciles à gérer et contrôler.
4. Répartir les utilisateurs entre plusieurs administrateurs locaux (voir plus loin “déléguer les opérations d’administration”).

Bénéfices attendus:

1. La gestion des permissions sera plus facile à superviser.
2. Les coûts d’administration seront réduits.
3. Les risques de perte de contrôle et de failles de sécurité sont moindres.

Déléguer des opérations d’administration

En répartissant les opérations de contrôle d’accès entre plusieurs personnes (Distributed Administration Model), on optimisera la productivité et la qualité de l’administration :

1. La charge de travail étant répartie, le volume d’information à gérer par personne est réduit, diminuant ainsi  les risques d’erreur.
2. On améliorera la qualité de l'administration en tirant parti (leveraging) des connaissances métiers spécifiques de chaque intervenant. Par exemple, un responsable de Business Unit sera le mieux placé pour connaître ses utilisateurs, leurs rôles dans l’organisation et les droits dont ils ont besoin.

Voici un exemple de répartition des tâches d’administration :

1. Spécification des droits d’accès : des spécialistes fonctionnel/métier spécifient les droits d’accès, et les regroupent en paquets cohérents.
2. Mise en œuvre (enforcement) des droits d’accès : Les développeurs transposent les droits d’accès en actions techniques, au sein de leur application : activer (ou désactiver) des contrôles, filtrer des données, etc.
3. Gestion des comptes utilisateurs :
1. Le responsable business (chef de service, responsable de site...) connaît les besoins de ses utilisateurs. Il adresse donc les demandes de création, désactivation ou suppression de comptes aux administrateurs habilités.
2. Dans certains cas (site web public par exemple), l’utilisateur peut créer son propre compte (Self Registration). Selon le niveau de sécurité requis, on peut lui donner automatiquement des droits d’accès par défaut, ou laisser l’administrateur valider son compte et lui donner des droits.
3. Pour des raisons de sécurité, les opérations de création, modification, suppression de comptes utilisateur sont confiées à une autorité centrale en charge de l’annuaire d’entreprise (Administrateur AD par exemple).
4. Si le système prévoit l’enrichissement des données utilisateurs (profil utilisateur), on délègue cette tâche aux personnes les mieux placées : les utilisateurs eux-mêmes ou leurs responsables business.
4. Affectation des droits d’accès :
1. L’assignation de droits d’accès est confiée au responsable business, qui connaît bien chaque utilisateur, ses fonctions et ses droits d’accès.
2. Un principe doit demeurer : un utilisateur ne peut définir lui-même ses propres droits. Le responsable business peut donner des droits à ses utilisateurs, mais pas à lui-même. Son rôle d’administrateur lui sera donc attribué par une autorité centrale en charge de la sécurité applicative.

Garder la trace des opérations importantes

Pour satisfaire aux exigences des standards de type SOX, HIPPA, etc. il faut garder la trace (log) des opérations réalisées par les utilisateurs et les administrateurs. On doit aussi documenter en temps réel les utilisateurs et leurs droit d’accès.

En 2008, une grande Banque a découvert une perte de 5 milliards d’Euros sur ses activités de marché. Le management a dû répondre aux questions suivantes : Qui a causé cette perte ? Qui l’a laissé faire ? D’autres traders peuvent-ils faire de même ?

Plus généralement, les normes nécessitent de répondre à trois questions :

• Qui a fait quoi, à une date ou sur une période donnée ?
• Qui a donné des droits d’accès, quand et à qui ?
• Qui peut faire quoi aujourd’hui ?

Pour que le système soit efficace, les mécanismes de trace et d’audit doivent être :

• Centralisés et communs à toutes les applications
• Indépendants des technologies utilisées pour les développer
• Accessibles par toutes les applications (pour tracer les opérations en temps réel).

Utilisables directement par tous les contrôleurs (pour auditer le système à tout moment, et sans dépendre des propriétaires de chaque application).

Séparer les données de sécurité de Développement, Test et Production

Plusieurs environnements distincts sont généralement nécessaires :

• Quand les applications évoluent, les permissions aussi. Les développeurs doivent alors mettre à jour les jeux de permissions existants. Ils le font dans un environnement de développement pour ne pas perturber la production.
• L’erreur est humaine. Chaque oubli ou fausse manipulation peut générer une faille sécurité. On validera donc les nouvelles permissions dans un environnement de test, reproduisant les caractéristiques de la production.
• Après validation, les nouvelles permissions seront déployées en production. On devra alors insérer les nouvelles permissions sans perturber les données de sécurité déjà en production (comptes utilisateurs et droits d’accès existants).
• Pour des raisons de sécurité, il faut scinder les responsabilités : le développeur peut modifier les permissions, mais ne peut les déployer en production. Seul le responsable d’exploitation peut le faire après leur validation par les testeurs.

Bâtir une infrastructure sécurisée et évolutive

Indépendance et évolutivité

Le système de sécurité doit être indépendant des technologies sur lesquelles reposeront les applications (actuelles et à venir). On pourra exposer des services web - consommés uniformément par toutes les applications - pour authentifier les utilisateurs, charger leurs permissions et tracer leurs opérations. Une bonne documentation et une API détaillée faciliteront sa mise en œuvre uniforme.

Modularité et flexibilité

Le système de sécurité devra être modulaire, pour s’adapter à toutes les architectures et règles de sécurité de l’entreprise. Selon le standard XACML (eXtensible Access Control Markup Language), un système de contrôle d’accès comportera les composants suivants :

• Policy Enforcement Point (PEP) : c’est l’endroit où les permissions utilisateur sont appliquées. Par exemple lorsque les droits d’accès imposent de restreindre certaines fonctionnalités de l’application. Le PEP protège l'application sécurisée.
• Policy Decision Point (PDP) : c’est le cœur du système de sécurité. Le PDP est l'endroit où les demandes d’accès sont évaluées et comparées aux permissions de l’utilisateur et aux règles de sécurité.
• Policy Information Point (PIP) : c’est un connecteur à une source d’information externe (Active Directory, base de données…), qui pourra être nécessaire pour traiter certaines demandes d’accès. 
  Par exemple:
  • Seuls les comptables peuvent créer une facture
  • John demande à créer une facture
  • Le PDP demande alors au PIP : John est-il un comptable?
• Policy Retrieval Point (PRP) : c’est le composant qui stocke les données de sécurité (base de données, dossier…).

Policy Administration Point (PAP) : c’est un outil d'administration. Par exemple, l’endroit où les permissions sont éditées et affectées aux utilisateurs.

Recommandations Supplémentaires (Identity Management)

Les points listés ci-dessous vont au-delà de la sécurité applicative, puisqu’ils touchent à la gestion des comptes utilisateurs, et peuvent s’appliquer à tous les aspects du contrôle d’accès. Pour autant, ils auront un impact déterminant sur le niveau de sécurité de vos applications et leur facilité d’administration.

Unifier les comptes utilisateurs

Faciliter la gestion des utilisateurs

Maintenir un comptes par utilisateur et par système impose de répéter les mêmes opérations pour chaque application (créer, modifier, désactiver, supprimer des comptes utilisateurs…).

Cela génère au minimum une charge de travail importante, et probablement des erreurs humaines (des comptes inutilisés restent actifs par exemple).

A l’inverse, conserver un seul compte par utilisateur, auquel seront associés tous ses droits d’accès, facilitera le travail des administrateurs en charge de maintenir la liste des utilisateurs actifs.

Réduire le coût des mots de passe

Centraliser les identités permet de réduire les coûts - cachés et importants - de gestion des mots de passes. Ces coûts sont estimés par Gartner entre $70 à $200 par utilisateur et par an!
Si chaque utilisateur dispose d’un compte par système il doit mémoriser autant de mots de passes. La plupart n’y arrivent pas (password fatigue), ce qui crée plusieurs problèmes:

1. Soit ils oublient fréquemment des mots de passe et font appel au helpdesk, consommant leur temps et celui du support.
2. Soit ils choisissent le même mot de passe pour tous leurs comptes, créant ainsi une faille de sécurité majeure : si le système le plus faible est piraté - tous n’ont pas le même niveau de sécurité - tous les systèmes sont immédiatement exposés, même les plus sensibles!
3. Certains choisissent enfin de noter leurs mots de passe (sur un post-it collé sous leur  écran par exemple)...inutile d’en expliquer l’impact sur le niveau de sécurité...

Elever le niveau de sécurité

L’authentification de l’utilisateur est la clef qui ouvre les portes des systèmes protégés. Par principe, de multiples systèmes offriront des niveaux de sécurité variables, dont certains seront peut-être insuffisants.

Centraliser la gestion des identités dans un système unique offrant un niveau de sécurité élevé, augmentera le niveau de protection global et réduira d’autant les risques d’intrusion.

Restera ensuite à définir ce que l’utilisateur à le droit de faire à l’intérieur de chaque  application (voir rôles et permissions)...

Supporter plusieurs types d’identité

Ne pas confondre un compte unique par utilisateur et un seul type de comptes pour tous les utilisateurs:

1. distinguer les différentes populations d’utilisateurs
2. choisir ce qui est le plus simple à gérer pour chaque population (workflow)
3. choisir pour chaque population le stockage d’identité le plus simple à administrer

Dans le cas de populations nécessitant différents types d’identités, le système de sécurité devra les prendre en compte sans ajouter de complexité à son utilisation pour toutes les parties prenantes:

1. Les permissions pourront être associées de façon identiques à tous types de comptes utilisateurs.
2. Un groupe utilisateurs - recevant des droits d’accès pourra contenir plusieurs types de comptes utilisateurs
3. Une même fenêtre de login permettra à l’utilisateur de choisir son identité pour s’authentifier.
4. Les outils d’audit pourront superviser de façon transversale et identique tous les comptes utilisateurs

Implémenter un Single Sign-On (SSO)

Qu'est-ce que le Single Sign-On

Les systèmes de Single Sign-On permettent aux utilisateurs d'accéder à plusieurs application après une première identification.
Les principales caractéristiques des systèmes de SSO sont :

1. 1 compte par utilisateur suffit à controler l'accès à plusieurs applications ou sites web.
2. Les utilisateurs s'identifient une fois et ont accès à toutes les applications sans s'identifier de nouveau.
3. Tout ou partie des informations de connexion (login et password par exemple) peuvent être mémorisés afin que l'utilisateur n'est pas besoin de les saisir de nouveau lors de leur prochaine visite.
4. Single Sign-off: une seule action est nécéssaire pour de déconnecter ou couper l'accès à plusieurs applications.

Il existe deux scenarios de base pour les sessions Single Sign-On (read more):

1. Login first - l'utilisateur commence par se loguer dans le SSO puis choisit une application à laquelle il veut accéder.
2. Application first - l'utilisateur essaie d'abord de se loguer à une application, mais parce qu'il ne sont pas encore authentifié, ils sont redirigés vers une page de login. Après une connexion réussie, ils sont redirigés vers l'application.

Bénéfices attendus

Le Single Sign-On simplifie bien sûr la vie des utilisateurs, mais vous pouvez vous attendre beaucoup plus :

1. Amélioration de la productivité des utilisateurs: ils n'ont pas besoin de se connecter plusieurs fois ni de mémorier plusieurs mots de passe pour une même identité.
2. Réduction des coûts: diminuer le nombre d'appels au support informatique ; moins de demandes pour réinitialiser les mots de passe oubliés
3. Amélioration de la productivité des développeurs : Le mécanisme de SSO doit être indépendant de l'application. Les développeurs n'ont donc pas à se soucier de l'authentification . Ils peuvent supposer qu'une fois qu'une demande d'accès à une application est accompagnée d'un nom d'utilisateur, l'authentification a déjà eu lieu.
4. Amélioration de la Sécurité:
1. Réduit l'hameçonnage car les utilisateurs ne sont pas habitués à saisir des mots de passe partout sans y penser.
2. L'authentification ne se fait qu'à un seul endroit, qui reçoit les informations de connexions de l'utilisateur. Les applications reçoivent seulement l'information indiquant si elles doivent donner l'accès ou non. Le fait que l'utilisateur ne se connecte qu'une seule fois limite également le nombre de transfert d'informations sensibles sur le réseau, sans oublier que le SSO implique généralement l'utilisation de canaux de communication sécurisés.