Abdullah Kökbıyık

Ahmet Musa Çatak

Mustafa Emre Başar

Oğuz Ok

Multi-Factor Authentication, Custom Authentication ve CAS Yaklaşımları

Multi-Factor Authentication
Custom Authentication
- UserDetailService
- AuthenticationProvider
CAS (Central Authentication Service)
- Proxy CAS
- Spring Security CAS
Kaynakça

Multi-Factor Authentication

Çok Faktörlü Kimlik Doğrulamaya (MFA) Giriş

Çok Faktörlü Kimlik Doğrulama (MFA), bir kullanıcının kimliğini doğrulamak için birden fazla bağımsız doğrulama yönteminin birlikte kullanıldığı bir güvenlik sürecidir. MFA, sadece parola gibi tek bir doğrulama yöntemine güvenmek yerine, ek güvenlik katmanları oluşturarak yetkisiz erişim riskini azaltmayı hedefler.

MFA sistemleri, genellikle bilgi (bildiğiniz bir şey), sahiplik (sahip olduğunuz bir şey) ve biyometri (size ait bir özellik) gibi farklı doğrulama faktörlerinin en az ikisini bir araya getirerek çalışır.

Bu bağlamda, İki Faktörlü Kimlik Doğrulama (2FA), MFA’in özel bir türüdür. 2FA’da yukarıdaki kategorilerden sadece iki farklı doğrulama faktörü birlikte kullanılır. Örneğin, kullanıcı bir parola girdikten sonra telefonuna gelen tek kullanımlık bir kodla ikinci doğrulamayı tamamlar.

MFA ve özellikle 2FA, kullanıcı hesaplarının güvenliğini artırmak için önemlidir. Çünkü birçok kullanıcı aynı parolayı birden fazla hesapta tekrarlar ve bu da parola güvenliğini zayıflatır. Parolalar kolayca tahmin edilebilir, çalınabilir veya oltalama (phishing) saldırılarıyla ele geçirilebilir.

MFA, bu gibi tehditlere karşı ek bir koruma katmanı sağlar. Parola sızdırılmış olsa bile, ikinci (veya üçüncü) doğrulama faktörü olmadan erişim sağlanamaz. Bu sayede kimlik avı, brute force saldırıları, çalınan kimlik bilgileri gibi güvenlik tehditlerine karşı etkili bir savunma mekanizması oluşturulur.

Sonuç olarak, MFA uygulamak; veri ihlallerine karşı korunmak, hassas bilgilerin yalnızca yetkili kişilerce erişilmesini sağlamak ve kullanıcı hesaplarını daha güvenli hale getirmek için basit ama güçlü bir yöntemdir.

Çok Faktörlü Kimlik Doğrulama Türleri

MFA SMS tabanlı kimlik doğrulama sistemleri, kimlik doğrulayıcı uygulamalar, donanımlar gibi çeşitli yöntemlerle uygulanabilir. Bu sayede kullanıcı hesaplarının güvenliğini büyük ölçüde artırabilir.

Çok faktörlü kimlik doğrulama için kullanılabilecek çeşitli yöntemler vardır. Yaygın olarak kullanılan bazı yöntemler:

Bildiğiniz Bir Şey (Bilgi Faktörü):
- Parolalar/PIN’ler
- Güvenlik soruları
Sahip Olduğunuz Bir Şey (Sahip Olma Faktörü):
- Cep telefonları
- Donanım tokenleri
- Akıllı kartlar
Olduğunuz Bir Şey (Kalıtım Faktörü):
- Biyometrik özellikler (parmak izi, iris taraması, yüz tanıma)
- Ses tanıma
Bulunduğunuz Yer (Konum Faktörü):
- IP coğrafi konumu
- GPS koordinatları
Yaptığınız Bir Şey (Eylem Faktörü):
- Harekete dayalı kimlik doğrulama
- Yazma ritmi

Spring Security ve 2FA

Spring Security, Java uygulamalarında çok faktörlü kimlik doğrulama uygulamak için esnek ve geniş kapsamlı bir destek sağlar. Bu sayede kimlik doğrulama sağlayıcılarını yapılandırıp kimlik doğrulama akışını düzenleyerek, kullanıcıların birden fazla faktör ile kimlik doğrulaması yapmasını sağlar.

Spring Security, çok faktörlü kimlik doğrulama (MFA) olarak da bilinen iki faktörlü kimlik doğrulama (2FA) özelliklerini destekler. Spring Security, 2FA’ı uygulamak için SMS tabanlı kimlik doğrulama, e-posta tabanlı kimlik doğrulama ve zaman tabanlı tek seferlik parolalar (TOTP) dahil olmak üzere çeşitli seçenekler sunar. Aynı zamanda kullanıcılar kimlik doğrulama sürecini biyometrik kimlik doğrulama veya donanım tokenleri gibi diğer kimlik doğrulama faktörlerini kullanacak şekilde özelleştirebilir.

Uygulamanızın gereksinimlerine ve istenen güvenlik düzeyine bağlı olarak SMS tabanlı doğrulama, e-posta tabanlı doğrulama, TOTP, biyometrik kimlik doğrulama ve donanım tokenleri gibi çeşitli türler arasından seçim yapabilirsiniz. Spring Security tarafından sağlanan özelleştirme seçenekleri, MFA uygulamasını özel ihtiyaçlarınıza uyacak şekilde uyarlamanıza olanak tanır.

Spring Security ile Çok Faktörlü Kimlik Doğrulamanın Uygulanması

Spring Security ile MFA uygulanırken her faktör için kimlik doğrulama sağlayıcılarını yapılandırmak ve kimlik doğrulama akışını düzenlemek gerekir. Bazı yaygın MFA türleri ve nasıl uygulayabileceğimize dair bilgiler:

SMS Tabanlı Doğrulama:
- SMS tabanlı bir kimlik doğrulama sağlayıcısı yapılandırılır.
- Oturum açma girişimi üzerine, kullanıcının kayıtlı telefon numarasına tek seferlik bir kod gönderilir.
- Kullanıcıdan SMS ile alınan kodu girmesi istenir.
- Kullanıcı tarafından girilen kod doğrulanır.
E-posta Tabanlı Doğrulama:
- E-posta tabanlı bir kimlik doğrulama sağlayıcısı yapılandırılır.
- Oturum açma girişimi üzerine, kullanıcının kayıtlı e-posta adresine tek seferlik bir kod veya doğrulama bağlantısı gönderilir.
- Kullanıcıdan e-posta yoluyla alınan kodu girmesi veya doğrulama bağlantısına açması istenir.
- Kullanıcı tarafından girilen kod veya açılan bağlantı doğrulanır.
TOTP (Zaman Tabanlı Tek Kullanımlık Parola):
- Bir TOTP kimlik doğrulama sağlayıcısı yapılandırılır.
- Her kullanıcı için gizli bir anahtar oluşturulur ve bu anahtar güvenli bir şekilde paylaşılır.
- Kullanıcılar bir kimlik doğrulayıcı uygulaması (örneğin Google Authenticator, Microsoft Authenticator, Authy) yükler ve TOTP’yi kurmak için ekrandaki QR kodu tarar.
- Oturum açma girişiminde, kullanıcıdan kimlik doğrulayıcı uygulaması tarafından oluşturulan geçerli OTP’yi girmesi istenir.
- Kullanıcı tarafından girilen OTP doğrulanır.
Biyometrik Kimlik Doğrulama:
- Platformlar tarafından sağlanan biyometrik kimlik doğrulama API’leri veya SDK’ları entegre edilir. (örneğin Android için parmak izi tarayıcı API’ı, iOS için Touch ID/Face ID)
- Kullanıcı kaydı sırasında biyometrik veriler elde edilir.
- Oturum açma girişiminde, kullanıcıdan biyometrik verileri kullanarak kimlik doğrulaması yapması istenir.
- Kullanıcı tarafından sağlanan biyometrik veriler, kayıt sırasında sağlanan veriler ile doğrulanır.
Donanım Tokenleri:
- Donanım token’leri sağlayıcılarıyla (örn. RSA SecurID) entegrasyon sağlanır.
- Donanım token’leri ilgili kullanıcılara dağıtılır.
- Oturum açma girişiminde, kullanıcıdan donanım token’inde görüntülenen kodu girmesi istenir.
- Kullanıcı tarafından girilen kod doğrulanır.

Mevcut 2FA yöntemlerini dikkatlice değerlendirmek ve güvenlik, kullanıcı deneyimi, maliyet ve sisteminizle uyumluluk arasında en iyi dengeyi sağlayan yöntemi seçmek önemlidir. Ayrıca ortaya çıkabilecek güvenlik açıklarını veya sorunları tespit etmek için sistemi düzenli olarak test etmek ve izlemek çok önemlidir.

Custom Authentication

Kimlik doğrulama, güvenli web uygulamalarının temelini oluşturur. Kullanıcıların kimliklerinin doğrulanması ve yalnızca yetkili kaynaklara erişmelerinin sağlanması açısından kritik bir işlemdir. Spring Boot Security, varsayılan kimlik doğrulama yapılandırmaları sunar; ancak, özel kullanım durumlarına uyum sağlamak, farklı iş mantıklarını karşılamak veya mevcut sistemlerle entegre olmak için bu sürecin özelleştirilmesi gerekebilir.

Özellikle eski sistemlerle entegrasyon, harici kimlik sağlayıcılarının kullanımı veya tamamen özel kimlik doğrulama mantıklarının uygulanması gereken durumlarda, özelleştirilmiş kimlik doğrulama çözümleri hayati önem taşır.

Spring Security ile özel bir kimlik doğrulama mekanizması oluşturmak için temel olarak iki yapı özelleştirilmelidir:

UserDetailsService interface’i: Kullanıcı adına dayalı olarak kullanıcı bilgilerini yüklemekten sorumludur.
AuthenticationProvider interface’i: Kullanıcının kimlik bilgilerine göre doğrulama işlemini gerçekleştirir.

Bu interface’ler Spring Security kütüphanesinden gelir ve ihtiyaca göre implemente edilerek özelleştirilebilir.

UserDetailsService Interface’ini Uygulamak

UserDetailsService, Spring Security tarafından sağlanan ve kullanıcı bilgilerini yüklemek için kullanılan bir interface’tir (org.springframework.security.core.userdetails.UserDetailsService). Bu interface’i implement ederken, loadUserByUsername(String username) metodunu override ederek kullanıcıyı nasıl bulacağımızı tanımlarız.

Aşağıda basit bir örnekte, kullanıcı bilgileri veritabanından alınmaktadır:

@Service 
@RequiredArgsConstructor 
public class UserDetailsServiceImpl implements UserDetailsService {

private final UserRepository userRepository;

    @Override
    public UserDetails loadUserByUsername(final String username) throws UsernameNotFoundException {
        User user = userRepository.findByUsername(username); 
        if (user == null) { 
            throw new UsernameNotFoundException("User bulunamadı"); 
        } 
        return user;
    }
}

Alternatif olarak, kullanıcı bilgilerini bir CSV dosyasından da okuyabilirsiniz:

@Service
@RequiredArgsConstructor 
public class CsvCredentialLoader implements UserDetailsService {

    @Override
    public UserDetails loadUserByUsername(final String username) throws UsernameNotFoundException {
        Map<String, String> credentials = new HashMap<>();
        try (BufferedReader br = new BufferedReader(new FileReader(csvFilePath))) {
            br.lines().forEach(line -> {
                String[] parts = line.split(",");
                if (parts.length == 2) {
                    credentials.put(parts[0].trim(), parts[1].trim());
                }
            });
        } catch (Exception e) {
            e.printStackTrace();
        }
        //Elde edilen HashMap, User objesine uygun şekilde map edildikten sonra bu User objesi return edilir.
    }
}

AuthenticationProvider Interface’ini Uygulamak

Kullanıcı bilgilerini aldıktan sonra, doğrulama işlemini AuthenticationProvider interface’ini implement eden bir sınıf içinde gerçekleştiririz. Bu sınıf, authenticate() metodunda özel kimlik doğrulama mantığını çalıştırır.

Aşağıda bir dış servisten doğrulama yapan örnek bir uygulama yer alıyor:

@Service
@RequiredArgsConstructor
public class CustomAuthenticationProvider implements AuthenticationProvider {

    private final CustomUserDetailsService userDetailsService;

    private final AuthClient authClient;

    @Override
    public Authentication authenticate(Authentication authentication) throws AuthenticationException {
        String username = (String) authentication.getPrincipal();
        String password = (String) authentication.getCredentials();

        if (authClient.isUserValid(username, password)) {
            return new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities());
        } else {
            throw new BadCredentialsException("Given username and password is wrong");
        }
    
    }

    @Override
    public boolean supports(Class<?> authentication) {
        ...
    }
}

AuthenticationProvider’ın Yapılandırılması

Kendi AuthenticationProvider implementasyonunuzu oluşturduktan sonra, bunu AuthenticationManager konfigürasyonuna dahil etmeniz gerekir. Böylece gelen kimlik doğrulama istekleri sizin provider sınıfınız üzerinden de işlenebilir hale gelir:

public class SecurityConfiguration {
    ...

    @Bean
    public AuthenticationManager authenticationManager(CustomAuthenticationProvider customAuthenticationProvider){
        return new ProviderManager(customAuthenticationProvider);
    }
    ...
}

Bu yapı sayesinde, Spring Security’nin varsayılan davranışları yerine tamamen size özgü bir kimlik doğrulama süreci tanımlamış olursunuz.

CAS (Central Authentication Service)

Merkezi Kimlik Doğrulama Servisi (Central Authentication Service) webde kullanıcıların kimlik doğrulamasının yapılmasını sağlayan bir SSO (Single Sign On) protokolüdür. Kullanıcının login yaptığı bilgiler tek seferlik girilir ve birden fazla uygulamaya giriş yapmak için kullanılır. Bu yapılırken de şifreyi saklamaz ve paylaşmaz. Yetkilendirme gerektiren uygulama kullanıcıyı merkezi ve güvenilir tek bir sunucu olan CAS sunucusuna yönlendirecektir.

CAS akışı aşağıdaki gibidir:

Bir kullanıcı, henüz doğrulanmamış bir web uygulamasına erişmeye çalışır; bu, CAS hizmetini kullanan bir uygulamaya yapılan ilk erişimdir.
Kullanıcı CAS sunucusuna yönlendirilir.
Kullanıcı giriş bilgilerini CAS sunucusunda girer ve CAS sunucusu kullanıcının girişinin gerçek olup olmadığına karar verir.
Kullanıcının girişi doğrulandığında bir servis bileti (service ticket) URL’e iliştirilir.
Uygulama daha sonra CAS sunucusuna bir istek göndererek servis biletini doğrular. Bilet geçerliyse, kullanıcı doğrulanır ve uygulamaya geri döndürülür.
Eğer kullanıcı daha önce aynı oturumda CAS sunucusuna giriş yaptıysa ve session hâlâ geçerliyse, tekrar giriş yapmasına gerek kalmaz. CAS sunucusu doğrudan bir Service Ticket üreterek kullanıcıyı otomatik olarak hedef uygulamaya yönlendirir.

CAS Akış Şeması

CAS’ın bazı önemli bileşenleri aşağıdaki gibidir:

İstemci web tarayıcısı: Bu, CAS hizmetini kullanarak web uygulamasına yerleştirilen bir yazılımdır.
Web uygulaması: Bu, kimlik doğrulaması arayan uygulamadır.
CAS sunucusu: Bu, CAS hizmetini kullanarak kullanıcıları kimlik doğrulamak ve web uygulamalarına erişim sağlamak için kullanılan bağımsız bileşendir.
Arka uç hizmeti: CAS protokolü, kendi HTTP arayüzüne sahip olmayan ancak yine de bir web uygulamasıyla iletişim kurabilen bir veritabanı sunucusunu da içerebilir.

CAS protokolü yalnızca kullanıcıların web uygulamalarına erişimini doğrular ve kullanıcıları yetkilendirmek için kullanılmaz. Bir kullanıcı oturum açma kimlik bilgileriyle CAS sunucusunda oturum açtığında, CAS kimlik doğrulaması kullanıcının kim olduğunu belirleyerek kimin oturum açtığını belgelendirir, ancak uygulama parolayı ve oturum açma bilgilerini doğrudan “görmez”.

Uygulama içinde yetkilendirme erişimi ve ayrıcalıkları olan kullanıcıları belirlemeniz ve sistemde ayarlamanız gerekir. Örneğin, belirli kullanıcı kimliklerini belirli dosyalarda okuma ve yazma yapmalarına izin verecek “yönetici” ayrıcalıklarına sahip olacak şekilde ayarlayabilirsiniz. Bu bir yetkilendirme biçimidir.

Kısacası, kimlik doğrulama bir kullanıcının kimliğini doğrularken, yetkilendirme bir kullanıcının hangi belirli verilere erişimi ve ayrıcalıklara sahip olduğunu doğrular. Sisteminiz hem kimlik doğrulama hem de yetkilendirme gerektirecektir. CAS hizmeti yalnızca kimlik doğrulama parçasını sağlar ve yetkilendirmenin başka bir katmanda da uygulanması gerekir.

Faydaları:

Kolaylık: Kullanıcıların, ek oturum açmalara gerek kalmadan birden fazla web uygulamasına erişmek için bir oturum sırasında yalnızca bir kez CAS sunucusunda oturum açmaları gerekir.
Tutarlılık: Her kullanıcının CAS sunucusunda aynı oturum açma sayfası vardır.
Uygulamalar için daha az çaba gerekir: Web uygulamalarının kendi kimlik doğrulama altyapılarına ve süreçlerine sahip olmaları veya bunları icat etmeye devam etmeleri gerekmez.
Güvenlik: Web uygulamalarının oturum açma kimlik bilgilerine veya parolalara erişimi yoktur.

Önemli Notlar:

CAS protokolü, kullanıcıların bir oturumda bir kez güvenilir bir sunucuda oturum açmasına ve tekrar tekrar oturum açmadan birden fazla uygulamaya erişebilmesine olanak tanıyan tek oturum açma açık kaynaklı bir hizmettir. Bu, üretkenliği, hızı ve son kullanıcı deneyimini artırabilir.
CAS protokolü, tüm kullanıcıların doğrudan oturum açacağı güvenilir ve merkezi bir CAS sunucusunu içerir. Oturum açıldıktan sonra sistem, çerezleri kullanarak kullanıcıyı oturumun geri kalanı için “hatırlar”.
Bir kullanıcı yetkilendirme gerektiren bir web uygulamasına erişmeye çalıştığında, başlangıçta yetkilendirme için CAS sunucusuna yönlendirilir. Yetkilendirilirse, URL’ye bir servis bileti eklenir. Bir kullanıcı başka bir web uygulamasına eriştiğinde, yetkilendirme arka uçta işlenir ve kullanıcının dahil olmasına bile gerek kalmaz.
CAS protokolü güvenlidir, parolaları web uygulamalarından gizler. Ayrıca kullanışlı ve kullanıcı dostudur.

Proxy CAS

Proxy CAS (Proxy Central Authentication Service), CAS protokolünün genişletilmiş bir versiyonudur ve özellikle bir kullanıcıdan elde edilen kimlik doğrulama bilgilerini birden fazla arka uç uygulamasına güvenli bir şekilde iletmek için kullanılır. Proxy CAS, kullanıcıların doğrudan erişemedikleri arka uç hizmetlere erişim sağlamalarına izin verir ve bu erişimi güvenli bir şekilde yönetir.

Proxy CAS Nasıl Çalışır?

Kullanıcı Kimlik Doğrulama: Kullanıcı, bir CAS istemcisine (örneğin, bir web uygulaması) erişir ve CAS sunucusu üzerinden kimlik doğrulama yapar. Başarılı kimlik doğrulama sonrası CAS sunucusu, CAS istemcisine bir Hizmet Bileti (Service Ticket, ST) verir.
Proxy Bileti Alımı: CAS istemcisi, belirli bir arka uç hizmete erişim sağlamak istediğinde, bu hizmet için CAS sunucusundan bir Proxy Bileti (Proxy Ticket, PT) talep eder. Bu süreç, CAS istemcisinin CAS sunucusuna kimliğini kanıtlaması ve arka uç hizmete erişim yetkisi alması anlamına gelir.
Proxy İstemcisi: Proxy CAS senaryosunda, CAS istemcisi, aynı zamanda bir Proxy İstemcisi rolü oynar. Yani, başka bir hizmete kimlik doğrulama bilgilerini ileterek bu hizmete erişim sağlar.
Proxy Bileti Kullanımı: CAS istemcisi, elde ettiği proxy biletini arka uç hizmete iletir. Arka uç hizmet, CAS sunucusuna bu bileti doğrulamak için bir istek gönderir. CAS sunucusu bileti doğruladıktan sonra, arka uç hizmet kullanıcının kimliğini kabul eder ve gerekli kaynaklara erişimi sağlar.

Proxy CAS’in Avantajları

Birden Fazla Hizmete Erişim: Kullanıcıların tek bir kimlik doğrulaması ile birden fazla arka uç hizmete erişim sağlamasına olanak tanır.
Güvenlik ve Güvenilirlik: Proxy CAS, kimlik doğrulama bilgilerini merkezi olarak yönetir ve güvenli bir şekilde arka uç hizmetlere iletir, bu da güvenliği artırır.
Ölçeklenebilirlik: Büyük ölçekli uygulamalarda, birden fazla hizmete erişim gerektiğinde Proxy CAS bu işlemleri yönetmek için uygun bir çözüm sunar.

Kullanım Senaryoları

Web Portalları: Bir kullanıcı portal üzerinden oturum açar ve ardından arka uçta farklı servislerle (örneğin, e-posta, dosya depolama) etkileşime geçer. Proxy CAS, bu senaryoda kullanıcı kimliğini ve yetkisini güvenli bir şekilde arka uç servislere iletir.
Mikroservis Mimarileri: Mikroservislerin kullanıldığı sistemlerde, kullanıcı kimlik doğrulama bilgileri birden fazla mikroservise güvenli bir şekilde iletilmesi gerektiğinde Proxy CAS kullanılabilir.
API Geçitleri: API geçitleri, kullanıcı kimlik doğrulamasını yönetmek ve arka uç API’lere erişim sağlamak için Proxy CAS kullanabilir.

Dikkat Edilmesi Gerekenler

Güvenlik: Proxy CAS iletilen biletlerin ve kimlik doğrulama bilgilerinin güvenliğini sağlamak için SSL/TLS gibi güvenli iletişim protokollerinin kullanılması kritik öneme sahiptir.
Doğrulama ve Yetkilendirme: Her biletin doğrulanması ve arka uç hizmetlerin doğru yetkilendirme kontrollerini uygulaması önemlidir. Proxy CAS senaryolarında, doğru hizmetlere doğru yetkilerle erişim sağlandığından emin olunmalıdır.
Ölçeklenebilirlik: CAS sunucusunun artan istek hacmini kaldırabilmesi için ölçeklenebilir yapıda olması gerekmektedir.

Proxy CAS, kullanıcılara ve uygulamalara esneklik sağlarken, güvenli kimlik doğrulama ve yetkilendirme süreçlerini merkezi olarak yönetme yeteneği sunar. Özellikle kompleks sistemlerde birden fazla servise erişim gerektiğinde Proxy CAS etkili bir çözüm olabilir.

Spring Security CAS

Spring Security ve CAS (Central Authentication Service) birlikte kullanıldığında, güvenli bir şekilde kimlik doğrulama ve yetkilendirme işlemleri merkezi olarak yönetilir. Bu entegrasyon, büyük ölçekli uygulamalarda kullanıcıların tek bir oturum açma (Single Sign-On, SSO) ile birden fazla uygulamaya erişimini sağlar.

CAS Sunucusunun Kurulumu ve Yapılandırılması: İlk adım olarak, merkezi kimlik doğrulama görevini üstlenecek bir CAS sunucusunun kurulması ve çalışır durumda olması gerekmektedir. CAS sunucusu, çeşitli kimlik doğrulama mekanizmalarını (örneğin LDAP, veritabanı gibi) destekleyecek şekilde yapılandırılmalıdır.

Spring Boot Projesinin Oluşturulması: Bir Spring Boot projesi oluşturularak, spring-boot-starter-security bağımlılığı projeye dahil edilmelidir. Ayrıca, CAS entegrasyonunu sağlamak için gerekli olan spring-security-cas gibi bağımlılıkların da eklenmesi gerekmektedir.

<dependencies>
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-security</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework.security</groupId>
		<artifactId>spring-security-cas</artifactId>
	</dependency>
</dependencies>

CAS Tabanlı Güvenlik Yapılandırmasının Oluşturulması: Spring Security’nin, CAS kimlik doğrulama mekanizması ile uyumlu çalışacak şekilde yapılandırılması gerekmektedir. Bu amaçla, WebSecurityConfigurerAdapter sınıfını extend bir yapılandırma sınıfı tanımlanarak CAS protokolüne uygun şekilde ayarlamalar yapılmalıdır.

@Configuration @EnableWebSecurity public class SecurityConfig {

@Value(“${cas.server.url}”) private String casServerUrl;

@Value(“${cas.client.service-url}”) private String casClientServiceUrl;

@Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(authz -> authz .anyRequest().authenticated() ) .exceptionHandling(e -> e .authenticationEntryPoint(casAuthenticationEntryPoint()) ) .addFilter(casAuthenticationFilter(authenticationManager(http))) .logout(logout -> logout .logoutSuccessHandler(logoutSuccessHandler()) .permitAll() );
```
1
 return http.build();  }
```
@Bean public AuthenticationManager authenticationManager(HttpSecurity http) throws Exception { return http.getSharedObject(AuthenticationManagerBuilder.class) .authenticationProvider(casAuthenticationProvider()) .build(); }

@Bean public CasAuthenticationFilter casAuthenticationFilter(AuthenticationManager authenticationManager) { CasAuthenticationFilter filter = new CasAuthenticationFilter(); filter.setAuthenticationManager(authenticationManager); filter.setFilterProcessesUrl(“/login/cas”); return filter; }

@Bean public CasAuthenticationProvider casAuthenticationProvider() { CasAuthenticationProvider provider = new CasAuthenticationProvider(); provider.setServiceProperties(serviceProperties()); provider.setTicketValidator(casTicketValidator()); provider.setUserDetailsService(customUserDetailsService()); provider.setKey(“casAuthProviderKey”); return provider; }

@Bean public ServiceProperties serviceProperties() { ServiceProperties properties = new ServiceProperties(); properties.setService(casClientServiceUrl + “/login/cas”); properties.setSendRenew(false); return properties; }

@Bean public Cas20ServiceTicketValidator casTicketValidator() { return new Cas20ServiceTicketValidator(casServerUrl); }

@Bean public CasAuthenticationEntryPoint casAuthenticationEntryPoint() { CasAuthenticationEntryPoint entryPoint = new CasAuthenticationEntryPoint(); entryPoint.setLoginUrl(casServerUrl + “/login”); entryPoint.setServiceProperties(serviceProperties()); return entryPoint; }

@Bean public LogoutSuccessHandler logoutSuccessHandler() { SimpleUrlLogoutSuccessHandler successHandler = new SimpleUrlLogoutSuccessHandler(); successHandler.setDefaultTargetUrl(casServerUrl + “/logout?service=” + casClientServiceUrl); return successHandler; }

@Bean public UserDetailsService customUserDetailsService() { return new CustomUserDetailsService(); } }

Uygulama Ayarlarının Yapılandırılması: application.properties veya application.yml dosyasında, CAS sunucusu ve istemciye ait gerekli URL yapılandırmaları yapılmalıdır.

cas.server.url=https://cas-server.example.com/cas
cas.client.service-url=https://client-app.example.com

CAS Tabanlı Giriş Noktasının Tanımlanması: login ve logout işlemleri için gerekli CAS filtreleri ve giriş noktaları tanımlanmalıdır. Bu işlemlerin doğru bir şekilde çalışabilmesi için CAS sunucusunun doğru URL’ler ile yapılandırıldığından emin olunmalıdır.

Adımlar:

CAS Giriş Filtresinin Yapılandırılması

CasAuthenticationFilter sınıfı, CAS tabanlı kimlik doğrulama işlemleri için kullanılan filtredir. Bu filtrenin, CAS sunucusu ile doğru bir şekilde iletişim kurabilmesi için yapılandırılması gereklidir.

Aşağıdaki kod örneği, CAS giriş filtresinin nasıl tanımlanacağını göstermektedir:

@Bean
public  CasAuthenticationFilter casAuthenticationFilter() throws  Exception {
	CasAuthenticationFilter casAuthenticationFilter = new  CasAuthenticationFilter();
	casAuthenticationFilter.setAuthenticationManager(authenticationManager());
	casAuthenticationFilter.setFilterProcessesUrl("/login/cas");
	return  casAuthenticationFilter;
}

CAS Kimlik Doğrulama Giriş Noktasının Belirlenmesi

CAS kimlik doğrulama giriş noktası, kimlik doğrulama gerektiren bir isteğin CAS sunucusuna yönlendirilmesini sağlar. CasAuthenticationEntryPoint sınıfı bu işlevi yerine getirir.

Giriş noktası, CAS sunucusunun oturum açma URL’sine yönlendirme yapacak şekilde ayarlanmalıdır. Örneğin:

@Bean
public  CasAuthenticationEntryPoint casAuthenticationEntryPoint() {
	CasAuthenticationEntryPoint entryPoint = new  CasAuthenticationEntryPoint();
	entryPoint.setLoginUrl(casServerUrl + "/login");
	entryPoint.setServiceProperties(serviceProperties());
	return  entryPoint;
}

Spring Security Yapılandırmasına CAS Entegrasyonunun Eklenmesi

Spring Security yapılandırma sınıfında, CAS giriş filtresi ve giriş noktası eklenmelidir. HttpSecurity yapılandırmasında bu filtreyi ekleyin ve giriş noktası ayarlarını yapın:

@Override
protected  void  configure(HttpSecurity http) throws  Exception {
	http.authorizeRequests()
		.anyRequest().authenticated()
		.and()
		.exceptionHandling()
		.authenticationEntryPoint(casAuthenticationEntryPoint())
		.and()
		.addFilter(casAuthenticationFilter())
		.logout().logoutSuccessUrl(casServerUrl + "/logout").permitAll();
}

Single Logout (Tek Oturum Kapatma) Desteğinin Sağlanması: CAS sunucusu üzerinden oturum kapatıldığında, bağlı olan tüm istemci uygulamalarda oturumların kapatılmasını sağlamak için uygun yapılandırmalar yapılmalıdır. Bu işlem, kullanıcıların tüm uygulamalardan güvenli bir şekilde çıkış yapmasını sağlar.

Adımlar:

Logout Success Handler Tanımlanması

Spring Security, oturum kapatma işlemlerini yönetmek için LogoutSuccessHandler arayüzünü sağlar. CAS ile Single Logout entegrasyonu için bu arayüz özelleştirilir.

Kullanıcının oturum kapatma isteği yapıldığında, CAS sunucusuna yönlendirilir. Aşağıdaki örnek, bir CAS LogoutSuccessHandler tanımlamaktadır:

@Bean
public  LogoutSuccessHandler logoutSuccessHandler() {
	SimpleUrlLogoutSuccessHandler successHandler = new  SimpleUrlLogoutSuccessHandler();
	successHandler.setDefaultTargetUrl(casServerUrl + "/logout?service="  + casClientServiceUrl);
	return  successHandler;
}

Logout Request Filter Yapılandırılması

CAS sunucusu, oturum kapatma işlemini başlatmak için istemci uygulamalarına bir logoutRequest gönderir. Bu isteklerin işlenmesi için SingleLogoutFilter ve LogoutFilter kullanılır.

SingleLogoutFilter, gelen logoutRequest isteklerini dinleyerek oturum kapatma işlemlerini başlatır:

@Bean
public  SingleLogoutFilter singleLogoutFilter() {
	return  new  SingleLogoutFilter(casServerUrl + "/logout", new  SecurityContextLogoutHandler());
}

Spring Security Yapılandırmasında Logout Filtrelerinin Eklenmesi

Yukarıda tanımlanan filtreler ve logout success handler, Spring Security yapılandırmasına eklenir. Bu, kullanıcıların tüm bağlı uygulamalardan çıkış yapmasını sağlar:

@Override
protected  void  configure(HttpSecurity http) throws  Exception {
	http.authorizeRequests()
		.anyRequest().authenticated()
		.and()
		.exceptionHandling()
		.authenticationEntryPoint(casAuthenticationEntryPoint())
		.and()
		.addFilter(casAuthenticationFilter())
		.addFilterBefore(singleLogoutFilter(), CasAuthenticationFilter.class)
		.logout()
		.logoutSuccessHandler(logoutSuccessHandler())
		.permitAll();
}

Spring Security ve CAS entegrasyonu, merkezi kimlik doğrulama ve Single Sign-On (SSO) özellikleri sağlayarak kullanıcı deneyimini geliştirmekte ve güvenliği artırmaktadır. Yukarıda belirtilen adımlar izlenerek, Spring tabanlı bir uygulamanın CAS sunucusu ile entegre edilmesi ve kullanıcıların tek bir oturum açma işlemi ile birden fazla uygulamaya güvenli bir şekilde erişim sağlaması mümkün hale getirilebilir. Bu entegrasyon, kurumsal uygulamalar için güvenilir ve ölçeklenebilir bir güvenlik çözümü sunmaktadır.

Serinin bir sonraki yazısına Parolasız Kimlik Doğrulama Yaklaşımları adresinden ulaşabilirsiniz.

Kaynakça

10.01.2025

« Güvenli Parola Depolama Yaklaşımları Parolasız Kimlik Doğrulama Yaklaşımları »