Czym jest CAS i dlaczego jest kluczowy dla bezpiecznego logowania?

W dzisiejszym cyfrowym świecie, gdzie użytkownicy korzystają z dziesiątek, a nawet setek aplikacji i usług online, zarządzanie wieloma zestawami danych do logowania staje się prawdziwym wyzwaniem. Problem ten dotyczy zarówno pamięci użytkownika, jak i bezpieczeństwa, ponieważ prowadzi do używania tych samych, często słabych haseł, lub do ich zapisywania w niezabezpieczonych miejscach. Odpowiedzią na to wyzwanie jest koncepcja Single Sign-On (SSO), czyli jednokrotnego logowania. Wśród wielu protokołów SSO, Central Authentication Service (CAS) stanowi jedno z najbardziej ugruntowanych i niezawodnych rozwiązań, które od lat wspiera instytucje edukacyjne, firmy i organizacje w centralizacji procesu uwierzytelniania.

CAS, czyli Central Authentication Service, to otwarty protokół i system służący do bezpiecznego uwierzytelniania użytkowników w wielu aplikacjach webowych za pomocą jednego zestawu danych logowania. Jego głównym celem jest eliminacja konieczności wielokrotnego wpisywania nazwy użytkownika i hasła przy przełączaniu się między różnymi usługami. Raz uwierzytelniony w serwerze CAS, użytkownik uzyskuje dostęp do wszystkich zintegrowanych z CAS aplikacji bez potrzeby ponownego logowania, co znacząco poprawia komfort użytkowania i efektywność pracy.

Kluczowa rola CAS w kontekście bezpieczeństwa logowania wynika z kilku aspektów. Po pierwsze, centralizuje on proces uwierzytelniania. Zamiast każdej aplikacji samodzielnie weryfikować tożsamość użytkownika, wszystkie one delegują to zadanie do jednego, zaufanego serwera CAS. Minimalizuje to powierzchnię ataku, ponieważ dane logowania użytkownika są wprowadzane i przetwarzane tylko w jednym miejscu, a nie w każdej aplikacji z osobna. Po drugie, CAS promuje stosowanie silniejszych polityk bezpieczeństwa. Ponieważ serwer CAS jest jedynym punktem styku z danymi uwierzytelniającymi, administratorzy mogą skupić się na jego zabezpieczeniu, wdrażając zaawansowane mechanizmy, takie jak uwierzytelnianie wieloskładnikowe (MFA), monitorowanie podejrzanych aktywności czy ścisłe polityki haseł, które obowiązują dla wszystkich zintegrowanych usług.

Dzięki CAS logowanie staje się nie tylko wygodniejsze, ale przede wszystkim bezpieczniejsze. Firmy i organizacje mogą zapewnić spójne środowisko uwierzytelniania, zmniejszyć ryzyko wycieku danych oraz uprościć zarządzanie kontami użytkowników. Integracja z systemami tożsamości, takimi jak LDAP czy Active Directory, dodatkowo zwiększa jego elastyczność i skalowalność, czyniąc go doskonałym wyborem dla środowisk o złożonej infrastrukturze IT.

Jak działa proces logowania CAS krok po kroku?

Zrozumienie mechanizmu działania CAS jest kluczowe dla efektywnej implementacji i zarządzania. Proces logowania CAS, choć złożony na poziomie technicznym, opiera się na prostym założeniu: użytkownik uwierzytelnia się raz w centralnym systemie, a następnie otrzymuje dostęp do powiązanych usług bez ponownego wprowadzania danych. Poniżej przedstawiamy szczegółowy przebieg tego procesu:

1. Początkowe żądanie dostępu do usługi: Użytkownik próbuje uzyskać dostęp do aplikacji webowej (zwanej „usługą” w terminologii CAS), która jest chroniona przez CAS. Przykładem może być próba otwarcia firmowego intranetu.

2. Wykrycie braku sesji: Klient CAS (moduł wbudowany w aplikację chronioną) wykrywa, że użytkownik nie posiada aktywnej sesji CAS i nie jest uwierzytelniony w kontekście tej usługi.

3. Przekierowanie do serwera CAS: Klient CAS przekierowuje przeglądarkę użytkownika do serwera CAS. W żądaniu przekierowania zawarty jest adres URL usługi, do której użytkownik początkowo dążył (tzw. service URL).

4. Sprawdzenie globalnej sesji CAS: Serwer CAS sprawdza, czy użytkownik ma już aktywną globalną sesję logowania CAS. Odbywa się to poprzez analizę ciasteczka (TGC - Ticket-Granting Cookie) przechowywanego w przeglądarce użytkownika.

   • Jeśli sesja istnieje: Oznacza to, że użytkownik został już wcześniej uwierzytelniony w serwerze CAS. Serwer generuje unikalny bilet serwisowy (ST - Service Ticket) dla konkretnej usługi i przekierowuje użytkownika z powrotem do usługi, dołączając ST w parametrze URL. Użytkownik nie musi ponownie podawać danych logowania.
   • Jeśli sesja nie istnieje: Serwer CAS wyświetla użytkownikowi stronę logowania, gdzie musi on wprowadzić swoją nazwę użytkownika i hasło.

5. Uwierzytelnienie użytkownika (jeśli konieczne): Użytkownik wprowadza swoje dane logowania na stronie serwera CAS. Serwer CAS weryfikuje te dane w swoim backendowym magazynie tożsamości (np. baza danych, LDAP, Active Directory).

   • Po pomyślnym uwierzytelnieniu: Serwer CAS ustanawia globalną sesję logowania, generuje TGT (Ticket-Granting Ticket), które jest przechowywane po stronie serwera oraz wysyła do przeglądarki użytkownika ciasteczko TGC. Następnie generuje ST (Service Ticket) dla żądanej usługi i przekierowuje użytkownika z powrotem do usługi, dołączając ST w parametrze URL.
   • W przypadku niepowodzenia: Użytkownik zostaje poinformowany o błędnych danych logowania i proszony o ponowną próbę.

6. Walidacja biletu serwisowego przez usługę: Po przekierowaniu użytkownika z powrotem do usługi z biletem serwisowym (ST), klient CAS w aplikacji niezwłocznie wysyła to ST do serwera CAS w celu walidacji. Klient CAS wykonuje to żądanie bez udziału przeglądarki użytkownika, za pomocą bezpośredniego połączenia (back-channel request).

7. Odpowiedź serwera CAS: Serwer CAS odbiera żądanie walidacji, sprawdza poprawność ST (czy jest ważne, czy nie było wcześniej użyte i czy zostało wydane dla danej usługi).

   • Jeśli ST jest ważne: Serwer CAS odpowiada, potwierdzając ważność biletu i przekazując informacje o uwierzytelnionym użytkowniku (np. jego identyfikator).
   • Jeśli ST jest nieprawidłowe: Serwer CAS odmawia walidacji.

8. Ustanowienie lokalnej sesji w usłudze: Po pomyślnej walidacji ST, usługa uważa użytkownika za uwierzytelnionego. Tworzy dla niego lokalną sesję (np. poprzez ciasteczko sesyjne HTTP) i zezwala na dostęp do żądanych zasobów. Od tego momentu użytkownik jest zalogowany do tej konkretnej aplikacji.

9. Dostęp do innych usług: Jeśli użytkownik spróbuje uzyskać dostęp do innej aplikacji chronionej przez CAS, proces rozpocznie się od kroku 1. Jednak dzięki istniejącemu ciasteczku TGC (krok 4), użytkownik zostanie automatycznie przekierowany z biletem serwisowym do nowej usługi bez ponownego logowania, co demonstruje ideę jednokrotnego logowania.

Ten sprawny mechanizm, w którym CAS logowanie odbywa się poprzez wzajemną weryfikację między serwerem CAS a klientem CAS w aplikacjach, jest podstawą bezpieczeństwa i wygody oferowanej przez ten system.

Główne zalety wdrożenia systemu CAS do logowania

Wdrożenie Central Authentication Service (CAS) jako rozwiązania do logowania przynosi szereg korzyści, które wykraczają poza samą wygodę użytkowania. Dotyczą one zarówno perspektywy użytkownika końcowego, administratora systemu, jak i ogólnego bezpieczeństwa i efektywności operacyjnej organizacji. Poniżej przedstawiamy najważniejsze zalety korzystania z systemu CAS:

• Jednokrotne Logowanie (SSO): To fundamentalna i najbardziej odczuwalna korzyść. Użytkownik loguje się tylko raz do serwera CAS, a następnie uzyskuje dostęp do wszystkich zintegrowanych aplikacji bez potrzeby ponownego wprowadzania danych uwierzytelniających. Dramatycznie poprawia to doświadczenie użytkownika i oszczędza czas, eliminując frustrację związaną z wielokrotnym logowaniem.

• Zwiększone Bezpieczeństwo:

  • Centralizacja uwierzytelniania: Dane logowania są wprowadzane i weryfikowane tylko w jednym, zabezpieczonym miejscu – serwerze CAS. Zmniejsza to powierzchnię ataku, ponieważ poszczególne aplikacje nie muszą przechowywać ani przetwarzać haseł użytkowników.
  • Wsparcie dla silnych polityk: Serwer CAS może egzekwować złożone polityki haseł, uwierzytelnianie wieloskładnikowe (MFA) oraz inne zaawansowane środki bezpieczeństwa, które automatycznie rozciągają się na wszystkie zintegrowane aplikacje.
  • Ograniczenie phishingu: Użytkownicy szybko uczą się rozpoznawać zaufaną stronę logowania CAS, co utrudnia ataki phishingowe, ponieważ fałszywe strony logowania będą łatwiejsze do zidentyfikowania.

• Uproszczone zarządzanie użytkownikami:

  • Jedno źródło prawdy: CAS integruje się z centralnymi systemami tożsamości (np. LDAP, Active Directory, bazami danych), co oznacza, że zmiany w danych użytkownika (np. zmiana hasła, blokada konta) są od razu widoczne we wszystkich aplikacjach.
  • Łatwiejsze zarządzanie dostępem: Administratorzy IT mają centralny punkt kontroli nad uwierzytelnianiem, co upraszcza procesy onboardingu i offboardingu pracowników.

• Zmniejszenie obciążenia działu IT: Mniejsza liczba zapytań o resetowanie haseł (dzięki SSO) i zcentralizowane zarządzanie kontami redukuje liczbę zgłoszeń do helpdesku, pozwalając zespołowi IT skupić się na bardziej strategicznych zadaniach.

• Elastyczność i skalowalność: CAS jest wysoce konfigurowalny i może być dostosowany do różnych środowisk i wymagań. Obsługuje dużą liczbę użytkowników i aplikacji, co czyni go odpowiednim dla rosnących organizacji.

• Otwartoźródłowy charakter: Jako projekt open-source, CAS oferuje przejrzystość kodu, aktywne wsparcie społeczności oraz brak opłat licencyjnych za samo oprogramowanie, co może być atrakcyjne kosztowo dla wielu organizacji.

• Wsparcie dla wielu technologii: Istnieją klienci CAS i biblioteki dla większości popularnych języków programowania i frameworków webowych (Java, PHP, Python, Ruby, .NET), co ułatwia integrację istniejących i nowych aplikacji.

Dzięki tym zaletom, CAS logowanie stanowi solidną podstawę dla infrastruktury uwierzytelniania w każdej organizacji, która dąży do poprawy bezpieczeństwa, efektywności i doświadczenia użytkownika.

Architektura CAS: Kluczowe komponenty i ich rola

System CAS, aby zapewnić funkcjonalność jednokrotnego logowania, opiera się na interakcji między kilkoma kluczowymi komponentami. Zrozumienie ich ról i wzajemnych zależności jest niezbędne do prawidłowego zaprojektowania, wdrożenia i utrzymania rozwiązania CAS logowania. Główne elementy architektury CAS to Serwer CAS, Klient CAS (znany również jako Application/Service) oraz Magazyn Tożsamości.

1. Serwer CAS (CAS Server)

Serwer CAS to serce całego systemu. Jest to centralna aplikacja webowa, która odpowiada za uwierzytelnianie użytkowników i zarządzanie globalną sesją SSO. Jego główne funkcje obejmują:

• Uwierzytelnianie użytkowników: Serwer CAS jest jedynym miejscem, gdzie użytkownik wprowadza swoje dane logowania (nazwę użytkownika i hasło). Odpowiada za weryfikację tych danych z magazynem tożsamości.
• Zarządzanie biletami: Serwer CAS generuje i zarządza różnymi typami biletów:
  • Ticket-Granting Ticket (TGT): Reprezentuje globalną sesję SSO użytkownika po pomyślnym uwierzytelnieniu. Jest przechowywany po stronie serwera.
  • Ticket-Granting Cookie (TGC): Jest ciasteczkiem przeglądarki, które wskazuje na istniejące TGT. Używane do identyfikacji użytkownika w kolejnych żądaniach do serwera CAS, umożliwiając bezproblemowy dostęp do innych usług bez ponownego logowania.
  • Service Ticket (ST): Jest jednorazowym biletem, wydawanym przez serwer CAS dla konkretnej usługi. Służy do potwierdzenia tożsamości użytkownika w danej aplikacji. Każde ST może być użyte tylko raz do walidacji.
• Rejestracja usług: Serwer CAS musi być skonfigurowany, aby wiedzieć, które aplikacje (usługi) są uprawnione do korzystania z jego mechanizmów uwierzytelniania. Ta lista zarejestrowanych usług zwiększa bezpieczeństwo, zapobiegając nieautoryzowanemu wykorzystaniu serwera CAS.
• Wylogowanie (Single Logout – SLO): Serwer CAS może koordynować wylogowanie użytkownika ze wszystkich zintegrowanych aplikacji, gdy użytkownik zdecyduje się zakończyć sesję SSO.

Implementacje serwera CAS są dostępne w różnych technologiach, z czego oficjalna implementacja referencyjna jest napisana w języku Java.

2. Klient CAS (CAS Client / Service)

Klient CAS to moduł lub biblioteka zintegrowana z każdą aplikacją webową, która ma korzystać z systemu CAS logowania. Jego głównym zadaniem jest pośredniczenie między aplikacją a serwerem CAS. Klient CAS wykonuje następujące czynności:

• Wykrywanie nieautoryzowanych użytkowników: Klient CAS sprawdza, czy użytkownik ma aktywną sesję w aplikacji. Jeśli nie, inicjuje proces uwierzytelniania CAS.
• Przekierowanie do serwera CAS: Po wykryciu braku autoryzacji, klient CAS przekierowuje przeglądarkę użytkownika do serwera CAS, przekazując adres URL swojej aplikacji (service URL).
• Odbiór i walidacja Service Ticket (ST): Po powrocie użytkownika z serwera CAS z Service Ticket (ST), klient CAS odbiera to ST. Następnie wykonuje bezpośrednie, „back-channel” żądanie do serwera CAS w celu walidacji ST. Ten krok jest kluczowy dla bezpieczeństwa, ponieważ tylko serwer CAS może potwierdzić autentyczność biletu i tożsamość użytkownika.
• Ustanowienie lokalnej sesji: Po pomyślnej walidacji ST, klient CAS uznaje użytkownika za uwierzytelnionego i często tworzy lokalną sesję w aplikacji, przechowując w niej dane o użytkowniku, które mogą być przekazane przez serwer CAS (np. atrybuty z magazynu tożsamości).
• Obsługa wylogowania: Klient CAS reaguje na żądania wylogowania od serwera CAS, niszcząc lokalną sesję użytkownika w aplikacji.

Istnieje wiele implementacji klientów CAS dla różnych języków programowania i frameworków, co ułatwia integrację niemal każdej aplikacji webowej.

3. Magazyn Tożsamości (Identity Store)

Magazyn Tożsamości nie jest bezpośrednio częścią protokołu CAS, ale jest niezbędnym zewnętrznym komponentem, z którym serwer CAS musi się komunikować w celu weryfikacji danych logowania użytkowników oraz pobierania ich atrybutów. Może to być:

• Lightweight Directory Access Protocol (LDAP) / Active Directory: Najczęściej używane rozwiązanie w środowiskach korporacyjnych i akademickich. LDAP i Active Directory przechowują dane użytkowników, grupy i inne atrybuty w scentralizowanym katalogu.
• Relacyjne Bazy Danych: Serwer CAS może być skonfigurowany do uwierzytelniania użytkowników na podstawie danych przechowywanych w bazach danych (np. MySQL, PostgreSQL, Oracle).
• Inne niestandardowe źródła: Możliwe jest również zintegrowanie serwera CAS z innymi, niestandardowymi źródłami tożsamości poprzez odpowiednie moduły.

Wybór magazynu tożsamości zależy od istniejącej infrastruktury organizacji i wymagań dotyczących zarządzania użytkownikami. To w nim przechowywane są dane, które użytkownik wprowadza podczas procesu CAS logowania.

Interakcja tych trzech kluczowych komponentów – niezawodnego Serwera CAS, wszechstronnego Klienta CAS i bezpiecznego Magazynu Tożsamości – tworzy solidną architekturę systemu CAS, umożliwiającą efektywne i bezpieczne jednokrotne logowanie.

Konfiguracja i integracja CAS w popularnych aplikacjach i frameworkach

Implementacja systemu CAS logowania wymaga konfiguracji zarówno na poziomie serwera CAS, jak i każdej pojedynczej aplikacji (klienta CAS). Proces ten, choć różni się w szczegółach w zależności od używanych technologii, opiera się na tych samych fundamentalnych zasadach. Poniżej przedstawiamy ogólne kroki i przykłady integracji w popularnych środowiskach.

Ogólne kroki konfiguracji serwera CAS:

1. Wdrożenie serwera CAS: Najpierw należy wdrożyć instancję serwera CAS. Najczęściej wykorzystuje się oficjalną implementację referencyjną (CAS Server), która jest aplikacją Java i wymaga serwera aplikacji, takiego jak Apache Tomcat, Jetty lub WildFly. Możliwe jest również użycie gotowych obrazów Docker.

2. Konfiguracja magazynu tożsamości: Serwer CAS musi być połączony z zewnętrznym magazynem tożsamości.

   • LDAP/Active Directory: To najpopularniejsza opcja. Konfiguruje się adresy serwerów LDAP, bazowe DN, atrybuty użytkowników (np. uid, cn, mail) oraz dane konta do bindowania.
   • Baza danych: Wymaga konfiguracji sterownika JDBC, URL bazy, danych do logowania oraz zapytań SQL do weryfikacji użytkownika i pobierania atrybutów.

3. Rejestracja usług (aplikacji): Każda aplikacja, która ma korzystać z serwera CAS, musi zostać zarejestrowana. Rejestracja obejmuje podanie wzorca URL usługi (service URL pattern), który serwer CAS będzie akceptował. Przykładowo, ^https://mojaaplikacja.example.com/.*. To kluczowy krok dla bezpieczeństwa, aby serwer CAS komunikował się tylko z zaufanymi usługami.

4. Konfiguracja protokołu HTTPS: Serwer CAS musi być dostępny tylko przez HTTPS, aby zapewnić bezpieczną komunikację i ochronę danych logowania.

5. Opcjonalne konfiguracje: W zależności od potrzeb, można skonfigurować MFA, polityki haseł, wygląd strony logowania, obsługę atrybutów użytkowników, czy wylogowanie (SLO).

Integracja klienta CAS w popularnych frameworkach:

Integracja po stronie klienta polega na dodaniu do aplikacji biblioteki klienta CAS i odpowiednim skonfigurowaniu jej, aby przekierowywała użytkowników do serwera CAS i walidowała bilety serwisowe.

1. Java (Spring Security CAS, JA-SIG CAS Client)

W ekosystemie Java, szczególnie popularne są rozwiązania oparte na Spring Framework. Spring Security CAS jest najczęściej wybieranym klientem, integrującym się bezproblemowo z potężnym frameworkiem Spring Security.

• Dodanie zależności: W pliku pom.xml (Maven) lub build.gradle (Gradle) dodaje się zależność do spring-security-cas.
• Konfiguracja Spring Security: W konfiguracji Spring Security (np. w klasie SecurityConfig) należy zdefiniować bean-y dla:
  • CasAuthenticationEntryPoint: Odpowiada za przekierowanie nieautoryzowanych użytkowników do serwera CAS.
  • ServiceProperties: Definiuje adres URL usługi aplikacji dla CAS.
  • CasAuthenticationProvider: Odpowiada za walidację biletów serwisowych z serwerem CAS i uwierzytelnianie użytkownika w kontekście Spring Security. Należy podać adres URL serwera CAS oraz implementację TicketValidator.
• Przykład konfiguracji (fragment):

  
  @Configuration
  @EnableWebSecurity
  public class SecurityConfig extends WebSecurityConfigurerAdapter {
  
      @Value("${cas.server.url}")
      private String casServerUrl;
      @Value("${cas.service.url}")
      private String casServiceUrl;
  
      @Bean
      public ServiceProperties serviceProperties() {
          ServiceProperties serviceProperties = new ServiceProperties();
          serviceProperties.setService(casServiceUrl + "/login/cas");
          serviceProperties.setSendRenew(false); // Ustawienie na true wymusi ponowne logowanie zawsze
          return serviceProperties;
      }
  
      @Bean
      public CasAuthenticationEntryPoint casAuthenticationEntryPoint() {
          CasAuthenticationEntryPoint entryPoint = new CasAuthenticationEntryPoint();
          entryPoint.setLoginUrl(casServerUrl + "/login");
          entryPoint.setServiceProperties(serviceProperties());
          return entryPoint;
      }
  
      @Bean
      public TicketValidator casTicketValidator() {
          return new Cas30ServiceTicketValidator(casServerUrl);
      }
  
      @Bean
      public CasAuthenticationProvider casAuthenticationProvider() {
          CasAuthenticationProvider provider = new CasAuthenticationProvider();
          provider.setServiceProperties(serviceProperties());
          provider.setTicketValidator(casTicketValidator());
          provider.setUserDetailsService(userDetailsService()); // Własna implementacja UserDetailsService
          provider.setKey("an_id_for_this_provider_only");
          return provider;
      }
  
      @Override
      protected void configure(HttpSecurity http) throws Exception {
          http
              .exceptionHandling().authenticationEntryPoint(casAuthenticationEntryPoint())
              .and()
              .authorizeRequests()
                  .antMatchers("/login/cas").permitAll() // CAS callback URL
                  .anyRequest().authenticated()
              .and()
              .addFilterBefore(casAuthenticationFilter(), BasicAuthenticationFilter.class);
      }
  
      @Bean
      public CasAuthenticationFilter casAuthenticationFilter() throws Exception {
          CasAuthenticationFilter filter = new CasAuthenticationFilter();
          filter.setAuthenticationManager(authenticationManagerBean());
          filter.setAuthenticationSuccessHandler((request, response, authentication) -> {
              // Przekierowanie po sukcesie logowania
              response.sendRedirect("/");
          });
          return filter;
      }
  }
  

2. PHP (phpCAS)

Dla PHP, oficjalna biblioteka phpCAS jest standardowym rozwiązaniem. Jest to dobrze udokumentowana i elastyczna biblioteka.

• Instalacja: Najprościej przez Composer: composer require jasig/phpcas.
• Konfiguracja: W pliku konfiguracyjnym lub na początku skryptu, który ma być chroniony, należy zainicjować phpCAS:

  
  // Autoload Composer
  require_once __DIR__ . '/vendor/autoload.php';
  
  // Inicjalizacja phpCAS
  phpCAS::setDebug(); // Tryb debugowania (opcjonalnie)
  phpCAS::setVerbose(true); // Wyświetlanie szczegółowych błędów (opcjonalnie)
  
  // Ustawienia serwera CAS
  $cas_host = 'cas.example.com';
  $cas_port = 443;
  $cas_context = '/cas'; // Kontekst serwera CAS na serwerze WWW
  
  // Ustawienie certyfikatu CA serwera CAS (wymagane dla HTTPS)
  // phpCAS::setCasServerCACert('/path/to/cas_server_ca.pem'); 
  // LUB: W trybie debugowania można tymczasowo wyłączyć walidację SSL (NIE używać w produkcji!)
  phpCAS::setNoCasServerValidation(); 
  
  // Inicjalizacja CAS Client
  phpCAS::client(CAS_VERSION_3_0, $cas_host, $cas_port, $cas_context);
  
  // Sprawdzenie, czy użytkownik jest już uwierzytelniony
  if (!phpCAS::isAuthenticated()) {
      // Jeśli nie, uruchom proces logowania CAS
      phpCAS::forceAuthentication();
  }
  
  // Jeśli użytkownik jest uwierzytelniony, możemy pobrać jego identyfikator
  $username = phpCAS::getUser();
  echo "Witaj, " . $username . "! Jesteś zalogowany.";
  
  // Opcjonalnie: pobieranie atrybutów użytkownika
  $attributes = phpCAS::getAttributes();
  // print_r($attributes);
  
  // Link do wylogowania
  echo '
  Wyloguj
  ';
  if (isset($_GET['logout'])) {
      phpCAS::logout();
  }
  

3. Python (django-cas-ng, python-cas)

Dla aplikacji Pythonowych, zwłaszcza tych opartych na frameworku Django, dostępne są dedykowane biblioteki.

• Django-cas-ng: To popularny klient CAS dla Django.
  • Instalacja: pip install django-cas-ng.
  • Konfiguracja w settings.py:

    
    # settings.py
    INSTALLED_APPS = [
        # ... inne aplikacje
        'django_cas_ng',
    ]
    
    AUTHENTICATION_BACKENDS = (
        'django.contrib.auth.backends.ModelBackend', # Domyślny backend Django
        'django_cas_ng.backends.CASBackend', # Backend CAS
    )
    
    CAS_SERVER_URL = 'https://cas.example.com/cas/'
    CAS_VERSION = '3' # Użyj odpowiedniej wersji protokołu CAS (1, 2, 3)
    CAS_REDIRECT_URL = '/' # Adres, na który zostanie przekierowany użytkownik po zalogowaniu
    CAS_LOGOUT_COMPLETELY = True # Umożliwia single logout
    CAS_FORCE_SSL_LOGIN = True # Wymuś HTTPS dla logowania CAS
    CAS_EXTRA_LOGIN_PARAMS = {'renew': True} # Opcjonalne parametry (np. wymuszenie ponownego logowania)
    
    # Dodaj URLs dla CAS
    urlpatterns = [
        # ...
        path('accounts/login/', include('django_cas_ng.urls')),
        path('accounts/logout/', views.logout_page, name='logout'), # Własna strona wylogowania
        # ...
    ]
    

  • Zmodyfikuj urls.py i widoki: Django-cas-ng dostarcza widoki do logowania. Musisz też zapewnić, że chronione widoki wymagają uwierzytelnienia (np. za pomocą dekoratora @login_required).

Kluczowe aspekty integracji:

• Adresy URL: Precyzyjne określenie adresów URL serwera CAS i adresów zwrotnych usług jest fundamentalne.
• Certyfik
  

  Brak powiązanych wpisów.