1 / 43

Formation CAS

Formation CAS. Julien Marchal. Plan. Le but CAS un SSO WEB L’intérêt de CAS Mécanisme Technologies utilisées Les authentifications Installation de base Certificats Développement d’un petit client CAS (php) Clients phpCAS JAVA CASFilter Mod_auth_cas Pam_cas REST SSOut

giona
Download Presentation

Formation CAS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Formation CAS, mars 2009 Formation CAS Julien Marchal

  2. Plan • Le but • CAS un SSO WEB • L’intérêt de CAS • Mécanisme • Technologies utilisées • Les authentifications • Installation de base • Certificats • Développement d’un petit client CAS (php) • Clients • phpCAS • JAVA CASFilter • Mod_auth_cas • Pam_cas • REST • SSOut • Audit et statistiques • Redondance et failover Formation CAS, Paris, 9 et 10 mars 2009

  3. Le but SSO Single Sign-On authentification unique et unifiée Sécurité protéger le mot de passe ne pas transmettre le mot de passe aux applications un seul point d’authentification Plusieurs mécanismes d’authentification LDAP, fichier plat, X509 Formation CAS, Paris, 9 et 10 mars 2009

  4. Le but Service Service Appli n°3 Appli n°3 Appli n°2 Appli n°2 Appli n°1 Appli n°1 Navigateur web Navigateur web avec CAS sans CAS Formation CAS, Paris, 9 et 10 mars 2009

  5. CAS un SSO WEB Centralisation de l’authentification en un point Le serveur d’authentification Redirections HTTP transparentes Application vers serveur d’authentification Serveur d’authentification vers les applications Passage d’information lors de ces redirections Cookies Paramètres CGI Formation CAS, Paris, 9 et 10 mars 2009

  6. L’intérêt de CAS Le mot de passe n’est JAMAIS transmis aux applications Utilisation de ticket « opaque » et à usage unique (à la Kerberos) Mécanisme n-tiers Utilisation de services à travers des applications clientes sans transmission du mot de passe Librairies clientes Java filter, jsp, php, perl, python. Dot net, module Apache et PAM Formation CAS, Paris, 9 et 10 mars 2009

  7. Mécanisme 1ère authentification d’un utilisateur Serveur CAS Navigateur web HTTPS Formation CAS, Paris, 9 et 10 mars 2009

  8. Mécanisme 1ère authentification d’un utilisateur Référenciel utilisateurs Identifiant Mot de passe HTTPS TGC • TGC : Ticket Granting Cookie • Passeport du navigateur auprès du serveur CAS • Cookie privé et protégé (le seul cookie utilisé dans CAS ; il n’est pas obligatoire) • Ticket opaque rejouable TGC Formation CAS, Paris, 9 et 10 mars 2009

  9. MécanismeAccès à une application (après authentification) ID ST TGC ST ST HTTPS • ST : Service Ticket • Passeport du navigateur auprès du client CAS • Ticket opaque non rejouable • Limité dans le temps TGC Formation CAS, Paris, 9 et 10 mars 2009

  10. MécanismeAccès à une application (après authentification) ID ST TGC ST ST HTTPS • Toutes les redirections sont transparentes pour l’utilisateur TGC Dans la pratique… Formation CAS, Paris, 9 et 10 mars 2009

  11. MécanismeAccès à une application (avant authentification) HTTPS formulaire d’authentification Formation CAS, Paris, 9 et 10 mars 2009

  12. MécanismeAccès à une application (avant authentification) ID ST TGC ST ST identifiantmot de passe HTTPS • Il n’est pas nécessaire de s’être préalablement authentifié auprès du serveur CAS pour accéder à une application TGC Formation CAS, Paris, 9 et 10 mars 2009

  13. MécanismeRemarques • Une fois le TGC acquis, l’authentification devient transparente pour l’accès à toutes les autres applications CAS-ifiées • Une fois authentifié pour une application, une session applicative est mise en place Formation CAS, Paris, 9 et 10 mars 2009

  14. MécanismeFonctionnement n-tiers ID PGT ST ST PGT TGC Formation CAS, Paris, 9 et 10 mars 2009

  15. MécanismeFonctionnement n-tiers ID PT PT PT PGT • PGT : Proxy Granting Ticket • Passeport d'un utilisateur pour une application auprès du serveur CAS • Ticket opaque rejouable PGT ST TGC Formation CAS, Paris, 9 et 10 mars 2009

  16. Technologies utilisées • JAVA • SPRING • REST • HTTP • SSL Formation CAS, Paris, 9 et 10 mars 2009

  17. Les authentifications • Le choix du/des mode(s) d’authentification est laissé à l’initiative de l’administrateur • Configuration XML pour ajouter des « handlers » d’authentification • Possibilité de développer ses propres couches d’authentification X509 Active directory SPNEGO Fichier plat RADIUS JAAS JDBC LDAP Formation CAS, Paris, 9 et 10 mars 2009

  18. Installation de base • TP 1, 2 et 3 Formation CAS, Paris, 9 et 10 mars 2009

  19. Certificats • Pour fonctionner en SSO, CAS a besoin d’une connexion HTTPS • Le mieux est d’utiliser des certificats signés par des autorités reconnus par les JVM • On peut aussi utiliser des certificats dit auto-signés • Les clients CAS ont besoin de connaître le certificat du serveur CAS afin de faire des connexions HTTPS directes vers lui Formation CAS, Paris, 9 et 10 mars 2009

  20. Certificats • TP4 : Nous allons utiliser des certificats auto-signés Formation CAS, Paris, 9 et 10 mars 2009

  21. Développement d’un petit client CAS (php) • Afin de mieux comprendre le fonctionnement CAS, nous allons développer un client en PHP Formation CAS, Paris, 9 et 10 mars 2009

  22. Développement d’un petit client CAS Algorithme de base Arrivée requête Si un ticket en GET Pas de session ou pas de nom utilisateur dans la session Redirection vers CAS Requête HTTP vers CAS Validation du ticket Analyse XML Récupération Nom utilisateur Affichage nom utilisateur Récupération du Nom utilisateur En session Formation CAS, Paris, 9 et 10 mars 2009

  23. Développement d’un petit client CAS (php) • En cas d’erreur, CAS va répondre : <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationFailure code="..."> Optional authentication failure message </cas:authenticationFailure> </cas:serviceResponse> • En cas de succès <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationSuccess> <cas:user>NetID</cas:user> </cas:authenticationSuccess> </cas:serviceResponse> • TP5 Formation CAS, Paris, 9 et 10 mars 2009

  24. Développement d’un petit client CAS (php - proxy) • Nous allons développer le client en php permettant de faire un fonctionnement proxy • Pour se faire, le serveur CAS aura besoin de faire une connexion HTTPS directe vers le client Formation CAS, Paris, 9 et 10 mars 2009

  25. Développement d’un petit client CASAlgorithme de base (proxy) Arrivée requête Si un PGT-IOU en GET Si un ticket en GET Pas de session ou pas de nom utilisateur dans la session Récupération PGT Stockage en session Redirection vers CAS Requête HTTP vers CAS Validation du ticket Demande proxy Analyse XML Récupération Nom utilisateur Et du PGT-IOU Demande D’un PT Récupération du Nom utilisateur En session Affichage nom utilisateur Stockage PGT-IOU Formation CAS, Paris, 9 et 10 mars 2009

  26. Développement d’un petit client CAS (php - proxy) • En cas de succès <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> <cas:authenticationSuccess> <cas:user>NetID</cas:user> <cas:proxyGrantingTicket>PGTIOU</cas:proxyGrantingTicket> </cas:authenticationSuccess> </cas:serviceResponse> • Lors de la demande d’un PT <cas:serviceResponse> <cas:proxySuccess> <cas:proxyTicket>ST-957-ZuucXqTZ1YcJw81T3dxf</cas:proxyTicket> </cas:proxySuccess> </cas:serviceResponse> • TP 6 Formation CAS, Paris, 9 et 10 mars 2009

  27. Utilisation de clientphpCAS • http://www.ja-sig.org/wiki/display/CASC/phpCAS • Librairie pour PHP • Gère le proxy • Gère le logout CAS Formation CAS, Paris, 9 et 10 mars 2009

  28. Utilisation de clientphpCAS include_once('CAS.php'); phpCAS::setDebug(); // initialize phpCAS phpCAS::client(CAS_VERSION_2_0,‘localhost',443,‘/cas'); phpCAS::setNoCasServerValidation(); phpCAS::forceAuthentication(); if (isset($_REQUEST['logout'])) { phpCAS::logout(); } ?> <h1>Successfull Authentication!</h1> <p>login is <b><?php echo phpCAS::getUser(); • TP 7 : Mise en place de phpCAS Formation CAS, Paris, 9 et 10 mars 2009

  29. Utilisation de clientJava CAS Filter • Le client CAS Java existe sous forme de filter • 4 filtres • CASFilter : va gérer l’authentification • CASValidation: va gérer la validation des tickets • CASWrapper : va mettre à disposition le username dans le remoteuser • CAS Single Sign Out Filter : va gérer les requêtes de logout Formation CAS, Paris, 9 et 10 mars 2009

  30. Utilisation de clientJava CAS Filter • Le CASFilter <filter> <filter-name>CASFilter</filter-name> <filter-class> org.jasig.cas.client.authentication.AuthenticationFilter </filter-class> <init-param> <param-name>casServerLoginUrl</param-name> <param-value>https://localhost/cas/login</param-value> </init-param> </filter> Formation CAS, Paris, 9 et 10 mars 2009

  31. Utilisation de clientJava CAS Filter • Le CASValidation <filter> <filter-name>CASValidation</filter-name> <filter-class> org.jasig.cas.client.validation.Cas20ProxyReceivingTicketValidationFilter </filter-class> <init-param> <param-name>casServerUrlPrefix</param-name> <param-value>https://localhost/cas</param-value> </init-param> <init-param> <param-name>redirectAfterValidation</param-name> <param-value>true</param-value> </init-param> </filter> Formation CAS, Paris, 9 et 10 mars 2009

  32. Utilisation de clientJava CAS Filter • Le CASWrapper <filter> <filter-name>CASWrapper</filter-name> <filter-class> org.jasig.cas.client.util.HttpServletRequestWrapperFilter </filter-class> </filter> Formation CAS, Paris, 9 et 10 mars 2009

  33. Utilisation de clientJava CAS Filter • Le CAS Single Sign Out Filter <filter> <filter-name>CAS Single Sign Out Filter</filter-name> <filter-class>org.jasig.cas.client.session.SingleSignOutFilter</filter-class> </filter> • TP 8 : Mise en place d’un client JAVA CAS Filter Formation CAS, Paris, 9 et 10 mars 2009

  34. Utilisation de clientmod_auth_cas • Mod_auth_cas est un module apache LoadModule auth_cas_module /usr/lib/apache2/modules/mod_auth_cas.so <IfModule mod_auth_cas.c> CASVersion 2 CASDebug Off CASValidateServer Off CASLoginURL https://localhost/cas CASValidateURL https://localhost/cas/serviceValidate CASCookiePath /tmp/cas/ CASTimeout 7200 CASIdleTimeout 3600 CASCacheCleanInterval 1800 </IfModule> • TP9 : mod_auth_cas Formation CAS, Paris, 9 et 10 mars 2009

  35. Utilisation de clientpam_cas IMAP PT PAM_CAS ID PT • Pam_cas est un module pam • PAM : Pluggable Authentication Modules • Peut servir pour des accès à des services linux (FTP, IMAP, etc…) Formation CAS, Paris, 9 et 10 mars 2009

  36. Utilisation de clientpam_cas • /etc/pam.d.imap auth sufficient /lib/security/pam_cas.so \-simap://imap.univ.fr \-f/etc/pam_cas.conf auth sufficient /lib/security/pam_ldap.so auth required /lib/security/pam_pwdb.so shadow nullok account required /lib/security/pam_pwdb.so shadow nullok • /etc/pam_cas.conf host localhost port 443 uriValidate /proxyValidate ssl on debug off proxy https://localhost/casProxy.php trusted_ca /Cert/ac-racine.pem Formation CAS, Paris, 9 et 10 mars 2009

  37. Interface REST • CAS possède une interface REST • Celle-ci permet de faire du CAS sans pour autant parler des langages lourds tel que XML • Elle est destinée à des clients en ligne de commande par exemple • TP 10 : Activer REST Formation CAS, Paris, 9 et 10 mars 2009

  38. Interface REST • Fonctionnement • Un post vers https://localhost/cas/rest/tickets avec username=tp1&password=tp1 • Extraire de la réponse une url https://localhost/cas/rest/tickets/TGT-X-XXXXX (le TGT) • On refait un post vers l’url extraite avec service=imap://test.fr • On obtient un PT • TP 11 : client REST Formation CAS, Paris, 9 et 10 mars 2009

  39. Le SSOut • CAS implémente depuis sa version 3 un mécanisme de Single Sign OUT • A chaque authentification, il mémorise l’url de retour et le ticket • Lors d’un logout du CAS (appel url /logout), il va envoyer à chaque service (POST) une requête SAML contenant le ticket à delogguer • A charge à l’application de le traiter Formation CAS, Paris, 9 et 10 mars 2009

  40. Le SSOut <samlp:LogoutRequest ID="[RANDOM ID]" Version="2.0" IssueInstant="[CURRENT DATE/TIME]"> <saml:NameID>@NOT_USED@</saml:NameID> <samlp:SessionIndex>[SESSION IDENTIFIER]</samlp:SessionIndex> </samlp:LogoutRequest> Formation CAS, Paris, 9 et 10 mars 2009

  41. Audit et statistiques • Le CAS permet d’avoir des logs d’accounting ainsi que des statistiques. • Les exemples fournis sont simplistes mais permettent de se faire une idée • Pour se faire, le serveur CAS se base sur inspektr • http://code.google.com/p/inspektr/ • TP 12 : statistiques et audit Formation CAS, Paris, 9 et 10 mars 2009

  42. Redondance et failover • De base, CAS gère ses tickets en mémoire • Donc si il s’arrête, tout l’historique est perdu, ce qui met les clients dans un état instable. • Il est possible d’externaliser la gestion des tickets dans un daemon memcache • Dans ce cas, il est possible de faire du load balancing et du failover Formation CAS, Paris, 9 et 10 mars 2009

  43. Redondance et failover Memcache pour stocker les tickets JK JK Serveur AUTH1 CAS TCP TCP memcached Repcached / TCP Frontal Serveur AUTH2 CAS memcached Formation CAS, Paris, 9 et 10 mars 2009

More Related