CAS - konfiguracja dostawcy tożsamości cz. 1 Skip to content →

CAS – konfiguracja dostawcy tożsamości cz. 1

Central Authentication Service (CAS) to protokół używany przy realizacji modelu Single Sign On.
W SSO uwierzytelnianie realizowane jest przez osobną aplikację, która następnie rozpropagowuje informacje o zalogowanym użytkowniku. Dzięki takiemu podejściu użytkownik raz wpisując dane do logowania otrzymuje dostęp do kilku aplikacji.

Aplikacja, która zostanie przedstawiona w tym wpisie nosi taką samą nazwę jak protokół. Projekt The Cental Authentication Service został stworzony na Uniwersytecie Yale. Obecnie CAS rozwijany jest przez fundację Apero.

Pobieranie CAS

Pierwszym krokiem jaki musimy wykonać przy konfiguracji CAS jest pobranie aplikacji do uwierzytelniania. Wszystkie niezbędne elementy znajdują się w publicznym repozutorium udostępnianym przez fundację Apero. Repozytorium możemy pobrać za pomocą komendy

Jako, że repozytorium zawiera wiele różnych elementów cały process może potrwać kilka minut. Mając już wszystko pobrane zamportuj projekt ze ścieżki /cas/cas-server-webapp do swojego ulubionego IDE.

Przedstawione w tym poście rozwiązanie opiera się na wersji 4.1.1. Można się na nią przełączyć wpisując w konsoli:

Najważniejsze elementy cas-server-webapp

Aplikacja cas-server-webapp zawiera kilka plików i folderów, którym warto się na samym początku przyjżeć :

  1. src/main/resources/services/*
    W powyższym folderze znajdują się konfiguracje klientów, którzy powinni mieć dostęp do aplikacji CAS. Możemy zdefiniować numer serwisu, nazwę, opis, sposoby wylogowywania użytkowników i wiele wiele innych. Dokładny opis sekcji plików konfiguracyjnych można znaleźć w oficjalnej dokumentacji
  2. src/main/resources/services/messages_*.properties
    Pliki messages_*.properties to pliki z konfiguracyjne dla internacjonalizacji aplikacji CAS. Przeglądając różne pliki możemy zobaczyć, że różnią się one tylko i wyłącznie tłumaczeniami przy danych kluczach.
  3. src/main/webapp/web-inf/cas.properties
    Główny plik konfiguracyjny aplikacji CAS. Część wpisów to wpisy charakterystyczne dla aplikacji Spring. Znajdziemy tam m. in. wskazanie adresu i portu, nazwa hosta, sterownik dla połączenia z bazą danych, konfiguracje wylogowania. W dalszej części tego wpisu będziemy edytowali ten plik.
  4. src/main/webapp/web-inf/deployerConfigContext.xml
    Standardowy plik konfiguracyjny kontekstu aplikacji CAS. Tutaj będziemy wprowadzali najwiecej zmian.

Konfiguracja aplikacji

Baza danych

Poprawna konfiguracja pozwoli zalogować się na użytkownika, którego dane są przechowywane w bazie danych o poniższej strukturze.

Maven

Do testów aplikacja będzie uruchamiana w kontenerze Tomcat. Dodajmy konfigurację pluginu Maven’a, który będzie odpowiedzialny za deploy aplikacji w odpowiednich ścieżkach naszego kontenera.

Wykorzystanie bazy danych zmusza nas do dodania elementów, które domyślnie nie są wzięte pod uwagę. Pierwszy z nich to wsparcie dla baz danych po stronie CAS, drugi to sterownik JDBC dla MySQL, trzeci to biblioteka dla JDBC

Uzupełnijmy jeszcze sekcję properties w wersje komponentów

Plik konfiguracyjny

Plik konfiguracyjny cas.properties  jest dostępny w folderze src/main/webapp/web-inf/ . Musimy zmienić następujące wartości:

Wartości w sekcji server są uzależnione od konfiguracji kontenera, w którym aplikacja będzie uruchamiana oraz ścieżki, pod którą dostępny będzie konteks aplikacji CAS.

Kontekst aplikacji

Na tym etapie konfiguracji czeka nas najwięcej pracy. Wszystkie zmiany z tej sekcji będą przeprowadzane w pliku deployerConfigContext.xml .

Bean authenticationManager jako konstruktor powinien przyjąć referencję do uchwytu, który zapewni nam połączenie z bazą danych oraz wykonanie odpowiedniego zapytania:

Następnie powinniśmy skonfigurować  dbAuthHandler. Pierwsze ziarno odpowiada za połączenie z bazą, drugie za zapytanie o hasło użytkownika. p:user  oraz p:password  to dane użytkownika, który ma dostęp do bazy danych (nie mylić z użytkownikiem, któr będzie próbował się zalogować).

Ostatnim krokiem jest skonfigurowanie ziarna odpowiedzialnego za dostarczenie danych, które zostaną zwrócone do aplikacji klienckiej. Ziarno to nosi nazwę attributeRepository.

Atrybuty zwrócone przez zapytanie z 1 parametru konstruktora są mapowane na wartości w odpowiedzi:

  • id zostanie zwrócone jako pole id
  • username jako pole username
  • mail jako mail
  • role jako roles

queryAttributeMapping  odpowiada za mapowanie pól w zapytaniu SQL. Jako nazwy użytkownika w aplikacji CAS używamy jego maila – całe logowanie będzie bazowało na mailu. Chcą zmienić je na username musimy zmienić zapytanie z dbAuthHandler .

Test

Ukończyliśmy już wszystkie etapy konfiguracji. Teraz możemy przejść do testowania. Spróbujmy zalogować się na utworzone konta w pierwszym polu formularza logowania wpisując adres e-mail zaś w drugim hasła.

Po poprawnym zalogowaniu powinniśmy ujrzeć

CAS_successfull_login

Przy mojej konfiguracji Tomcat’a wylogowanie z aplikacji możliwe jest poprzez wejście na np.  https://localhost:8443/cas-demo/logout  (zamiana login na logout).

W następnym poście przedstawię proces tworzenia aplikacji, która będzie używała aplikacji CAS jako głównego dostawcy tożsamości.

Przydatne linki

  1. Oficjalne repozytorium fundacji Apero – github.com/Jasig
  2. Grupa projektu CAS na Google Groups – groups.google.com/forum/#!forum/jasig-cas-user