Keycloak 26.6.0: Beş önizleme özelliği üretime hazır hale geliyor

Keycloak projesi açık kaynak kimlik sağlayıcısının 26.6.0 sürümünü yayınladı. Odak noktası, önizleme durumundan çıkan ve artık tam olarak desteklendiği kabul edilen beş özelliktir. Kubernetes ortamlarında Keycloak kullanan kuruluşlar için sıfır kesinti süreli yama sürümleri ve birleştirilmiş istemci kimlik doğrulaması muhtemelen özellikle alakalı olacaktır.

Duyuruya göre muhtemelen en pratik yenilik: Gelecekte yama sürümleri, hizmet kesintiye uğramadan küçük sürümler akışı içinde Sürekli Güncellemeler olarak kurulabilecek. Geliştirme ekibi, bireysel düğümler kapatıldığında hata mesajlarını önleyen geliştirilmiş Graceful HTTP Shutdown özelliğiyle birlikte, konteynerli dağıtımların merkezi bir gereksinimini ele alıyor. Sürüm notlarına göre yama sürümlerinden kesinti yaşamadan yararlanmak için Keycloak operatörünün güncelleme stratejisini “Otomatik” olarak ayarlamanız yeterli.

Ek olarak proje, birleştirilmiş istemci kimlik doğrulamasını üretken duruma yükseltti. Bu özellik, müşterilerin bir güven ilişkisi kurulur kurulmaz harici bir sağlayıcıdan gelen mevcut kimlik bilgilerini kullanmasına olanak tanır. Bu, Keycloak'ta bireysel müşteri sırlarına olan ihtiyacı ortadan kaldırır. Harici OpenID Connect kimlik sağlayıcılarından ve Kubernetes hizmet hesaplarından gelen istemci iddiaları desteklenir. Birden fazla kimlik sağlayıcıya sahip kuruluşlar, gizli dizilere yönelik yönetim çabalarını önemli ölçüde azaltır. Ancak SPIFFE OAuth istemci kimlik doğrulaması, temel belirtim henüz sonlandırılmadığından önizleme durumunda kalır.

JWT İş Akışları ve Yetkilendirme

Artık desteklenen iş akışlarıyla Keycloak, Kimlik Yönetişimi ve Yönetimi (IGA) alanından temel işlevleri getiriyor. Yöneticiler, YAML dosyalarında kullanıcı ve istemci yaşam döngüsü yönetimi gibi bölge görevlerini tanımlayabilir ve bunları olaylara, koşullara veya programlara göre otomatikleştirebilir. Sürüm ayrıca yeni yerleşik adımlar, bir sorun giderme kılavuzu ve iş akışı motorunda çeşitli iyileştirmeler içerir.

RFC 7523 kapsamında JWT Yetkilendirmesi artık üretime hazır olarak kabul ediliyor. OAuth 2.0 erişim belirteçleri için harici JWT iddialarının değiş tokuşuna olanak tanır ve bu nedenle harici belirteçlerin dahili belirteçlere dönüştürülmesi gereken kullanım durumlarına yardımcı olur. Beşli, önceki Arquillian tabanlı yaklaşımın yerini alan yeni Keycloak Test Çerçevesi ile tamamlanıyor.

Deneysel MCP ve Java 25 desteği

Beş ana özelliğe ek olarak sürüm daha fazla yenilik sunuyor. Keycloak deneysel olarak artık OAuth 2.0 istemci meta verilerini tanımlamak için yeni ortaya çıkan bir standart olan CIMD'yi (OAuth İstemci Kimliği Meta Veri Belgesi) desteklemektedir. Model Bağlam Protokolü (MCP), 2025-11-25 sürümünden itibaren CIMD gerektirdiğinden Keycloak, gelecekte MCP senaryoları için yetkilendirme sunucusu olarak kullanılabilir.

Legacy Token Exchange V1'in yerini alması amaçlanan Identity Brokering V2 API'si de önizleme aşamasında yayınlanacak ve SAML protokolü için Yükseltilmiş kimlik doğrulaması da yayınlanacak. Kuruluşlar aynı zamanda bir kapsam içindeki çatışmaların adlandırılmasından kaçınan, örgütsel olarak izole edilmiş grup hiyerarşilerinden de yararlanır.

Altyapı açısından bakıldığında, Keycloak artık OpenJDK 25'i desteklemektedir. Ancak konteyner görüntüsü, FIPS uyumluluğunu sağlamak için hala Java 21 kullanmaktadır; dolayısıyla, düzenlenmiş ortamlardaki kuruluşlar için her şey aynı kalır. Java 21'e sahip mevcut dağıtımlar değişmeden çalışmaya devam etmelidir. Diğer iyileştirmeler arasında Kubernetes ve OpenShift'te otomatik güven deposu başlatma, Traefik ve Envoy için yeni istemci sertifikası arama sağlayıcıları ve belirteçler ve tanımlama bilgileri gibi hassas bilgileri filtreleyen revize edilmiş HTTP erişim günlükleri yer alıyor.

Notları güncelle

Keycloak 26.6.0'a yükseltme yapmadan önce yöneticilerin Yükseltme Kılavuzundaki önemli değişiklikleri incelemesi gerekir. JavaScript tabanlı politikalar artık komut dosyası oluşturma işlevinin etkinleştirilmesini gerektiriyor. İstemci URI'leri, JWT yetkilendirmesi vermek için HTTPS'yi ve veren yapılandırmasını kullanmalıdır ve istemci iddiaları, bir sağlayıcıyı benzersiz şekilde tanımlamalıdır.

(harita)