Note : le site officiel de cas par ja-sig est








télécharger 72.83 Kb.
titreNote : le site officiel de cas par ja-sig est
date de publication20.03.2018
taille72.83 Kb.
typeNote
ar.21-bal.com > documents > Note


Direction Générale de l'Administration

Direction des Technologies de l'Information

__________________________________________________________________________________________




Méta-annuaire

Présentation de la solution CAS de Web SSO du CoE

Ce document est la propriété du Conseil de l’Europe.

Il ne peut être reproduit ou communiqué sans accord préalable de l’auteur


Rédacteur

Version

Date de rédaction

Statut actuel

DIT

3.0

27/08/2009

validé



Sommaire

1 Préambule 3

2 Généralités sur le fonctionnement de CAS 4

2.1 Généralités 4

2.1.1 Le serveur CAS 4

2.1.2 Les navigateurs Web 4

2.1.3 Les clients CAS 4

2.2 Description du fonctionnement 4

2.2.1 Authentification d'un utilisateur 4

2.2.2 Accès à une ressource protégée après authentification 5

2.2.3 Accès à une ressource protégée sans authentification préalable 6

2.3 Architecture CAS mise en place au Conseil de l’Europe 7

2.3.1 Architecture technique mise en œuvre 7

2.3.2 Spécificité Intranet / Internet 7

2.3.3 Pages d’authentification 9

3 Fonctionnement détaillé 11

3.1 Mise en place de l’authentification 11

3.1.1 Login 11

3.1.2 Validation du « Service Ticket » 11

3.1.3 Gestion de l’identité 12

3.1.4 Schéma des flux lors d’une première authentification 12

3.2 Mise en place de la prolongation de session 14

3.2.1 Prolongation 14

3.2.2 Schéma des flux lors d’une prolongation de session 14

3.3 Gestion du Logout 16

3.4 Spécificités 17

3.4.1 Impersonification : gestion des comptes « administrateurs » 17

3.4.2 Gestion des applications « mixtes » 17

3.4.3 Page d’accueil 17


1Préambule


Dans le cadre de la mise en œuvre d’une solution de Web Single Sign On (WebSSO) pour l’accès à ses applications web, le Conseil de l’Europe a choisi la solution CAS (Central Authentication Service).

CAS est une solution Opensource de SSO Web développée à l’origine par l’université de Yale puis reprise par la communauté JA-SIG.

Note : le site officiel de CAS par JA-SIG est http://www.jasig.org/cas.

Les applications s’intègrent à CAS soit au niveau applicatif au moyen de bibliothèques disponibles pour différents langages (.NET, PHP, ASP, C, Java…) ou d’un client CAS connu déjà intégré dans l’application, soit directement au niveau d’un serveur Web (module Apache pour CAS par exemple).

Note : le site officiel des clients disponibles est : http://www.ja-sig.org/wiki/display/CASC/Home

2Généralités sur le fonctionnement de CAS

2.1Généralités

2.1.1Le serveur CAS


L'authentification est centralisée sur un serveur CAS. Ce serveur est le seul acteur du mécanisme CAS qui relaye les mots de passe des utilisateurs à l’annuaire centralisé LDAP. Son rôle est double :

  • Authentifier les utilisateurs ;

  • Certifier l'identité de la personne authentifiée aux clients CAS par son ticket de service.

2.1.2Les navigateurs Web


Les navigateurs Web doivent satisfaire les contraintes suivantes pour bénéficier de tout le confort de CAS :

  • Permettre le protocole HTTPS

  • Savoir stocker des cookies (en particulier, les cookies privés ne devront être retransmis qu'au serveur les ayant émis pour garantir la sécurité du mécanisme CAS).

Ces exigences sont satisfaites par tous les navigateurs classiquement utilisés, à savoir Microsoft Internet Explorer (depuis la version 5.0), Netscape Navigator (depuis la version 4.7) et Mozilla Firefox (depuis la première version).

2.1.3Les clients CAS


Une application Web munie d'une bibliothèque cliente ou d’un client CAS intégré est alors appelé « client CAS ». Il ne délivre les ressources qu'après s’être assuré que le navigateur qui l'accède se soit authentifié auprès du serveur CAS. Le client s’assure également à intervalle régulier de la validité de la session CAS.

2.2Description du fonctionnement

2.2.1Authentification d'un utilisateur


Un utilisateur non authentifié, ou dont l'authentification a expiré, et qui accède au serveur CAS se voit proposer un formulaire d'authentification (figure 6), dans lequel il est invité à entrer ses informations d’authentification (login/email et mot de passe).

Ci-dessous, les échanges mis en œuvre :



Figure 1 - Premier accès d'un navigateur au serveur CAS (sans TGC)

Si les informations d’authentification sont correctes, le serveur renvoie au navigateur un cookie appelé TGC (Ticket Granting Cookie) :



Figure 2 - Authentification d'un navigateur auprès du serveur CAS

Le Ticket Granting Cookie (TGC) est le passeport de l’utilisateur auprès du serveur CAS. Le TGC, à une durée de vie limitée à celle de la session du navigateur (Une fois le navigateur fermé, la session est perdue), il est le moyen pour les navigateurs d'obtenir auprès du serveur CAS des tickets pour les clients CAS sans avoir à se ré-authentifier.

C'est un cookie privé (n'est jamais transmis à d'autres serveurs que le serveur CAS) et protégé (toutes les requêtes des navigateurs vers le serveur CAS se font sous HTTPS).

Comme tous les tickets utilisés dans le mécanisme CAS, il est opaque (ne contient aucune information sur l'utilisateur authentifié) : c'est un identifiant de session entre le navigateur et le serveur CAS.

2.2.2Accès à une ressource protégée après authentification


Ci-dessous, la séquence d’accès à une ressource protégée par CAS :



Figure 3 - Redirection par le serveur CAS d'un navigateur vers un client CAS après authentification

Les étapes sont :

  • [1] : Le navigateur tente d'accéder à une ressource protégée sur un client CAS ;

  • [2] : Le client redirige le navigateur vers le serveur CAS dans le but d'authentifier l'utilisateur ;

  • [3] : Le navigateur, précédemment authentifié auprès du serveur CAS, lui présente le TGC (rappel : un cookie) ;

  • [4] : Sur présentation du TGC, le serveur CAS délivre au navigateur un Service Ticket (ticket de service ou ST) ; c'est un ticket opaque, qui ne transporte aucune information personnelle ; il n'est utilisable que par le « service » (l'URL) qui en a fait la demande ;

  • [5] : Dans le même temps, le serveur CAS redirige le navigateur vers le service demandeur en passant le Service Ticket en paramètre CGI ;

  • [6] et [7] : Le Service Ticket est alors validé auprès du serveur CAS par le client CAS, directement en HTTP ;

  • [8] : la ressource est délivrée au navigateur.

Note : toutes les redirections présentées sont complètement transparentes pour l’utilisateur qui ne les voit pas et a l'impression d'accéder directement à la ressource désirée, sans authentification comme le montre la figure ci-dessous :



Figure 4 - Vision par l’utilisateur du mécanisme d’authentification

Le Service Ticket (ST) est le passeport de l’utilisateur auprès d'un client CAS. Il est non rejouable (ne peut être présenté qu'une seule fois au serveur CAS), limité à un seul client CAS et sa durée de vie est très limitée dans le temps (typiquement quelques secondes).

2.2.3Accès à une ressource protégée sans authentification préalable


Si l’utilisateur n'est pas déjà authentifié auprès du serveur CAS avant d'accéder à une ressource, son navigateur est, comme précédemment, redirigé vers le serveur CAS, qui lui propose alors un formulaire d'authentification.

Lors de la soumission du formulaire par le navigateur au serveur CAS, si les informations fournies sont correctes, le serveur CAS :

  • Délivre un TGC (Ticket Granting Cookie) au client, qui lui permettra ultérieurement de ne pas avoir à se ré-authentifier ;

  • Délivre au client un Service Ticket à destination du client CAS ;

  • Redirige le client vers le client CAS.

On voit ainsi qu'il n'est pas nécessaire d'être préalablement authentifié pour accéder à une ressource protégée.

2.3Architecture CAS mise en place au Conseil de l’Europe

2.3.1Architecture technique mise en œuvre


Dans le cadre de l’architecture mise en place au Conseil de l’Europe, tous les nœuds qui constituent la plateforme d’authentification sont redondés pour garantir une continuité de service :

  • Le rôle du référentiel « utilisateur » est joué par le Méta-annuaire (annuaire Microsoft ADAM) id.coe.int, qui est redondé, et dont l’alimentation est assurée par le moteur de synchronisation Microsoft Forefront Identity Manager (FIM) à partir des différentes bases de comptes Active Directory du Conseil de l'Europe ;

  • Deux serveurs CAS sont montés en cluster actif-passif (si le serveur actif tombe, le serveur passif prend automatiquement le relais mais les utilisateurs perdent leur session et doivent se ré-authentifier) ;

  • Les serveurs CAS sont placés derrière le reverse proxy qui est également redondé en mode actif-passif.

2.3.2Spécificité Intranet / Internet


Certains comportements sont différents suivant la provenance du client (connexion depuis l’Intranet ou connexion depuis Internet).

Provenance

Ticket Granting Cookie TGC

Validité de la page d’authentification

Intranet

Type : persistant (écrit sur le disque).

Validité : 1 mois.

4 heures.

Internet

Type : non persistant (non écrit sur le disque).

Validité : 4 heures et expiration à la fermeture du navigateur web.

5 minutes : afin d’empêcher les revalidation de formulaire via un retour arrière.



Figure 5 - Architecture du Conseil de l’Europe

2.3.3Pages d’authentification


Les pages d’authentification CAS ont été personnalisées comme le montrent les figures ci-après :



Figure 6 - Page de Login CAS pour le COE



Figure 7 - Page de Logout CAS pour le COE



Figure 8 - Page d’erreur CAS pour le COE

3Fonctionnement détaillé

3.1Mise en place de l’authentification

3.1.1Login


Pour authentifier l’utilisateur, l’application doit rediriger l’utilisateur vers le serveur CAS, l’url (le service à valider) doit être soumise comme paramètre à cette requête. C’est cette url qui sera utilisée par le serveur CAS pour revenir ensuite sur la page souhaitée :

https://cas.coe.int/cas/login?service=http://app1.coe.int

Le serveur CAS se charge ensuite d’authentifier l’utilisateur et renvoie un « Service Ticket » sous la forme d’un paramètre qu’il faut récupérer en vue de sa validation future.

http://app1.coe.int?ticket=ST-12345678

3.1.2Validation du « Service Ticket »


La durée de vie de ce ticket est de 20 secondes, l’application doit le valider en faisant un appel à la page « ServiceValidate » du serveur CAS :

https://cas.coe.int/cas/serviceValidate?service=http://app1.coe.int&ticket=ST-12345678

Un flux XML est récupéré en réponse à cette requête, il contient l’email de l’utilisateur authentifié dans une balise  :





john.doe@coe.int





Note : le « Service ticket » ne peut être validé qu’une seule fois et a une durée de vie de 20 secondes. En cas d’expiration ou d’erreur, le flux XML retourne un code d’erreur :





le ticket ST-XXXXXXXXX; est inconnu





Ci-dessous les autres codes d’erreurs pouvant survenir :

INVALID_REQUEST 

Certains paramètres sont faux ou non présents

INVALID_TICKET 

Le ticket soumis n'est pas valide, le détail est précisé dans le bloc de la réponse XML retournée.

INVALID_SERVICE

Le ticket soumis est valide mais le service spécifié ne correspond pas au ticket présenté. Le ticket est tout de même invalidé, il faudra redemander un ticket pour ce service.

INTERNAL_ERROR

Une erreur interne au serveur CAS s'est produite durant la validation du ticket.

3.1.3Gestion de l’identité


Une fois l’identité de l’utilisateur connue, il faut la stocker dans une variable de session propre à l’application selon les mécanismes standards à sa technologie.

La gestion des autorisations et rôles doit ensuite être faite par l’application en se basant sur cette variable de session.

3.1.4Schéma des flux lors d’une première authentification


Le diagramme ci-dessous présente les différents appels et vérification à effectuer lors d’une première authentification de l’utilisateur par une application ayant à utiliser le SSO Web.


3.2Mise en place de la prolongation de session

3.2.1Prolongation


Toutes les 5 minutes (durée devant pouvoir être modifiée via un fichier de configuration), un nouveau « Service ticket » doit être demandé puis validé auprès du serveur CAS afin de rafraîchir le contenu de la variable de session applicative.

En effet, si la session CAS :

  • est toujours valide : cela prolongera la session CAS (glissement de la session de l’utilisateur sur le serveur CAS) ;

  • n’est plus valide (expiration, ou logout depuis une autre application) : la session applicative doit être vidée, et ainsi le mécanisme redirigera automatiquement l’utilisateur sur la page de login.

3.2.2Schéma des flux lors d’une prolongation de session


Le diagramme ci-dessous présente les différents appels et vérification à effectuer lors d’une prolongation de session ou lorsqu’une nouvelle application a besoin d’identifier un utilisateur possédant déjà une session auprès du serveur CAS.


3.3Gestion du Logout


La gestion du logout est particulière puisque le logout applicatif seul est inutile. En effet, le mécanisme CAS reconnecte automatiquement l’utilisateur à l’application lorsque celui-ci tente d’y accéder. Pour être pris en compte, le logout applicatif doit être couplé au logout CAS, mais dans ce cas, la session CAS sera fermée pour toutes les autres applications.

Il est donc nécessaire de choisir entre les deux possibilités suivantes :

  • Logout SSO + logout applicatif. La session applicative doit être supprimée et le logout CAS effectué comme ci-dessus.

  • Logout SSO seul (un lien vers la page https://cas.coe.int/cas/logout/ puis fermer son navigateur ou être redirigé vers la page d’accueil anonyme de l’application si elle existe (voir le paragraphe ci-après Page d’accueil ). Dans ce cas, la session applicative est conservée.

Préconisation : Pour chaque application souhaitant intégrer le SSO web, le comportement doit être, si possible, le suivant :

  • Les boutons "logout" actuels doivent être renommés, en "fermer cette application". Le rôle de ce bouton sera d'enregistrer le travail en cours puis de rediriger l'utilisateur vers la page d’accueil de l’application si elle en possède une ou vers le portail Intranet/Internet si l’application n’en possède pas.

A noter que si l'utilisateur n'utilise pas ce bouton et ferme directement l'onglet du navigateur, tout comme actuellement, le travail en cours ne sera pas sauvegardé.

  • Un second bouton "logout SSO" ou "fermer ma session SSO" doit être ajouté à chaque application. Ce bouton permet à l'utilisateur de se déconnecter de sa "session SSO". Lorsque l'utilisateur cliquera sur ce nouveau bouton, un popup lui sera présenté pour lui signaler que cette opération va fermer non seulement cette application mais aussi toutes les autres applications ouvertes.

Exemple de popup :



Texte en version française :

Attention : vous allez fermer toutes vos applications web et risquez de perdre toutes vos données non sauvegardées.

Voulez-vous vraiment vous déconnecter et fermer votre session SSO ?

Texte en version anglaise:

Warning: you will close all your web applications and may lose all your unsaved data.

Do you really want to sign out and close your SSO session?

3.4Spécificités

3.4.1Impersonification : gestion des comptes « administrateurs »


Si l’application possède des comptes « administrateurs » qui ne sont pas référencés dans le système central d’authentification, l’application devra les gérer de manière exceptionnelle. L’accès à cette application par les utilisateurs de ces comptes devra se faire depuis un formulaire de login différent de celui offert par le WebSSO.

3.4.2Gestion des applications « mixtes »


Certaines applications peuvent être « mixtes », c’est-à-dire comporter une partie non restreinte et une partie restreinte nécessitant une authentification.

L’accès à cette application par les utilisateurs doit se faire en anonyme pour la partie non restreinte et en WebSSO CAS pour la partie restreinte.

3.4.3Page d’accueil


Pour répondre aux problématiques précédentes (gestion des comptes administrateur et gestion des applications « mixtes »), il faut mettre en place un point d’entrée : une page de bienvenue (portail d’accueil) en accès anonyme.

Cette page devra présenter un lien permettant de s’authentifier : un clic sur ce lien aura pour effet de démarrer le mécanisme d’authentification WebSSO CAS.

Si l’accès via des comptes administrateurs est nécessaire, un lien vers la partie « administration » pourra également être présent sur cette page d’accueil.

En cas d’authentification préalable via le WebSSO CAS, cette page devra en informer, de manière suffisamment claire, l’utilisateur en présentant des informations personnelles, par exemple : «Bienvenue John Doe».

Enfin, le cas échéant cette page pourra être utilisée pour orienter les utilisateurs en fonction de leurs catégories : utilisateurs internes au Conseil de l’Europe, utilisateurs externes, administrateurs de l’application, etc…

Le diagramme ci-dessous précise quelles sont les redirections à effectuer lorsqu’une page d’accueil est utilisée :



Fin du document

similaire:

Note : le site officiel de cas par ja-sig est iconLe désir en institution
«Interpréter l’enfant», IL fut beaucoup question de la pratique en institution orientée par le discours analytique, expérience singulière...

Note : le site officiel de cas par ja-sig est iconAvertissement
«Copix». Ce site est initialement hébergé par wamp, au sein d’un environnement de développement, sur la base de la version 4 de Copix....

Note : le site officiel de cas par ja-sig est iconTerminale stmg (sig)

Note : le site officiel de cas par ja-sig est iconRapport du site
«connexion permanente à Internet» n’est pas directement induite par le cahier des charges

Note : le site officiel de cas par ja-sig est iconVers une meilleure compréhension des attentes en magasin inférées...
«configuration» anticipée d’un point de vente à la lumière de la symbolique de l’enseigne et suite à l’expérience vécue par le client...

Note : le site officiel de cas par ja-sig est iconAdresse ip : Définition
«masque» sur une adresse ip. Le but d'un nom de domaine est de retenir et communiquer facilement l'adresse d'un ensemble de serveurs...

Note : le site officiel de cas par ja-sig est iconPar Daniel letouzey* (* Lycée Marie Curie -vire, secrétaire de la Régionale de Basse-Normandie)
«licence consommateur». L’original, en anglais, est disponible en ligne sur le site de la

Note : le site officiel de cas par ja-sig est iconLe site portail du professeur de fle
«rues commerçantes». La recherche peut se faire par adresse, par thème et par recherche cartographique

Note : le site officiel de cas par ja-sig est iconNote: En cas d’utilisation d’accessoires en céramique pour la réalisation...

Note : le site officiel de cas par ja-sig est iconHistoséminaire Pathologie Vésicale Cas n°1 et 2
«superficielles», n’infiltrant pas le muscle. L’aspect histologique conditionne leur pronostic et leur prise en charge. Une tumeur...








Tous droits réservés. Copyright © 2016
contacts
ar.21-bal.com