czyli prosty sposób na SSO

Slides:



Advertisements
Podobne prezentacje
Longhorn Academy - AD Warszawa, 12 kwietnia 2007
Advertisements

Systemy Single Sign On Praca magisterska Opiekun:
Marcin Piotrowski. Najpopularniejszymi darmowymi przeglądarkami są Internet Explorer, Opera, Mozilla Firefox, Google Chrome.
Decyzje projektowe w .NET Framework
Tworzenie portali z wykorzystaniem technologii Sun Java Enterprise Systems Joanna Kosińska
WEB SERVICE Stefan Rutkowski.
ADAM Active Directory w trybie aplikacyjnym
SYSTEM ZARZĄDZANIA DANYMI PCSS 2003/2004 START.
Uwierzytelnianie i autoryzacja dostępu do portali
Projektowanie Aplikacji Komputerowych
Architektura systemu Gra strategiczna „Strusia Jama”
Office 365… (liveatedu) Andrzej Kowalczyk
Tomasz Smieszkoł - 15 stycznia
Eclipse jako IDE III a.
POZNAŃ SUPERCOMPUTING AND NETWORKING CENTER 1 Stan oraz koncepcje zadań realizowanych przez PCSS w ramach projektu LDAP PCSS, Lipiec 2002.
Protokoły sieciowe.
Proxy WWW cache Prowadzący: mgr Marek Kopel
Proxy (WWW cache) Sieci Komputerowe
Czym jest ISA 2004 Microsoft Internet Security and Acceleration Server 2004 jest zaawansowaną zapora filtrującą ruch w warstwie aplikacji. Razem z zaporą.
Longhorn - Usługi terminalowe
Enteprise Java Beans Emil Wcisło.
Microsoft Serwer - wprowadzenie
Architektura systemów wykorzystujących bazy danych (systemów bazodanowych) Wykład S. Kozielski.
Łukasz Trzciałkowski Bartłomiej Żuchowski Łukasz Pawłowski.
Novell Account Management 3.0
InfinitERP prezentacja systemu.
Jak przeżyć w Internecie? Czyli o bezpieczeństwie słów kilka… Michał Jankowski MJ Software Solutions Services.
Przemek Lewicki Piotr Linka Bartek Stasikowski
Integracja aplikacji z Facebookiem
Promotor: dr.inż. Aleksandra Werner
... CZYLI 100% HYBRID Tomasz Onyszko IAM Kung-Fu Evangelist.
IT Asset Management Service
Web Serwisy w praktyce Technologie internetowe ( )
Zarządzanie użytkownikami i praca w sieci lokalnej
MMH Mobile Projekt programistyczny 2013
Przeznaczenie produktu Opis funkcjonalności
Lokalne serwery www Serwer WWW - ang. Web server jest to oprogramowanie zainstalowane na serwerze podłączonym do sieci Internet. Używające technologii.
SYSTEM REJESTRACJI UŻYTKOWNIKÓW W SERWISIE INTERNETOWYM Bezpieczny i scentralizowany system uwierzytelniania, autoryzacji oraz zarządzania użytkownikami.
Arkadiusz Twardoń ZTiPSK
Rozdział 1: Wprowadzenie do systemu Windows 2000 i podstaw sieci
Serwery aplikacji Zope Tomcat. Składniki Zopea: Serwer Management interface Databases.
Projekt i implementacja uogólnionego mechanizmu Java RMI
Specjalizacja "Dziennikarstwo On-line„ HTML – XHTML – Warsztat Prowadzący: Dariusz Jaruga
Aby wejść na stronę główną Centrum Kształcenia Ustawicznego w Białymstoku, wpisz adres strony: (Rys.1.)
Systemy zarządzania treścią Wykład 5
Aplikacja od SaaS do IdaaS
Aplet JavaCard, pełniący funkcję autoryzującą (obowiązkowo) oraz identyfikującą (opcjonalna) Aplet wystawia metody pozwalające zarejestrować swoją obecność,
Toruń 28/ Po udanym uwierzytelnieniu IdP może przekazać do SP dodatkowe informacje o użytkowniku – IdP korzysta ze wskazanego źródła danych.
Toruń 28/ Zadania Federacji – Źródło informacji o IdP i SP – Podstawa zaufania – Tworzenie wspólnego języka – Dbanie o formalności – Przygotowanie.
Toruń 28/ Metadane SAML opisują, w jaki sposób ma być realizowana komunikacja pomiędzy IdP i SP Metadane są typowo prezentowane w postaci XML.
OWASP + DevOps, kilka przydatnych narzędzi
Jednym z podstawowych celów tworzenia sieci komputerowych jest współdzielenie zasobów, takich jak pliki lub drukarki. Każdy z takich zasobów musi być udostępniony,
Jak przeżyć w Internecie? Czyli o bezpieczeństwie słów kilka… Michał Jankowski MJ Software Solutions Services.
Toruń 28/ Usługodawcy dostępni poprzez PIONIER.Id mogą pochodzić z dwóch źródeł: – bezpośrednio z PIONIER.Id – z eduGAIN za pośrednictwem PIONIER-id.
Technologie programowania systemów internetowych
Toruń 28/ Shibboleth SP działa z poziomu serwera HTTP, jest niezależny od języka programowania, pozwala zintegrować dowolną aplikację ze środowiskiem.
Poczta elektroniczna "electronic mail") A.Ś.
1100 kont użytkowników 900 zasobów IT Systemy bazodanowe, poczta, etc. Support 20 kont serwisantów.
Active Directory Federation Services w Windows Server 2012 R2
Aplikacje mobilne w zastosowaniach medycznych
Wykonanie oraz zintegrowanie aplikacji z portalem społecznościowym Facebook Wykonanie projektu: Papok Patryk, Twardoń Krzysztof AiR 3/3.
Podstawy języka skryptów
POZNAŃ SUPERCOMPUTING AND NETWORKING CENTER 1 Zastosowanie LDAP w usługach WWW i Portali PCSS, 2002.
Zarządzanie tożsamością Promotor: Prof. dr hab. Zbigniew Kotulski 17 kwietnia 2007 Dominik Zasiewski.
Połączenia aplikacji Klient/Serwer
Moduł e-Kontroli Grzegorz Dziurla.
WYŻSZA SZKOŁA INFORMATYKI I ZARZĄDZANIA z siedzibą w Rzeszowie WYDZIAŁ INFORMATYKI STOSOWANEJ VPN TYPU KLIENT-SERWER, KONFIGURACJA NA MICROSOFT ISA 2006.
Maciej Wierzchowski Mariusz Sołtysiak. Założenia  Autentykacja użytkownia  Autentykacja dostawcy  Zapewnienie bezpiecznego połączenia.
Sponsorzy: Media:. Sponsorzy: Media: MBUM 9/11/2017 Mikrotik Beer User Meeting Integracja uwierzytelniania tunelu L2TP/IPsec z Microsoft Active Directory.
Realizacja aplikacji internetowych
Zapis prezentacji:

czyli prosty sposób na SSO CAS (Central Authentication Service) czyli prosty sposób na SSO Marcin Frankiewicz Projektant, APUS 10.01.2013, Kraków

Agenda Czym jest CAS - parę słów o Single Sign-On Bilety, usługi ... czyli architektura Modułowość, rozszerzalność, konfiguracja Integracja z CAS-em Konkurencyjne rozwiązania A jak to wszystko działa w praktyce … Pomoc, źródła, materiały

Parę słów o Single Sign-On Czym jest CAS Parę słów o Single Sign-On

Wiele niepowiązanych witryn, każda wymaga założenia konta, do każdej inny login i hasło.

Wiele witryn, każda własny login i hasło. Według badania* 31% uczestników badania używa jednego lub dwóch haseł do wszystkich serwisów. Wykradzenie jednego hasła daje dostęp włamywaczom do wszystkich danych użytkownika zgromadzonych w „chmurze”.  *http://www.kaspersky.com/downloads/pdf/kaspersky-lab_ok-consumer-survey-report_eng_final.pdf

Zamieniamy na jeden punkt autoryzacji – jeden login i hasło Za pomocą wspólnego repozytorium np. LDAP, problem nadal pozostaje, kompromitacja któregokolwiek z systemów powoduje kompromitację całej infrastruktury – dostęp do dowolnego elementu. Za pomocą serwera SSO – JEDNA formatka logowania !!

SSO Single Sign On

Single Sign On Proces uwierzytelnienia, pozwalający na jednokrotne wprowadzenie danych uwierzytelniających (np. login i hasło ), a następnie na dostęp do usług bez ich ponownego wprowadzania

Single Sign On Komfort Bezpieczeństwo Tylko jeden login/hasło (lub inne dane uwierzytelniające) Autoryzacja tylko raz, a potem dostęp do wielu aplikacji (Single Sign-In) Bezpieczeństwo Aplikacje nie „dotykają” hasła użytkownika Dane logowania użytkownika bezpieczne nawet przy kompromitacji aplikacji usługi Single Sign In http://en.wikipedia.org/wiki/List_of_single_sign-on_implementations

CAS (Central Authentication Service) Proste, elastyczne, rozszerzalne, otwarte SSO

JA-SIG CAS CAS - Central Authentication Service Scentralizowane, wieloprotokołowe WebSSO (Single Sign-On, Single Sign-In, Single Sign-Out) Początki w Yale University, obecnie JA-SIG Serwer CAS oraz klienci CAS Wsparcie dla wielu mechanizmów autoryzacji Delegowanie autoryzacji (proxy) Dobrze udokumentowane API, protokół oraz wsparcie Darmowy i otwarty JASIG - Java Architectures Special Interest Group Wieloprotokołowe - komunikacja za pomocą jednego lub kilku protokołów WebSSO – SSO dla aplikacji WEB owych Single Sign-On – jedno hasło Single Sign-In – jednokrotne logowanie Single Sign-Out – jednokrotne wylogowanie Serwer CAS – autoryzuje klientów Scentralizowane – wszystkie hasła przechowywane w jednym miejscu (nie koniecznie jeden mechanizm autoryzacji)

Bilety, usługi ... czyli architektura

Podstawowe pojęcia dla CAS Serwer CAS Usługa – aplikacja WWW autoryzująca użytkowników za pomocą serwera CAS Proxy – usługa chcąca uzyskać dostęp do innych usług w imieniu danego użytkownika Usługa końcowa – usługa akceptująca dane uwierzytelniające od proxy Bilet – unikalny identyfikator służący do autoryzacji usług i jej weryfikacji

Architektura CAS Jak to działa?

www.prezentacja-cas.pl Użytkownik odwołuje się do zasobu w aplikacji WEB.

strona logowania logowanie.prezentacja-cas.pl redirect service=www.prezentacja-cas.pl Gdy zasób jest chroniony - redirect do serwera CAS CAS sprawdza czy istnieje TGT (Ticket Granting Ticket), jeśli istnieje zamiast strony logowania następuje pominięcie kroku i redirect do usługi (tak jak to zostanie pokazane w następnym kroku). Wyświetlenie strony logowania. www.prezentacja-cas.pl

ZALOGUJ logowanie.prezentacja-cas.pl www.prezentacja-cas.pl marcin.frankiewicz ************ Uwierzytelnianie (authentication). Jeżeli dane niepoprawne – komunikat. Dla danych poprawnych … www.prezentacja-cas.pl

logowanie.prezentacja-cas.pl redirect Redirect do usługi z ST (Service Ticket-em) jako parametr. Passing the "master key" session identifier exclusively between the user's browser and CAS server dramatically limits the potential for man-in-the-middle attacks on the session identifier. CAS benefits from increased security in this regard over shared cookie strategies. www.prezentacja-cas.pl www.prezentacja-cas.pl?ticket=xxx

Witaj marcin.frankiewicz! logowanie.prezentacja-cas.pl Witaj marcin.frankiewicz! weryfikacja ID TAK | NIE XML Weryfikacja ST przez usługę (do CAS przekazany ST i nazwa usługi). Czas życia ST bardzo krótki i powiązany z usługą, zapobiega to atakowi man in the middle. Odpowiedź za CAS w postaci XML-a. Identyfikator użytkownika + atrybuty. www.prezentacja-cas.pl

Architektura CAS Tryb gateway

Często spotykana sytuacja, zwłaszcza w portalach internetowych, że zasób jest publiczny a wyświetlana jest informacja o zalogowanym użytkowniku. Mechanizmy typu „pamiętaj mnie”. Domyślnie dla każdego zasobu chronionego następuje przekierowanie do CAS i prezentacja strony logowanie (dla niezalogowanego). Aby to osiągnąć w CAS wprowadzono tryb gateway. W trybie gateway strona logowania nie jest NIGDY pokazywana.

Protokół CAS – tryb gateway Rozpoznanie czy użytkownik jest zalogowany bez pokazywania strony logowania Przydatny dla zasobów niechronionych Dla niezalogowanych użytkowników dużo przekierowań Brak wsparcia w kliencie Spring Security  Każde żądanie przekierowywane na stronę logowania CAS a potem z powrotem do usługi

Bilety Architektura CAS Służą do autoryzacji usług i jej weryfikacji. Unikalne stringi z odpowiednim przedrostkiem i identyfikatorem.

Bilety TGT (Ticket Granting Ticket) bezpieczny identyfikator sesji SSO, udostępniany wyłącznie serwerowi CAS w postaci cookie ST (Service Ticket) dane uwierzytelniające możliwe do wykorzystania tylko raz wykorzystywane aby uzyskać dostęp do usług Proxy-granting ticket (PGT) Proxy-granting ticket IOU (PGTIOU) Proxy ticket (PT) TGT Private and protected cookie (the only one used by CAS, optional) Opaque re-playable ticket ST Browser’s passport to the CAS client (application) Opaque and non re-playable ticket Very limited validity (a few seconds) PGT Application’s passport for a user to the CAS server Opaque and re-playable ticket PT Application’s passport for a user to a tier service Very limited validity

Modułowość, rozszerzalność, konfiguracja Budowa serwera CAS

Zastosowane technologie Java 1.5 + Java Servlet 2.4 Apache Maven Spring WebFlow Możliwość wdrożenia na wielu serwerach - każdy serwer wspierający Servlet 2.4 – pojedyncze archiwum WAR Spring Framework – API CAS podobne do Spring Framework, rozszerzalne i modułowe, konfiguracja w XML Spring-a Spring Security – Zarządzanie usługami i statusem serwera Spring WebFlow – Logowanie jako Web Flow (workflow), łatwe do rozszerzenia np. wymuszenie zmiany hasła Spring Framework Spring Security

Konfiguracja serwera Maven WAR „overlay” Spring Beans XML deployerConfigContext.xml + cas.properties CSS, grafika, widok, itp. Nowe moduły w postaci zależności Maven Najprościej za pomocą mechanizmu maven war overlay, ale można też przepakować WAR-kę lub zbudować ze źródeł.

Protokoły komunikacji CAS 1.0 i 2.0 SAML 1.1 SAML2 OpenID OAuth Własny protokół  Komunikacja pomiędzy klientem a serwerem Klient może komunikować się z serwerem za pomocą któregokolwiek ze wspieranych protokołów. Wszystkie wspierane protokoły są konceptualnie podobne do siebie, jednak różniące je cechy lub właściwości mogą być pożądane przez jedną lub drugą aplikację. Np. protokół CAS wspiera autoryzację proxy a protokół SAML wspiera przekazywanie atrybutów oraz Single Sign Out. SAML 1.1 – wsparcie częściowe, głownie ze względu na przekazywanie atrybutów oraz Single Sign Out. SAML 2 – integracja z kontem Google, idP (identity provider) dla Google Apps (hosted) OpenID - wsparcie częściowe dla funkcjonalności idP (identity provider) OAuth – jako klient OAuth (Facebook, Twitter, Google) lub jako serwer OAuth 2.0

Dostawcy autoryzacji Podstawowy Active Directory LDAP JDBC JAAS RADIUS SPNEGO Certyfikat X.509 Własny dostawca  Podstawowy – użytkownik/hasło w konfiguracji serwera lub w pliku JDBC – query (SQL) do BD w pliku konfiguracji JAAS - Java Authentication and Authorization Service – framework podobny do PAM RADIUS - Remote Authentication Dial In User Service - usługa zdalnego uwierzytelniania użytkowników, którzy wdzwaniają się do systemu. Obecnie jest najpopularniejszym protokołem uwierzytelniania i autoryzowania użytkowników sieci telefonicznych i tunelowych. Używany również w sieciach bezprzewodowych. SPNEGO - Simple and Protected GSSAPI Negotiation Mechanism – Kerberos X.509 – certyfikat klienta

Dodatkowe funkcjonalności i rozszerzenia Menedżer usług i udostępnianie atrybutów RestAPI „Zapamiętywanie” użytkownika Blokada przed zgadywaniem hasła Audyt i statystyki Możliwość pracy w klastrze ClearPass Nieoficjalne, np. CASShib Menedżer usług – osobny moduł pozwalający na zarządzanie usługami – white-list, udostępniane atrybuty, proxy RestAPI – żądanie TGT, ST, logout „Remember me” – długoterminowe TGT Blokada przed zgadywaniem hasła – nie blokuje konta a jedynie dostęp z określonego IP Audyt i statystyki – Inspektr do audytowania, zapis w BD Klaster – unikalność biletów – rejestr biletów, distributable ClearPass – przekazywanie „czystego” hasła do usługi CASShib - CAS zamiast Shibboleth service provider

Integracja z CAS-em Klienci CAS Czyli jak zintegrować aplikację z CAS-em

Integracja klientów z CAS Oficjalni klienci utrzymywani przez JA-SIG Klienci nieoficjalni - community Aplikacje z wbudowaną integracją z CAS Pojęcie „CASifying” https://wiki.jasig.org/display/CAS/CASifying+Applications https://wiki.jasig.org/display/CASC/CASifying+Applications CASifying – czyli co zrobić aby aplikacja wykorzystywała CAS jako dostawcę uwierzytelniania.

Oficjalni klienci CAS Java CAS Client phpCAS mod_auth_cas Spring Security CAS Apache Shiro CAS phpCAS mod_auth_cas .NET CAS Client

Klient Java – zestaw filtrów, autoryzują i weryfikują, oraz umieszczają Principal-a w request

Klienci nieoficjalni Perl Ruby Python PAM IIS PL/SQL Drupal, JIRA, Confluence https://wiki.jasig.org/display/CASC/Unofficial+CAS+Clients

Aplikacje zintegrowane z CAS uPortal – portal JA-SIG Mantis – Bug Tracker Liferay Portal – portal Moodle – system e-learningowy

Comarch Portal  Overlay, overlay-a Autoryzacja JDBC, Active Directory, ePAUP (jednocześnie) Przekazywanie atrybutów Klient Spring Security + moduły dodatkowe z klientami Java Modyfikacja formatki logowania Klaster (Jboss Cache) Wymuszenie zmiany hasła

Konkurencyjne rozwiązania

Rozwiązania online OpenID OAuth Mozilla Persona ePUAP Facebook Google Twitter Microsoft Wiele innych http://en.wikipedia.org/wiki/Oauth Mozilla Persona ePUAP

Serwery SSO JOSSO OpenAM Shibboleth (Internet2) CoSign

DEMO A jak to wszystko działa w praktyce … 30 minut pracy – overlay CAS-a, prosty klient, konfiguracja Tomcat-a Scenariusz: https://github.com/fraanek-pl/cas-presentation

Pomoc, źródła, materiały Community … Pomoc, źródła, materiały

Pomoc, źródła, materiały http://www.jasig.org/cas http://www.ja-sig.org/wiki/display/CAS/Home http://www.jasig.org/cas/cas2-architecture http://www.jasig.org/cas/protocol https://github.com/Jasig/cas

Dziękuję za uwagę  Pytania, uwagi Marcin Frankiewicz Marcin.Frankiewicz@comarch.pl