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

git clone git@github.com:Jasig/cas.git

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:

git checkout v4.1.1

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.

CREATE TABLE user_role (
	role_id INTEGER PRIMARY KEY AUTO_INCREMENT,
	role VARCHAR(255) NOT NULL
);

CREATE TABLE user_account (
	user_id INTEGER PRIMARY KEY AUTO_INCREMENT,
	username VARCHAR(255) NOT NULL,
	fk_role_id INTEGER NOT NULL,
	mail VARCHAR(255) NOT NULL,
	password VARCHAR(255) NOT NULL,
	is_active BOOLEAN DEFAULT TRUE,
	registration_date TIMESTAMP NOT NULL,
	FOREIGN KEY (fk_role_id)
		REFERENCES user_role (role_id)
		ON UPDATE CASCADE
);

INSERT INTO `user_role` (`role_id`, `role`) VALUES
(1, 'ROLE_ADMIN'),
(2, 'ROLE_MODERATOR'),
(3, 'ROLE_USER');

INSERT INTO `user_account` (`username`, `fk_role_id`,`mail`,`password`,`registration_date`) VALUES
('test-user', 3, 'test-user@mail.com', 'test-user', NOW()),
('test-admin', 1, 'test-admin@mail.com', 'test-admin', NOW());

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

<dependency>
    <groupId>org.jasig.cas</groupId>
    <artifactId>cas-server-support-jdbc</artifactId>
    <version>${cas.jdbc.support}</version>
</dependency>
<dependency>
    <groupId>c3p0</groupId>
    <artifactId>c3p0</artifactId>
    <version>${c3p0.version}</version>
</dependency>
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>${mysql.version}</version>
</dependency>

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

<cas.jdbc.support>4.1.1</cas.jdbc.support>
<c3p0.version>0.9.1.2</c3p0.version>
<mysql.version>5.1.31</mysql.version>

Plik konfiguracyjny

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

server.name=https://localhost:8443
server.prefix=${server.name}/cas-demo

database.hibernate.dialect=org.hibernate.dialect.MySQLInnoDBDialect

cas.logout.followServiceRedirects=true

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:

<constructor-arg>
    <map>
        <entry key-ref="dbAuthHandler" value-ref="primaryPrincipalResolver" />
    </map>
</constructor-arg>

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ć).

<bean id="dataSource"
    class="com.mchange.v2.c3p0.ComboPooledDataSource"
    p:driverClass="com.mysql.jdbc.Driver"
    p:jdbcUrl="jdbc:mysql://127.0.0.1:3306/test_app"
    p:user="root"
    p:password=""
    p:minPoolSize="6"
    p:maxPoolSize="18" />

<bean id="dbAuthHandler"
    class="org.jasig.cas.adaptors.jdbc.QueryDatabaseAuthenticationHandler"
    p:dataSource-ref="dataSource"
    p:sql="SELECT password FROM user_account WHERE mail=?">
</bean>

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

<bean id="attributeRepository"
      class="org.jasig.services.persondir.support.jdbc.SingleRowJdbcPersonAttributeDao">
	<constructor-arg index="0" ref="dataSource" />
	<constructor-arg index="1" value="select user_account.username,
		user_account.fk_role_id,
		user_account.mail as mail,
		user_account.password,
		user_account.user_id as id,
		user_account.username as username,
		user_role.role as role
		from user_account
		join user_role on user_role.role_id = user_account.fk_role_id
		where {0}" />
	<property name="queryAttributeMapping">
		<map>
			<entry key="username" value="mail" />
		</map>
	</property>
	<property name="resultAttributeMapping">
		<map>
			<entry key="id" value="id" />
			<entry key="username" value="username" />
			<entry key="mail" value="email" />
			<entry key="role" value="roles" />
			</map>
	</property>
</bean>

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

You may also like

Comments