SQLI. Solution Santé. IdeoSSO - Intégration d'un client IdeoSSO 22/10/2007. Confidentiel SQLI Solution Santé 28/03/2008 P 1/35

Transcription

1 SQLI Solution Santé IdeoSSO - Intégration d'un client IdeoSSO 22/10/2007 Confidentiel SQLI Solution Santé 28/03/2008 P 1/35

2 Historique Historique des versions du document Version / Date Auteur Commentaire Date validation / Approbateur V1.0 17/10/2007 M. BRISOU Première version du document V1.2 22/10/2007 M. BRISOU Nouvelle version du document suite aux remarques de S. PERRINEAU Confidentiel SQLI Solution Santé 28/03/2008 P 2/35

3 Interlocuteurs VOS REFERENCES (Style : «Références») Groupe SQLI Agence de Dijon 10, rond point de la Nation Immeubre Apogée B Dijon : Fax : Martial BRISOU Chef de projets E-santé : mbrisou@sqli.com DOCUMENTS DE REFERENCE Intitulé Version Date Commentaire DOCUMENTS JOINTS Intitulé Version Date Commentaire Confidentiel SQLI Solution Santé 28/03/2008 P 3/35

4 Sommaire SOMMAIRE SOMMAIRE PRÉAMBULE Objectifs du document PRÉSENTATION GÉNÉRALE Présentation IdeoSSO Schéma général Cas d utilisation d une application cliente Identification de l utilisateur Identification de l utilisateur pour un mandataire Utilisation du mode mandataire Déconnexion de l utilisateur Les clients CAS et IdeoSSO Web Les navigateurs Internet Les différents clients CAS INTÉGRATION DE CLIENTS CAS La documentation officielle INTÉGRATION DU CLIENT CAS J2EE SERVLET La documentation officielle Téléchargement Système requis Installation Configuration Cas d utilisation Identification de l utilisateur Identification de l utilisateur pour un mandataire Utilisation du mode mandataire Déconnexion de l utilisateur INTÉGRATION DU CLIENT CAS PHP La documentation officielle Téléchargement Système requis Installation et configuration Cas d utilisation Identification de l utilisateur Identification de l utilisateur pour un mandataire...erreur! Signet non défini Utilisation du mode mandataire...erreur! Signet non défini Déconnexion de l utilisateur INTÉGRATION DU CLIENT CAS J2EE JSP La documentation officielle...22 Confidentiel SQLI Solution Santé 28/03/2008 P 4/35

5 Sommaire 6.2 Téléchargement Système requis Configuration Cas d utilisation Identification de l utilisateur Identification de l utilisateur pour un mandataire Déconnexion de l utilisateur INTÉGRATION DU CLIENT CAS POUR UN REVERSE PROXY La documentation officielle Téléchargement Cas d utilisation Identification d un utilisateur Identification d un utilisateur pour un mandataire Utilisation du mode mandataire Déconnexion LES SERVICES OFFICIELS DU SERVEUR CAS Le service servicevalidate, proxyvalidate Le service proxy LES SERVICES SUPPLÉMENTAIRES DU SERVEUR IDEOSSO Le service userinformation Le service keepgrantoralive Le service deletegrantor ANNEXES Liens Web Filtres du client IdeoSSO SQLI Les filtres Le filtre CASFilter ou CASValidateFilter Le filtre InformationFilter Le filtre KeepGrantorAliveFilter Le filtre DeleteGrantorFilter Confidentiel SQLI Solution Santé 28/03/2008 P 5/35

6 Préambule 1 PREAMBULE 1.1 Objectifs du document L objectif du document est de décrire l intégration d un client IdeoSSO à une application existante. Les différents points abordés seront : le fonctionnement général du serveur IdeoSSO les cas d utilisations mis en oeuvre par un serveur IdeoSSO l intégration des clients CAS officiels compatibles avec IdeoSSO Confidentiel SQLI Solution Santé 28/03/2008 P 6/35

7 Présentation générale 2 PRESENTATION GENERALE 2.1 Présentation IdeoSSO Le serveur IdeoSSO est basé sur l architecture CAS 2.0. Cette architecture CAS 2.0 est décrite par le projet Open Source : Central Authentication Service. Une partie des services offerts par IdeoSSO sont donc compatibles avec les clients CAS supportant l architecture CAS 2.0. Actuellement, la version du serveur CAS intégrée à IdeoSSO est 3.0.3RC Schéma général Le schéma suivant présente une architecture d une plate-forme Web disposant d un serveur IdeoSSO. Dans la suite des cas d utilisations, nous ne présenterons pas les flux passant par le reverse proxy. 2.3 Cas d utilisation d une application cliente Cette partie présente les différents cas d utilisation entre une application cliente et le serveur IdeoSSO. Confidentiel SQLI Solution Santé 28/03/2008 P 7/35

8 Présentation générale Identification de l utilisateur L authentification d un utilisateur est le fait qu il soit reconnu par le serveur IdeoSSO. Dans l architecture mise en œuvre, c est le serveur IdeoSSO qui permet l authentification de l utilisateur grâce aux différents modes d authentifications proposés. Ensuite, les clients IdeoSSO identifie cet utilisateur en validant des jetons de service (ou ticket de service) auprès du serveur. Cette partie est l identification de l utilisateur. Ces jetons sont eux-mêmes distribués par le serveur IdeoSSO. Processus d identification d un utilisateur via un serveur IdeoSSO : 1 : L utilisateur souhaite se connecter à l application 1, il utilise son navigateur Internet pour se connecter à l application. Confidentiel SQLI Solution Santé 28/03/2008 P 8/35

9 Présentation générale 2 : Le navigateur Internet ne présente pas de Service Ticket (ST) à l application, l application 1 redirige alors l utilisateur vers le serveur IdeoSSO pour obtenir un ST pour l application 1. 3 : Pour obtenir un Service Ticket pour l application 1, le navigateur doit préalablement avoir obtenu un Granting Ticket (TGT). Dans le cas présent, le navigateur ne peut pas présenter de TGT au serveur IdeoSSO. Le serveur propose alors le formulaire d authentification à l utilisateur. Le flux utilisé est un flux HTTPS. La validation de ce formulaire permettra d obtenir un TGT. 4 : L utilisateur remplit le formulaire d authentification choisi. Ce formulaire peut être un formulaire classique, par Identifiant/Mot de passe ou un formulaire évolué, par carte CPS. Ensuite, il soumet ce formulaire, par flux HTTPS, au serveur IdeoSSO. 5-6: Le serveur IdeoSSO authentifie l utilisateur grâce aux données entrées dans le formulaire d authentification et aux données présentes dans l annuaire de sécurité. Lorsque l utilisateur est authentifié, le serveur IdeoSSO envoie un TGT et un ST non re-jouable pour l application 1 au navigateur Internet et redirige le navigateur vers l application 1. 7 : L application 1 valide le ST auprès du serveur IdeoSSO. Cette validation permet à l application d obtenir l identité de l utilisateur qui se présente à l application. Elle est faite par des flux chiffrés par HTTPS. 8 : Le serveur IdeoSSO donne l identifiant de l utilisateur à l application 1. 9 : L application 1 identifie donc l utilisateur au sein de son système. Elle présente donc la page d accueil personnalisée de l application à utilisateur Identification de l utilisateur pour un mandataire Un mandataire (ou proxy) est une application cliente IdeoSSO qui peut elle-même effectuer une authentification auprès d un service client IdeoSSO. C'est-à-dire qu il est capable de proposer aux services des jetons qui serviront à la validation auprès du serveur IdeoSSO. Pour qu une application soit mandataire, il faut que le serveur IdeoSSO lui délivre un jeton de proxy. Pour cela, il faudra configurer les applications afin qu elle puisse recevoir ce jeton. Confidentiel SQLI Solution Santé 28/03/2008 P 9/35

10 Présentation générale " "#! * ( +, ) ' % $ & Processus d identification d un utilisateur pour un mandataire via un serveur IdeoSSO : 1 : L utilisateur souhaite se connecter au mandataire 1, il utilise son navigateur Internet pour se connecter au mandataire. 2 : Le navigateur Internet ne présente pas de ST au mandataire, le mandataire 1 redirige alors l utilisateur vers le serveur IdeoSSO pour obtenir un ST pour le mandataire 1. 3 : Pour obtenir un ST pour le mandataire 1, le navigateur doit préalablement avoir obtenu un TGT. Dans le cas présent, le navigateur ne peut pas présenter de TGT au serveur IdeoSSO. Le serveur propose alors le formulaire d authentification à l utilisateur. Le flux utilisé est un flux HTTPS. 4 : L utilisateur remplit le formulaire d authentification choisi. Ce formulaire peut être un formulaire classique, par Identifiant/Mot de passe ou un formulaire évolué, par carte CPS. Ensuite, il soumet ce formulaire, par flux HTTPS, au serveur IdeoSSO. 5 : Le serveur IdeoSSO authentifie l utilisateur grâce aux données entrées dans le formulaire d authentification et aux données présentes dans l annuaire de sécurité. De plus, il soumet une requête d un Proxy Granting Ticket (PGT) au mandataire. Confidentiel SQLI Solution Santé 28/03/2008 P 10/35

11 Présentation générale 6-7: L utilisateur est authentifié, le serveur IdeoSSO envoie un TGT et un ST non re-jouable pour le mandataire 1 au navigateur Internet et redirige le navigateur vers le mandataire 1. 8 : Le mandataire 1 valide le ST auprès du serveur IdeoSSO. Cette validation permet à l application d obtenir l identité de l utilisateur qui se présente au mandataire. Elle est faite par des flux chiffrés par HTTPS. De plus, elle permet d obtenir le PGT-IOU qui est en quelques sortes la deuxième partie du Proxy Granting Ticket. Ce PGT-IOU permet au mandataire de retrouver le PGT distribuer par le serveur IdeoSSO. 9 : Le serveur IdeoSSO donne l identifiant de l utilisateur au mandataire 1, ainsi que le PGT-IOU. 10 : Le mandataire 1 identifie donc l utilisateur au sein de son système. Il présente donc la page d accueil personnalisée de l application à utilisateur Utilisation du mode mandataire La validation des jetons fournis par un mandataire retournera l identité de l utilisateur authentifié aux applications. Il faut bien sûr s être connecté au mandataire avec le processus d authentification IdeoSSO. L avantage de ce fonctionnement est qu il n y a pas de rejoue de formulaire, le mot de passe de l utilisateur ne transite pas entre les services. &! " % ' ) $ * Processus d utilisation de Proxy Ticket par un mandataire via un serveur IdeoSSO : 0 : L utilisateur est préalablement authentifié auprès du serveur IdeoSSO via le processus de connexion à un mandataire. Confidentiel SQLI Solution Santé 28/03/2008 P 11/35

12 Présentation générale 1 : L utilisateur souhaite utiliser un service tiers via le mandataire 1. Il utilise son navigateur pour se connecter au mandataire 1. 2 : Le mandataire présente son PGT auprès du serveur IdeoSSO afin d obtenir un Proxy Ticket (PT). 3 : Le serveur IdeoSSO retourne le PT au mandataire pour le service 1 et l utilisateur connecté. 4 : Le mandataire 1 présente le PT au service tiers 1. Le service tiers 1 est aussi un client IdeoSSO, il est capable de valider les PT auprès du serveur de la plate-forme. 5 : Le service tiers 1 valide le PT auprès du serveur IdeoSSO. Cette validation permet au service tiers 1 d obtenir l identité de l utilisateur qui se présente. Elle est faite par des flux chiffrés par HTTPS. 6 : Le serveur IdeoSSO donne l identifiant de l utilisateur au service tiers 1. L utilisateur est alors connecté au service tiers 1 via le mécanisme IdeoSSO. 7 : Le mandataire 1 utilise le service tiers 1 en étant connecté avec le compte de l utilisateur. 8 : Le mandataire 1 présente la page de résultat au navigateur de l utilisateur Déconnexion de l utilisateur Lorsque l utilisateur souhaite se déconnecter d une application cliente, 2 cas de figures sont possibles : Déconnexion totale : La demande fait en sorte que l on soit totalement déconnecté du serveur IdeoSSO. L utilisateur devra alors s authentifier à nouveau pour accéder aux autres applications clientes. Déconnexion partielle : On se déconnecte de l application cliente seulement. C'est-à-dire que l application cliente prend en compte le fait que le délai de validité est bien expirée, néanmoins si l utilisateur souhaite se reconnecter à l application, c est le mécanisme IdeoSSO qui sera lancé car le navigateur Internet possède un TGC. Il n aura plus besoin de s authentifier à nouveau mais son environnement de travail dans l application cliente sera vierge comme une première connexion. Confidentiel SQLI Solution Santé 28/03/2008 P 12/35

13 Présentation générale Processus de déconnexion partielle d une application cliente IdeoSSO : A : L utilisateur fait une requête de déconnexion sur l application 1. B : L application 1 déconnecte l utilisateur de l application. Cette déconnexion ne déconnecte pas l utilisateur du serveur IdeoSSO. Processus de déconnexion totale d une application cliente IdeoSSO : 1 : L utilisateur fait une requête de déconnexion sur l application 1. 2: L application 1 déconnecte l utilisateur de l application. De plus, elle redirige le navigateur vers le service de déconnexion du serveur IdeoSSO. Le navigateur Internet présente alors le TGT au serveur IdeoSSO. Confidentiel SQLI Solution Santé 28/03/2008 P 13/35

14 Présentation générale 3 : Le serveur IdeoSSO détruit le TGT du navigateur. L utilisateur est alors totalement déconnecter du serveur IdeoSSO. 2.4 Les clients CAS et IdeoSSO Web Les navigateurs Internet Les navigateurs doivent satisfaire les contraintes suivantes pour bénéficier de tout le confort d un serveur IdeoSSO et des clients IdeoSSO (ou CAS) : disposer d'un moteur de chiffrement leur permettant d'utiliser le protocole HTTPS savoir effectuer des redirections HTTP et interpréter le langage JavaScript savoir stocker des cookies. En particulier, les cookies privés ne devront être retransmis qu'au serveur IdeoSSO les ayant émis pour garantir la sécurité du mécanisme d authentification Les différents clients CAS L architecture logicielle mise en œuvre pour les clients dépend fortement des applications clientes IdeoSSO. Les différents clients CAS existant de nos jours, compatibles en partie avec IdeoSSO, sont : Java Cas Client : Bibliothèque de client CAS pour les applications J2EE phpcas : Bibliothèque de client CAS pour les applications PHP perlcas : Bibliothèque de client CAS pour les applications PERL pam_cas : Module d authentification CAS pour un service UNIX mod_cas : Module d authentification CAS pour le serveur Web Apache Vu l étendue des technologies disposant de client CAS, il semble alors possible de développer des clients CAS pour toutes les technologies le permettant. Confidentiel SQLI Solution Santé 28/03/2008 P 14/35

15 Intégration de clients CAS 3 INTEGRATION DE CLIENTS CAS Le serveur IdeoSSO est basé sur l architecture CAS 2.0. Les clients CAS existants sont donc compatibles avec le serveur IdeoSSO. Toutefois, ces clients n implémentent pas les services supplémentaires fournis par le serveur IdeoSSO. Dans la suite du document, nous présenterons donc l intégration des clients CAS aux applications. 3.1 La documentation officielle La documentation officielle sur l intégration des clients CAS se trouve à l adresse suivante : Confidentiel SQLI Solution Santé 28/03/2008 P 15/35

16 Intégration du client CAS J2EE Servlet 4 INTEGRATION DU CLIENT CAS J2EE SERVLET 4.1 La documentation officielle La documentation officielle sur l intégration du client CAS J2EE se trouve à l URL suivante : Téléchargement L archive contenant le client CAS J2EE se trouve à l URL suivante : Système requis La mise en œuvre d un client CAS J2EE est simple. Ce client utilise le système de filtres défini dans les spécifications de l API Java Servlet 2.3 (inclus dans J2EE 1.3). Il est donc très facilement intégrables à une application J2EE. 4.4 Installation Pour installer ce client dans une application J2EE, il suffit d ajouter le jar au CLASSPATH de l application. Pour cela, il faut le copier dans le répertoire WEB-INF/lib de l application Web J2EE. Il est possible d ajouter ces jars dans le fichier META-INF/application.xml d un EAR si les applications sont déployées au sein d un EAR. C est la seule installation à faire sur une application J2EE pour mettre en place le client CAS J2EE. 4.5 Configuration Un filtre J2EE s exécute à chaque requête HTTP faites à l application. Il suffit de configurer le fichier descripteur de déploiement web.xml pour prendre en compte ces nouveaux filtres. Le configuration a ajouté dans le fichier web.xml est la suivante : <filter> <filter-name>cas Filter</filter-name> <filter-class>edu.yale.its.tp.cas.client.filter.casfilter</filter-class> <init-param> <param-name>edu.yale.its.tp.cas.client.filter.loginurl</param-name> <param-value> </init-param> <init-param> <param-name>edu.yale.its.tp.cas.client.filter.validateurl</param-name> <param-value> Confidentiel SQLI Solution Santé 28/03/2008 P 16/35

17 Intégration du client CAS J2EE Servlet </init-param> <init-param> <param-name>edu.yale.its.tp.cas.client.filter.servicename</param-name> <param-value> </init-param> </filter> <filter-mapping> <filter-name>cas Filter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> Les paramètres obligatoires du filtre CASFilter sont : Nom du paramètre Description Exemple edu.yale.its.tp.cas.cli ent.filter.loginurl edu.yale.its.tp.cas.cli ent.filter.validateurl edu.yale.its.tp.cas.cli ent.filter.serviceurl L URL de la page de connexion au serveur IdeoSSO. L URL de la servlet de validation des ST. L identifiant de l application cliente CAS. Cet identifiant est une URL Les paramètres optionnels du filtre CASFilter sont : Nom du paramètre Description Exemple edu.yale.its.tp.cas.cli ent.filter.authorizedpr oxy edu.yale.its.tp.cas.cli ent.filter.proxycallbac kurl edu.yale.its.tp.cas.cli ent.filter.wraprequest edu.yale.its.tp.cas.cli ent.filter.renew Les proxys autorisés pour l application cliente. L URL du récepteur de PGT de l application cliente. Si true, alors le filtre enveloppe la request J2EE et la méthode getremoteuser() retourne l identifiant de l utilisateur connecté. Force la ré-authentification au serveur IdeoSSO. True or false True or false Confidentiel SQLI Solution Santé 28/03/2008 P 17/35

18 Intégration du client CAS J2EE Servlet 4.6 Cas d utilisation Identification de l utilisateur Après l exécution du client CAS J2EE et après la validation du ticket auprès du serveur IdeoSSO, les attributs suivants se trouvent en session : Nom de l attribut Description Classe : Exemple edu.yale.its.tp.cas.client.filter. receipt edu.yale.its.tp.cas.client.filter. user L objet receipt indiquant que l identification de l utilisateur s est bien déroulé. L identité de l utilisateur connecté. CASReceipt. String : mbrisou L application peut donc récupérer l identifiant de l utilisateur connecté avec le code suivant : HttpSession session = request.getsession(); String userid = session.getattribute(casfilter.cas_filter_user); Si le paramètre edu.yale.its.tp.cas.client.filter.wraprequest est égal à true. Alors, il est possible de récupérer directement l identifiant de connexion à partir de la request. String uid = request.getremoteuser(); Ce code de récupération d identifiant peut être intégré dans la première servlet appelée de l application. Ensuite, l application pourra authentifier le compte utilisateur en local grâce à cette identifiant Identification de l utilisateur pour un mandataire Si l application cliente est un mandataire CAS, il faut ajouter des paramètres supplémentaires aux filtres. C est le même filtre CASFilter qui est utilisé pour l identification pour un mandataire CAS. Afin d assurer la réception du PGT, il faut définir dans le fichier web.xml, la servet de réception : <servlet> <servlet-name>proxyticketreceptor</servlet-name> <servlet-class>edu.yale.its.tp.cas.proxy.proxyticketreceptor</servlet-class> </servlet> <servlet-mapping> <servlet-name>proxyticketreceptor</servlet-name> <url-pattern>/receptor</url-pattern> </servlet-mapping> Les paramètres obligatoires du filtre CASFilter sont : Nom du paramètre Description Exemple Confidentiel SQLI Solution Santé 28/03/2008 P 18/35

19 Intégration du client CAS J2EE Servlet edu.yale.its.tp.cas.cli ent.filter.loginurl edu.yale.its.tp.cas.cli ent.filter.validateurl edu.yale.its.tp.cas.cli ent.filter.serviceurl edu.yale.its.tp.cas.cli ent.filter.authorizedpr oxy edu.yale.its.tp.cas.cli ent.filter.proxycallbac kurl L URL de la page de connexion au serveur IdeoSSO. L URL de la servlet de validation des ST. Doit être L identifiant de l application cliente CAS. Cet identifiant est une URL. Les proxys autorisés pour l application cliente séparé par un espace blanc. Doit contenir L URL du récepteur de PGT de l application cliente. Doit correspondre au mapping de la servlet de réception L identification pour un mandataire s effectue de la même manière que pour une application normale. Toutefois, il est possible de récupérer le PGT avec le code suivant : HttpSession session = request.getsession(); CASReceipt receipt = (CASReceipt) session.getattribute(casfilter.cas_filter_receipt); String pgtiou = receipt.getpgtiou(); Utilisation du mode mandataire Le mode mandataire permet d obtenir des PT pour l utilisateur connecté et pour un service tiers donné. Pour obtenir ce PT, il faut utiliser le code suivant : CASReceipt receipt = (CASReceipt) session.getattribute(casfilter.cas_filter_receipt); String pgtiou = receipt.getpgtiou(); String targetservice = " String proxyticket = ProxyTicketReceptor.getProxyTicket(pgtIou, targetservice); Le PT obtenu sera alors utilisé pour authentifier l utilisateur connecté au mandataire auprès d un service tiers client lui aussi du serveur IdeoSSO Déconnexion de l utilisateur Pour déconnecter du serveur IdeoSSO, il suffit de faire une redirection du navigateur vers l URL suivante : Le serveur IdeoSSO détruit alors le TGT pour le navigateur Internet. Confidentiel SQLI Solution Santé 28/03/2008 P 19/35

20 Intégration du client CAS PHP 5 INTEGRATION DU CLIENT CAS PHP 5.1 La documentation officielle La documentation officielle du client CAS pour l environnement PHP se trouve à l URL suivante : Téléchargement L archive contenant le client CAS PHP se trouve à l URL suivante : Actuellement, la version stable est la version Système requis L environnement requis pour le bon fonctionnement du client CAS PHP est : CURL 7.5+ compilé avec le support SSL PHP , PEAR DB Apache Installation et configuration L installation est simple. Il suffit d extraire les fichiers de l archive et de copier le sous répertoire source/cas dans un répertoire spécifique. Ce répertoire spécifique doit être dans le chemin de recherche PHP (include_path dans le fichier php.ini). Ensuite, pour activer le client CAS PHP dans vos pages PHP, il faut ajouter quelques lignes de codes au début de vos pages. 5.5 Cas d utilisation Identification de l utilisateur Pour identifier un utilisateur connecté au serveur IdeoSSO, il faut ajouter les lignes suivantes dans vos pages PHP : // import phpcas lib include_once('cas/cas.php'); // initialize phpcas Confidentiel SQLI Solution Santé 28/03/2008 P 20/35

21 Intégration du client CAS PHP phpcas::client(cas_version_2_0,'sante.sqli.com',443,'/ideosso/'); // force CAS authentication phpcas::forceauthentication(); L identifiant de l utilisateur connecté peut être obtenu à partir de l appel suivant : phpcas::getuser() Déconnexion de l utilisateur Pour déconnecter totalement l utilisateur, il faut rediriger l utilisateur vers l URL du service de déconnexion du serveur IdeoSSO. On utilise les lignes de codes suivantes : <a href="?logout=">logout</a> Confidentiel SQLI Solution Santé 28/03/2008 P 21/35

22 Intégration du client CAS J2EE JSP 6 INTEGRATION DU CLIENT CAS J2EE JSP 6.1 La documentation officielle La documentation officielle sur l intégration du client CAS JSP se trouve à l URL suivante : Téléchargement L archive contenant le client CAS JSP se trouve à l URL suivante : Système requis Pour exécuter le client CAS J2EE JSP, il faut un environnement supportant les taglibs. Le fichier TLD utilisé pour les taglibs se trouve dans l archive du client. 6.4 Configuration La seule configuration à faire pour utiliser les taglibs du client CAS J2EE JSP se trouve dans le fichier descripteur de déploiement web.xml. Il faut ajouter un paramètre d initialisation du contexte de l application JSP. <context-param> <param-name>edu.yale.its.tp.cas.servername</param-name> <param-value>monapplication.sqli.com</param-value> </context-param> Nom du paramètre Description Exemple edu.yale.its.tp.cas.ser vername Le hostname du serveur hébergeant l application. monapplication.sqli.com 6.5 Cas d utilisation Identification de l utilisateur Afin d identifier l utilisateur connecté au serveur IdeoSSO, il faut utiliser le tag AuthTag. <%@ taglib uri=" prefix="cas"%> <cas:auth var="netid" scope="session"> <cas:loginurl> Confidentiel SQLI Solution Santé 28/03/2008 P 22/35

23 Intégration du client CAS J2EE JSP <cas:validateurl> <cas:authorizedproxy> <cas:service> </cas:auth> Ce tag force l authentification auprès du serveur IdeoSSO. On retrouve sensiblement les mêmes paramètres que pour le client CAS J2EE Servlet. Les paramètres du tag sont : Nœud XML Description Exemple Attribut var Attribut scope Elément Cas:loginUrl Le nom de l attribut dans le scope contenant l identifiant du compte utilisateur connecté. Le scope contenant l identifiant du compte utilisateur connecté. L URL de la page de connexion au serveur IdeoSSO. netid page, session, request, application Elément Cas:validateUrl L URL de la servlet de validation des ST. Doit être Elément Cas:service Elément Cas:authoriezedProxy L identifiant de l application cliente CAS. Cet identifiant est une URL. Les proxys autorisés pour l application cliente séparé par un espace blanc. Doit contenir Après l exécution du tag, il est possible de récupérer l identifiant du compte utilisateur connecté au serveur IdeoSSO avec le code suivant dans la page JSP : <body> <p>welcome, <%= session.getattribute("netid") %>!</p> </body> Identification de l utilisateur pour un mandataire Le mode mandataire n est pas proposé pour le client CAS J2EE JSP Déconnexion de l utilisateur Pour déconnecter totalement l utilisateur, il faut faire une redirection d URL vers le service de déconnexion du serveur IdeoSSO. Pour cela, on utilise le tag LogoutTag dans la page JSP. Le code est le suivant : <cas:logout var="netid" scope="session" logouturl=" /> Confidentiel SQLI Solution Santé 28/03/2008 P 23/35

24 Intégration du client CAS J2EE JSP Les paramètres du tag sont : Nœud XML Description Exemple Attribut var Attribut scope Elément Cas:logoutUrl Le nom de l attribut dans le scope contenant l identifiant du compte utilisateur connecté. Le scope contenant l identifiant du compte utilisateur connecté. L URL du service de déconnexion au serveur IdeoSSO. netid page, session, request, application Confidentiel SQLI Solution Santé 28/03/2008 P 24/35

25 Intégration du client CAS pour un reverse proxy 7 INTEGRATION DU CLIENT CAS POUR UN REVERSE PROXY 7.1 La documentation officielle La documentation officielle sur l intégration du client CAS pour le mode reverse proxy d Apache se trouve à l URL suivante : Téléchargement L archive contenant le client CAS pour le mode reverse proxy d Apache se trouve à l URL suivante : Cas d utilisation Identification d un utilisateur Ce cas d utilisation est décrit dans la documentation officielle Identification d un utilisateur pour un mandataire Ce cas d utilisation n est pas supporté Utilisation du mode mandataire Ce cas d utilisation n est pas supporté Déconnexion Ce cas d utilisation n est pas supporté. Confidentiel SQLI Solution Santé 28/03/2008 P 25/35

26 Les services officiels du serveur CAS 8 LES SERVICES OFFICIELS DU SERVEUR CAS Les appels aux services se font en HTTPS, ce sont des requêtes HTTPS. Pour cela fonctionne, il faut que l application faisant appel aux services fasse confiance au certificat utilisé pour la requête. Si ce n est pas le cas, les connexions entre l application et le serveur IdeoSSO ne pourront pas être établies. Les réponses du serveur CAS sont des flux XML simple. Les services de la distribution officielle de CAS sont : servicevalidate, proxyvalidate proxy Nous allons maintenant décrire les interfaces de ces services. 8.1 Le service servicevalidate, proxyvalidate L URL de ce service est : ou Le tableau suivant présente les paramètres attendus par ce service. Nom du paramètre Description Exemple service L identifiant de l application ticket Le ticket à valider ST-X-YYYYYY. pgturl L URL du récepteur de proxygrantingticket. Le paramètre service correspond à l identifiant de l application faisant appel au service. Le paramètre ticket est un Proxy Ticket obtenu pour l application afin d utiliser le service. Le paramètre pgturl indique l URL du récepteur de Proxy Granting Ticket. Le service proxyvalidate va faire une requête sur cette URL pour fournir à l application le PGT. La réponse positive du service est : <cas:serviceresponse xmlns:cas=' <cas:authenticationsuccess> <cas:user>${userid}</cas:user> <cas:proxygrantingticket>${pgtiou}</cas:proxygrantingticket> <cas:proxies> <cas:proxy>${proxy.principal.id}</cas:proxy> </cas:proxies>... </cas:authenticationsuccess> <cas:proxy>${proxy.principal.idn}</cas:proxy> Confidentiel SQLI Solution Santé 28/03/2008 P 26/35

27 Les services officiels du serveur CAS </cas:serviceresponse> La variable userid correspond à l identifiant de l utilisateur connecté au serveur IdeoSSO. La variable pgtiou correspond à la deuxième partie du PGT. Ce pgtiou sera utilisé avec le PGT (posté sur pgturl) pour obtenir un Service Ticket grâce du service proxy. Les variables proxy.principal.idn indiquent la liste des mandataires autorisés pour l application. La réponse négative en cas de problème est : <cas:serviceresponse xmlns:cas=' <cas:authenticationfailure code='${code}'> ${description} </cas:authenticationfailure> </cas:serviceresponse> La variable code correspond au code de l erreur. La variable description correspond à la description de l erreur. 8.2 Le service proxy L URL de ce service est : Le tableau suivant présente les paramètres attendus par ce service. Nom du paramètre Description Exemple targetservice L identifiant de l application souhaitant un Service Ticket pgt Le PGT TGT-X-YYYYYY. Le paramètre targetservice correspond à l identifiant de l application souhaitant le Proxy Ticket. Le paramètre pgt est le Proxy Granting Ticket obtenu pour l application afin d utiliser le service. La réponse positive du service est : <cas:serviceresponse xmlns:cas=' <cas:proxysuccess> <cas:proxyticket>${ticket}</cas:proxyticket> </cas:proxysuccess> </cas:serviceresponse> La variable ticket correspond au Proxy Ticket délivré pour l application targetservice. Confidentiel SQLI Solution Santé 28/03/2008 P 27/35

28 Les services officiels du serveur CAS La réponse négative en cas de problème est : <cas:serviceresponse xmlns:cas=' <cas:proxyfailure code='${code}'> ${description} </cas:proxyfailure> </cas:serviceresponse> La variable code correspond au code de l erreur. La variable description correspond à la description de l erreur. Confidentiel SQLI Solution Santé 28/03/2008 P 28/35

29 Les services supplémentaires du serveur IdeoSSO 9 LES SERVICES SUPPLEMENTAIRES DU SERVEUR IDEOSSO Pour assurer une plus grande sécurité pour les applications clientes IdeoSSO, de nouveaux services ont été ajoutés au serveur IdeoSSO. La suite de cette partie présente ces nouveaux services. Les services supplémentaires sont les suivants : userinformation keepgrantoralive deletegrantor 9.1 Le service userinformation L URL de ce service est : Le tableau suivant présente les paramètres attendus par ce service. Nom du paramètre Description Exemple service L identifiant de l application ticket Le ticket à valider ST-X-YYYYYY. user L identifiant de l utilisateur connecté mbrisou Le paramètre service correspond à l identifiant de l application faisant appel au service. Le paramètre ticket est un Proxy Ticket obtenu pour l application afin d utiliser le service. Le paramètre user doit être égal à l identifiant de l utilisateur connecté. La réponse positive du service est : <cas:serviceresponse xmlns:cas=' <cas:informationsuccess> <cas:user>${username}</cas:user> <cas:userinformation> <cas:property name='${p.key}'>${p.value}</cas:property>... </cas:userinformation> </cas:informationsuccess> </cas:serviceresponse> Confidentiel SQLI Solution Santé 28/03/2008 P 29/35

30 Les services supplémentaires du serveur IdeoSSO La variable username correspond au paramètre user du service. Ensuite, c est un ensemble de clef/valeur (p.key/p.value) qui liste les informations de utilisateur. La réponse négative en cas de problème est : <cas:serviceresponse xmlns:cas=' <cas:informationfailure code='${code}'> ${description} </cas:informationfailure> </cas:serviceresponse> La variable code correspond au code de l erreur. La variable description correspond à la description de l erreur. 9.2 Le service keepgrantoralive L URL de ce service est : Le tableau suivant présente les paramètres attendus par ce service. Nom du paramètre Description Exemple service L identifiant de l application ticket Le ticket à valider pour utiliser le service ST-X-YYYYYY. egt Le ticket d expiration EGT-X-YYYYY. Le paramètre service correspond à l identifiant de l application faisant appel au service. Le paramètre ticket est un Proxy Ticket obtenu pour l application afin d utiliser le service. Lors du premier appel du service, le ticket d expiration n est pas connu. Il faut donc utiliser le paramètre ticket pour utiliser le service. La réponse positive du service retournera le ticket d expiration à utiliser pour les prochaines appels du service afin de maintenant en vie le Ticket Granting Ticket. La réponse positive du service est : <cas:serviceresponse xmlns:cas=' <cas:keepgrantoralivesuccess> <cas:keepgrantoralivetolerance>${expiregrantortimeout}</cas:keepgrantoralivet olerance> <cas:expireticket>${expiregrantorticket}</cas:expireticket> </cas:keepgrantoralivesuccess> Confidentiel SQLI Solution Santé 28/03/2008 P 30/35

31 Les services supplémentaires du serveur IdeoSSO </cas:serviceresponse> La variable expiregrantortimeout indique la durée de vie du ticket d expiration. Lorsque ce ticket d expiration expire, il va alors aussi faire expirer le TGT associé. La variable expiregrantorticket correspond au ticket d expiration qu il faudra préciser lors des prochains appels du service. La réponse négative en cas de problème est : <cas:serviceresponse xmlns:cas=' <cas:keepgrantoralivefailure code='${code}'> ${description} </cas:keepgrantoralivefailure> </cas:serviceresponse> La variable code correspond au code de l erreur. La variable description correspond à la description de l erreur. 9.3 Le service deletegrantor L URL de ce service est : Le tableau suivant présente les paramètres attendus par ce service. Nom du paramètre Description Exemple service L identifiant de l application ticket Le ticket à valider pour utiliser le service ST-X-YYYYYY. Le paramètre service correspond à l identifiant de l application faisant appel au service. Le paramètre ticket est un Proxy Ticket obtenu pour l application afin d utiliser le service. La réponse positive du service est : <cas:serviceresponse xmlns:cas=' <cas:deletegrantorsuccess> </cas:deletegrantorsuccess> </cas:serviceresponse> Aucune information supplémentaire n est retournée pour une réponse positive. Confidentiel SQLI Solution Santé 28/03/2008 P 31/35

32 Les services supplémentaires du serveur IdeoSSO La réponse négative en cas de problème est : <cas:serviceresponse xmlns:cas=' <cas:deletegrantorfailure code='${code}'> ${description} </cas:deletegrantorfailure> </cas:serviceresponse> La variable code correspond au code de l erreur. La variable description correspond à la description de l erreur. Confidentiel SQLI Solution Santé 28/03/2008 P 32/35

33 Annexes 10 ANNEXES 10.1 Liens Web Les liens suivants présentent le serveur CAS officiel et différents clients CAS : JASIG, EN : Le site officiel du serveur CAS du projet JASIG de Princeton. YALE, EN : Le site originel de CAS de Yale. ESUP-PORTAIL, FR : Un site français sur CAS pour l'intégration dans ESUP-PORTAIL Filtres du client IdeoSSO SQLI Le fonctionnement des clients WEB est simple. Ce sont des filtres placés devant l application cliente qui assure le mécanisme d authentification/identification. Ces filtres vont permettre de récupérer l identifiant de l utilisateur souhaitant se connecter à l application. Le système de filtres mis en œuvre pour le mécanisme IdeoSSO permet de développer rapidement des clients IdeoSSO pour des nouvelles technologies non supportées au jour d aujourd hui. Ils s enchaînent et ne sont pas tous obligatoires. C est en fonction des applications clientes IdeoSSO et de leurs besoins que l on configure ou pas certains filtres Les filtres CASFilter : récupère l identifiant d un utilisateur DeleteGrantorFilter : Détruit le TGT sur le serveur CAS InformationFilter : Récupère les informations d un utilisateur KeepAliveGrantorFilter : Maintient en vie le TGT sur le serveur CAS CASToXXFilter : Traduit les informations CAS pour l application cliente Confidentiel SQLI Solution Santé 28/03/2008 P 33/35

34 Annexes Le filtre CASFilter ou CASValidateFilter La tache de ce filtre est de récupérer d identifiant de l utilisateur. Pour effectuer ce travail, ce filtre demande au navigateur Internet un Service Ticket. Si le navigateur ne présente pas ce Service Ticket, alors il redirige le navigateur vers le serveur IdeoSSO pour obtenir un ticket. Le serveur génère le Service Ticket en fonction des habilitations grosses mailles et ensuite il redirige le navigateur vers l application. Le navigateur présente alors le Service Ticket au filtre CASFilter. Le filtre valide ce ticket auprès du serveur IdeoSSO pour obtenir l identifiant de l utilisateur. On rappelle que le Service Ticket à une durée de validité limitée. La validation se passe bien, l identifiant de l utilisateur et un reçu et mis en session Le filtre InformationFilter En plus de l identité de l utilisateur, les applications clientes ont besoin de connaître d autres informations sur le mode d authentification de l utilisateur. Le filtre InformationFilter récupère ses informations auprès du serveur IdeoSSO. Le mécanisme est sécurisé de la même manière que pour l identité de l utilisateur. Les flux sont chiffrés grâce au protocole HTTPS, un système d Information Ticket existe aussi. Ce filtre est utilisé au sein de la plate-forme pour informer l application du niveau d authentification utilisé par l utilisateur pour l identification au serveur IdeoSSO. Pour que ce filtre fonctionne, il faut que l utilisateur soit bien authentifié auprès du serveur IdeoSSO et que l application soit mandataire IdeoSSO. C'est-à-dire que ce filtre se place obligatoirement après le filtre CASFilter ou CASValidateFilter. Un reçu contient les informations supplémentaires à l identification d un utilisateur Le filtre KeepGrantorAliveFilter Ce filtre permet de maintenir en vie un Granting Ticket. Il est appelé à chaque appel de page de l application Web. Il permet de sécuriser le mécanisme d authentification IdeoSSO. Par exemple : Un utilisateur qui ne naviguerait pas (ie : absence) sur l application cliente IdeoSSO régulièrement verrait son Granting Ticket expiré. Une personne tierce ne pourrait alors pas utilisé le mécanisme d authentification IdeoSSO pour se connecter à une autre application avec l identité de l utilisateur absent. Ce filtre appelle régulièrement le service KeepGrantorAlive du serveur IdeoSSO pour lui indiquer de maintenir le Granting Ticket qui authentifie l utilisateur. Après un appel du service IdeoSSO, la durée maximale entre les appels lui est fournie. L application cliente IdeoSSO doit alors effectuer une requête auprès du serveur avant cette durée pour maintenir le ticket en vie. De plus, la session de l utilisateur peut être invalider si le maintient du Granting Ticket est impossible ou renvoi une erreur. Ce cas de figure se présente, si le ticket a déjà expiré ou si l utilisateur s est déjà déconnecté du serveur IdeoSSO. Ce filtre est utilisé pour assurer une plus grande sécurité des applications Le filtre DeleteGrantorFilter Ce filtre est utilisé pour forcer l expiration du Granting Ticket auprès du serveur IdeoSSO. Pour que cette partie du client soit le moins intrusif possible, ce filtre est déclenché grâce à un paramètre d URL. Le paramètre réservé pour ce filtre est : Confidentiel SQLI Solution Santé 28/03/2008 P 34/35

35 Annexes Paramètres casaction Description Paramètre réservé pour effectuer des actions dans les filtres Lorsque le paramètre casaction est égale à logout, alors le filtre DeleteGrantorFilter effectue une requête auprès du serveur IdeoSSO pour déconnecter l utilisateur. Ce filtre est utilisé lors de la déconnexion d un utilisateur d une application et du serveur IdeoSSO. Confidentiel SQLI Solution Santé 28/03/2008 P 35/35