kazimolmez adlı üyeden alıntı: mesajı görüntüle
Kodlarda genel olarak bi amatorlük ve karışıklık var ama bunlar çalışmasına engel şeyler değil. Burda da verebileceğim tek tavsiye session verilerini encrypt/decrypt ederek kullanman. Atarken encrypt, okurken decrypt edersen bi tık dhaa güvenli olur. Her sayfa da bu kontrolleri yapmak sayfa performansını düşürebilir o durumda örnek olarak 5dk da bir kontrol yapacak şekilde güncelleyebilirsin.
berkantipek adlı üyeden alıntı: mesajı görüntüle
Büyük bela bu Keycloak falan kullan zaten çoğu full-fledged auth çözümünün upstream IdP desteği oluyor, AD'yi oraya bağlarsın. AuthN kolay da, AuthZ çok daha karmaşık bir konu. Orada policy engine gibi mevzular devreye giriyor, onu da muhtemelen Intranet'teki uygulamaların yanına Envoy ve OPA'yı sidecar olarak yerleştirip falan çözebilirsin. Olmadı uygulama kendisine paslanan JWT'ı validate ederken claim'leri kendi içinde çözümleyip ona göre yanıt döner, ama haliyle bu durumda her uygulamanın kodunda değişiklik yapılması gerekiyor.

Benim sizin koddan anladığım her uygulama PHP ile yazılma, session'lar da ortak. Her şeyi merkezileştirmeniz sizin yararınıza olur, bu pek akıl işi gelmedi bana. Bir de auth server'dan geçtikten sonra bir daha niye uygulamalara ayrı ayrı auth olunması gerekiyor onu anlamadım, bu zaman AD ve SSO kullanmanın mantığına aykırı bu şekilde.
Öneriler için teşekkürler.

@berkantipek; Uygulama tamamen generic PHP ile yazılmış durumda. Keycloak ile bir identify server oluşturup bu sunucu üzerinden mi doğrulama yaptırmamızı öneriyorsunuz?