Keycloak Nedir? Neye Çözüm Getirmektedir? ve Temel Kavramları Nelerdir? #1

Merhaba,

Bu içeriğimizde; geliştirdiğimiz yazılımlarımızda, yetkilendirme işlemleriyle birlikte kimlik ve erişim yönetimi (IAM – Identity & Access Management) süreçlerindeki problemleri efektif bir şekilde çözebilmek için kurumsal ölçekte geliştirilmiş olan Keycloak platformunu baştan sona teorik olarak değerlendirecek ve böylece, ne olduğunu tam teferruatlı anlayıp, bundan sonraki konuya dair içeriklere sağlam bir bilgi zemini oluşturmuş olacağız. O halde fazla uzatmaksızın buyurun başlayalım…

Keycloak; özellikle microservice mimarileri, SPA’ler (Angular, React vs.), mobil uygulamalar ve API’ler için merkezi kimlik yönetimi sağlayan bir teknolojidir.

Keycloak Nedir?

Keycloak, uygulamaların kullanıcı doğrulama (authentication), yetkilendirme (authorization), Single Sign-ON (SSO) ve token üretimi ve yönetimi gibi işlerinin sorumluluğunu uygulamadan bağımsız bir şekilde yürütebilmemizi ve bunun yanında merkezi ve güvenli bir sunucuya taşıyarak bir IAM platformu oluşturmamızı sağlayan open source bir teknolojidir.

Temelde; OAuth 2.0, OpenID Connect (OIDC) ve SAML 2.0 protokollerini kullanmaktadır.

Ne Amaçla Üretilmiştir?

Eskiden yazılımlarımızda klasik kullanıcı tabloları, şifreleme algoritmaları, login ekranları, rol kontrolleri, token üretimi vs. gibi uygulamanın genel mahiyetinin dışında oldukça alakasız iş yükleriyle ilgilenmek mecburiyetindeydik. Artık günümüzde bu tarz bir davranıştan öte, bu ihtiyaçların tamamını merkezi bir servis olarak ayırabilecek ve farklı bir sunucu üzerinden bu hizmetleri sağlayabilecek bir yaklaşımı benimsemekteyiz. Haliyle Keycloak ile bu yaklaşımı kolayca uygulayabilmekte ve tek noktadan kullanıcı yönetiminden tutun, güvenlik prosedürlerini standartlara bağlamaya, SSO sağlamaya, yetki operasyonlarını koddan ayırmaya ve farklı uygulamaları aynı kimlik sistemiyle konuşturmaya kadar birçok işlemi rahatlıkla sağlayabilmekteyiz.

Keycloak İle Neler Yapabiliriz?

Keycloak’ın birçok yeteneği mevcuttur. Bizler için öne çıkan bazı yeteneklerini aşağıda özetlemeye çalışalım;

• Authentication
  Bir yazılım sisteminin kullanıcıya sorduğu ilk ve en temel soru ‘Sen kimsin?‘dir. Keycloak, bu sorunun cevabını tek bir yöntemle sınırlamamaktadır. Çünkü gerçek hayatta da insanlar tek tip değildirler ve tek bir yöntemle tanınmamaktadırlar. Bu mantıkla Keycloak’un aşağıdaki senaryolar eşliğinde Authentication süreçlerine eşlik edebildiğini söyleyebiliriz :
  • Username / Password : En klasik senaryodur. Kullanıcı bir ekrana gelir, kullanıcı adı ve şifresini girer ve kimliğini doğrular. Burada Keycloak bizlere bir login sayfası sağlayabilmektedir. Böylece hash’leme, güvenlik, brute-force koruması sorumluluklarının Keycloak tarafından üstlenilmesinin yanında tüm bu işlemlerin sorumluluğu geliştirici omuzlarından alınabilir.
  • Social Login (Google, GitHub vs.) : Sosyal medyalar üzerinden yapılan login işlemlerinde Keycloak bir aracı gibi davranış sergiler. Bu özelliği sayesinde uygulama açısından kullanıcının nereden geldiğinin bir önemi olmayacaktır. İster Google’dan gelebilir, istek LDAP’tan, isterse de manuel… Hepsi Keycloak açısından aynı kullanıcıdır, dolayısıyla uygulama açısından da…
  • LDAP / Active Directory : Kurumsal dünya için olmazsa olmaz diyebileceğimiz bu tarz senaryolarda Keycloak, teknoloji açısından eski dünya ile yeni dünya arasında bir köprü görevi görebilir ve bu tarz çalışmalara eşlik edebilir.
  • MFA (OTP, Authenticator) : Keycloak; telefon uygulaması, SMS, OTP ve donanımsal anahtar gibi ikinci katmanları kolayca destekleyebilmekte ve oldukça minimize kodla bu tarz authentication entegrasyonları sağlayabilmektedir.
• Authorization
  Sistem kullanıcıyı doğruladıktan sonra ikinci olarak ‘Yetkilerin nelerdir?’ sorusunu yöneltir. Haliyle burada Authorization devreye girer. Keycloak, authorization süreçlerinde de oldukça etkin çözümler sunmaktadır :
  • Realm Roles : Realm, Keycloak için önemli ve bence kritik bir kavramdır. Ne olduğuna içeriğimizin sonraki satırlarında hususi odaklanıyor olacağız. Ama şimdilik kısa bir açıklama yapmamız gerekirse eğer -birbirinden izole edilmiş bir yönetim alanı- olduğunu söylememiz yeterli olacaktır. Hoca ney yani bu realm? dediğinizi duyar gibiyim… Sabredin, uygun başlık altında tam olarak anlayacağınızı umuyorum. Bizler şimdilik realm tabanlı yetkilendirmeye odaklanırsak eğer evet, Keycloak’da realm seviyesinde yetkilendirme sağlanabildiğini ifade edelim ve devam edelim… İleride anlayacaksınız 😉
  • Client Roles : Keycloak ile kullanıcılara client (uygulama) seviyesinde yetkilendirme imkanı sağlanabilmektedir. Bunu şöyle örneklendirebiliriz; bir kullanıcı sistem genelinde sıradan kullanıcı olabilir. Ancak sadece rapor uygulamasında (client) admin yetkisine sahip olabilir. İşte böyle senaryoları Keycloak kolayca desteklemektedir.
    

    Unutma! Bu örnekteki ayrım microservice mimarisinin bel kemiğidir!

  • Group + Role Kombinasyonu : Gerçek hayatta nasıl ki insanlar tek tek rol almazlar, yazılımlarda da öyledir. Keycloak ile grup oluşturabilir, gruba göre rol tanımlayabilir ve kullanıcıları gruplara ekleyerek rollerle ilişkilendirebilirsiniz.
  • Attribute Tabanlı Yetkilendirme : Keycloak’da attribute tabanlı yetkilendirmeler ile rolden öte nitelik seviyesinde yetkilendirmeler de sağlanabilmektedir. Bu oldukça önemli ve Keycloak’ın farkını ortaya koyan özelliklerden birisidir. Buna da bir örnek vermek gerekirse eğer; ‘rolü var ama sadece kendi tenant’ına ait veriyi görsün’ şeklinde bir detay/nitelik tanımlaması isteniyorsa burada attribute tabanlı yetkilendirme davranışından istifade edilebilir. Bu yaklaşımın, policy tabanlı düşünmenin kapısını araladığını vurgulamış olalım.
• Token Yönetimi
  Artık sistemde kullanıcı kimliği hem doğrulandı hem de yetkilendirildi. Sırada uygulamalar arası taşınabilir bir kanıta geldi. İşte burada token yapılanması söz konusu olacaktır. Evet, Keycloak token ile ilgili tüm gereksinimleri sağlamaktadır :
  • Access Token : Kullanıcının hangi yetkilere sahip olduğunu ve kim olduğunu ifade eden kısa ömürlü bir karttır, yani token’dır. Bu token, tüm isteklerde taşınarak API’lere gönderilir ve API’ler bu token üzerinde rol var mı? süresi dolmuş mu? imzalı mı? şeklinde sorular eşliğinde gerekli kontrolleri sağlarlar.
  • Refresh Token : Access Token’ın süresi bittiğinde kullanıcıyı tekrar login ettirmemek için geliştirilmiş davranışsal bir yöntemdir.
  • ID Token : Özellikle frontend uygulamalar için kullanıcıya dair kullanıcı adı, email, profil bilgileri vs. gibi değerleri sunabilmek için kullanılan bir token’ıdr.
• SSO & Federation
  

  SSO’nun özü şudur; her kapıda kimlik göstermek zorunda kalmayalım…

  Tıpkı e-devlet’te olduğu gibi… Kullanıcı e-devlet’ten login olur, ardından diğer devlet sitelerine rahatlıkla giriş yapabilir. Aynı mantığı Keycloak ile de rahatlıkla yürütebilir ve ortak ve merkezi bir oturum yöneticisi olarak kullanabilirsiniz.

• Extensibility
  Tüm bunlara nazaran Keycloak tabi ki de kapalı bir kutu değildir ve ihtiyaç doğrultusunda özelleştirilebilmektedir. Login anında özel kontrol eklenebilir, token üretilirken ekstra bilgiler eklenebilir, özel kullanıcı doğrulamaları sağlanabilir.

Keycloak’un Rakiplerine Göre Avantajları Nelerdir?

Keycloak, özellikle IdentityServer gibi birden çok muadili ve alternatifi olan bir platformdur. Keycloak’u bu muadillerinden ayıran birkaç ayırt edici özelliği sayabiliriz. Örneğin; bunlardan open source ve ücretsiz olması en önemli özelliklerindendir diyebiliriz. Ayrıca Keycloak tercih edildiği taktirde, bu platforma karşın teknik, mimarisel ve mali olarak kilitlenme/bağımlı olma vaziyetini ifade eden Vendor Lock-in durumu söz konusu olmamakta, bundan kaynaklı istendiği yere deploy edilebilmekte ve Docker / Kubernetes teknolojileri kullanılarak rahatlıkla yönetilebilmektedir.

Keycloak’u muadillerinden ayıran bir başka öne çıkan özelliği ise realm yapısında bir tasarıma sahip olmasıdır. İçeriğimizin sonraki satırlarında daha teferruatlı incelendiğinde anlaşılacağı üzere realm yapısı, özellikle Multi-Tenancy sistemlerde oldukça avantaj sağlamaktadır. Bunun yanında özelleştirilebilir login UI ekranları ve Admin panelinin olması ekstradan avantaj sağlamaktadır.

Tüm bunların dışında önceki satırlarda ifade edildiği üzere Keycloak OAuth 2.0, OIDC ve SAML gibi birçok protokolü desteklemektedir. Halbuki günümüzde adı geçen onca modern sistem yalnız OAuth2’yi desteklemekteyken Keycloak, legacy sistemlerle de kolaylıkla entegre olabilmektedir.

Keycloak Kimler İçin İdealdir?

Keycloak’un, kullanıcı sayısının belirli bir eşiğin üstünde olduğu ya da düzenli artış gösterdiği ve bunun getirisi olarak aşırı rol ve karmaşık yetkilendirmelerin söz konusu olduğu kurumsal proje çalışmalarında, yetki çalışmalarını koddan ayırması ve denetlenebilir ve izlenebilir bir yapı sunması nedeniyle oldukça ideal olacağı kanaatindeyim. Ayrıca bu tarz projelerde güvenlik ihlali ‘hata’dan öte ciddi ‘kriz’ ortamı doğurabileceğinden dolayı güvenliği kişiye/geliştiriciye değil standartlara bağlayacağından ve böylece daha emin bir kimlik yönetim sistemi ortaya koyacağından ekstradan planlama süreçlerinde Keycloak’un düşünülmesi ve değerlendirilmesi gerektiğini öneriyorum.

Ayrıca Keyclock, microservice mimarisi için de oldukça uygundur diyebiliriz. Ne de olsa, bir microservice mimarisinde ayrı deploy süreçlerinden geçen ve her biri ayrı ekipler tarafından inşa edilen birden fazla servis varlık göstermektedir. Şimdi düşünürsek eğer her servisin kendi login işleminin olması ve her servisin token’ı farklı şekilde yorumlaması oldukça külfet bir durum olsa gerek. Ki böyle durumlarda genellikle yetkilendirme standartlarında zaafiyet olmazsa olmazdır! Yani kimin de ‘Admin’ olan rol adı, diğerinde ‘ADMIN’ şeklinde varlık gösterebilmektedir. Anlayacağınız, bu tarz kompleks süreçler için kimlik yönetim merkezini tek bir noktaya almak ve tek bir standart otorite yapısı sağlamaya çalışmak en ideal yaklaşım olacaktır. Her bir microservice, kullanıcıyı tanımak ve token’ı doğrulamakla uğraşmak yerine bu süreçteki tüm sorumluluğu Keycloak’a bırakarak sadece işine odaklanabilecektir.

Bunlarında dışında Keycloak için en ideal çalışmalardan birinin Multi-tenant olarak tasarlanmış mimariler olduğunu da söyleyebiliriz. Multi-tenant demek, aynı sistemde birbirinin verisini asla göremeyen yani birbirlerinden izole edilmiş olan birden fazla müşteri / kooperatif / firma demektir. Haliyle izolasyon hassasiyetiyle geliştirilmiş olan bu tarz sistemlerde yanlış bir yetkiden yahut yanlış bir filtrelemeden kaynaklı ciddi risklerle karşılaşma olasılığı yüksektir. Keycloak’un realm mantığı sayesinde, multi-tenant yapısına uygun bir altyapı sağlanmakta ve rahatlıkla müşterilerden yetkilere kadar her şeyin bir birinden ayrılabileceği doğal bir ortam / zemin sunulmaktadır. Evet, bu tarz bir ihtiyaç durumuna karşın gerekli olan izolasyon davranışı, kodla değil Keycloak’un mimarisiyle kolaylıkla sağlanabilmektedir. İşte bunun için biçilmiş kaftandır diyebiliriz.

Şunu net söyleyebiliriz ki, geliştirilen yazılımlarda -iyi niyetle- tasarlanmış güvenlik anlayışı pek tasvip ettiğimiz bir yaklaşım değildir! Hele hele bu, kritik operasyonlar yürüten yazılımlar için yabana atılabilecek bir konu hiç değildir! Bir yazılımda olmazsa olmaz diyebileceğimiz şifreleme, token, refresh flow, MFA, brute-force koruması vs. gibi tüm bu çağdaş yöntemler öyle haybeden düşünülüp üretilmiş yöntemler değildir! Bilakis hepsi sürekli güncellenen tehdit bilgisi eşliğinde yılların tecrübesiyle üretilmiş yöntemlerdir. Dolayısıyla benimsenin güvenlik anlayışının, o gün bilinen tehditlere maksimize cevap verebilecek ölçüde yeteneklere sahip olması en doğal haliyle beklenmektedir.

Tabi diğer perspektiften bakıldığında, geliştirici açısından ‘ben bunu hallederim’ denmesi her ne kadar özgüven olsa da nihayetinde güvenlik değildir! Haliyle bu sezgiye sırt dayanmaksızın doğru güvenlik anlayışıyla sistem tasarımı gerçekleştirilmelidir.

Keycloak tüm bu kaygıları ortadan kaldırarak bizlere test edilmiş akışları, standartlara uygun implementasyonları ve sürekli gelişen güvenlik modellerini hızlıca sunabilmekte ve böylece geliştiricilerin beşeri kaynaklı risklerini göze almaksızın, sadece iş problemlerinin çözümüne odaklanılmasını sağlayarak, güvenlik olayını baştan sona pratik bir şekilde halledebilmemizi sağlamaktadır.

Tüm bunların aksine tabi ki de Keycloak’ın tercih edilmemesi gereken durumları olduğunu da söylemekte fayda görmekteyim. Şöyle ki; Keycloak, her ne kadar güçlü ve kapsamlı bir kimlik yönetim çözümü olsa da her proje için doğru tercih değildir! Özellikle küçük ölçekli, tek uygulamadan oluşan ve kullanıcı sayısı sınırlı olan projelerde Keycloak kullanmak gereksiz bir ağırlık oluşturacak ve hatta ihtiyaca karşın yapılan çalışma ciddi bir maliyet olarak bizlere yansıyacaktır. Evet, sadece birkaç kullanıcıya yönelik olan ya da basit giriş-çıkış mekanizmasının yeterli olduğu senaryolarda, ayrı bir kimlik sunucusu kurmak, yapılandırmak ve bakımını üstlenmek, sağladığı faydadan çok zarara sebebiyet verecektir. Benzer mantıkla, yalnızca lokal ortamda çalışacak olan ve özellikle social login, SSO, token bazlı mimari veya merkezi yetkilendirme gibi ihtiyaçları olmayan sistemlerde Keycloak kullanmaya çalışmak süreci fazlasıyla baltalayacak ve karmaşıklaştıracaktır. Buradan anlayacağınız, Keycloak’dan istifade edebilmek için belirli bir eşiğin üstündeki projeleri hedeflemek daha doğru olacak ve ancak doğru şartlarda faydasından azami bir şekilde istifade ediliyor olacaktır.

Uzun lafın kısası Keycloak, kimlik yönetimi sorumluluğunu uygulamadan söküp alarak, güvenliği standardize etmekte ve yetki işlemlerini koddan ayırarak merkezi bir şekilde kimlik yönetimi sağlamamıza imkan tanımaktadır.

Keycloak’un Temel Kavramları Nelerdir?

Şimdi de Keycloak’u kullanırken sürekli temasta bulunacağımız temel kavramları ele almaya çalışalım. Bu kavramlardan en temeli olarak nitelendirebileceğimiz Realm ile başlayalım…

• Realm
  Keycloak mantığında Realm, bir izole güvenlik alanıdır. Yani birbirini görmeyen, birbirinden etkilenmeyen ve birbirine karışmayan bir evren tanımlaması demektir. Peki bu ne işe yarıyor hoca? diye sorduğunuzu duyar gibiyim… Şöyle düşünmenizi istiyorum; bir realm içerisinde şunların tamamını barındırmaktadır;
  • Kullanıcılar
  • Şifreler
  • Roller
  • Gruplar
  • Client’lar
  • Token ayarları
  • Claim mapper’ları
  • Login ekranı teması
  • Şifre politikaları
  • MFA kuralları

  Dolayısıyla her bir realm içerisinde bunlar diğerlerinden bağımsız ve izole bir şekilde tutulacaktır ve aralarında kesinlikle bir paylaşım söz konusu olmayacaktır. Böylece tek bir Keycloak sunucusunda birden fazla realm ile tamamen farklı varlık sahaları oluşturulabilecektir.

  Haklı olarak akıllara Neden bu kadar sert bir izolasyon mantığı güdülmektedir? sorusu gelebilir. Bu sorunun cevabı olarak da gerçek hayatı örnek verebiliriz. Ne de olsa hayatta; bankalardan, devlet sistemlerinden, SaaS platformlarından ve Multi-tenant ihtiyaç gerektiren senaryolardan edinilen tecrübelere dayanarak ciddi izole edilmiş alan ihtiyacının olduğu yadsınamaz bir gerçektir. Dolayısıyla bu gerçeği Keycloak bizlere bünyesindeki realm kavramı ile hazır ve ön kabul görmüş bir şekilde sunmaktadır.

  Realm her ne kadar tenant kavramını çağrıştırıyor olsa da bu kavramlar aynı anlamı ifade etmemektedirler. Realm, izole edilmiş kimlik ve yetki evrenini temsil ederken; tenant ise izole edilmiş işi / müşteriyi / organizasyonu ifade etmektedir.

  Realm’i daha da net anlamlandırabilmek için şöyle bir metafor üzerinden örneklendirmede bulunabiliriz; bir sistemi aynı apartmandaki farklı daireler olarak değil de direkt farklı apartmanlar olarak tasarladığımızda realm mantığını uygulamış oluruz. Kapılar ayrı, anahtarlar ayrı, elektrik tesisatı ayrı… Haliyle herhangi bir apartmanda olabilecek yangın, sel, patlama vs. gibi tehlike durumları diğer apartmanlara sıçramayacak ve böylece ideal izolasyon davranışı sergilenmiş olacaktır.

  Aşağıda iki farklı şirketin Keycloak üzerinde nasıl temsil edilebileceğine dair basit bir realm mimarisi örneği sunulmaktadır;

  company-a	company-b
  Realm: company-a ├── users ├── clients ├── roles	Realm: company-b ├── users ├── clients ├── roles

  Buradan yola çıkarak şunu diyebiliriz ki; aynı kullanıcı iki realm’de de ayrı ayrı tanımlanacağından dolayı iki farklı kişi olarak nitelendirilecektir. Evet, Keycloak’un realm mantığından da zaten beklenen tam da böyle bir ortam sağlamasıdır…

• Role
  Roller, yetki etiketleridir. admin, user, cooperative-president vs. gibi metinsel olarak tanımlanabilen ve anlamsal açıdan belirli davranışları ya da eylemleri kullanıcıların ya da client’ların yapıp yapamayacağının sınırlarını belirleyen etkene sahiplerdir.

  Keycloak’ta roller; realm seviyesinde tanımlanan ve tüm realm genelinde kullanılabilen Realm Roles ile client seviyesinde tanımlanan ve sadece ilgili client tarafından kullanılabilen Client Roles olmak üzere ikiye ayrılmaktadır.

• Client
  Client ise Keyclouk’a bağlanan uygulamaların genel adıdır. Bu uygulama bir Angular veya React SPA olabilir, Asp.NET Core API olabilir, mobile app yahut herhangi bir backend service’de olabilir. Yani bir projedeki tüm servisler / uygulamalar Keycloak içerisinde client olarak ilgili realm’de tanımlanırlar.

  Keycloak’da client’ın görevi, uygulama için sistemden token talep etmek ve uygulamadan gelen istek süreçlerinde var olan token’ı doğrulatmaktır. Bunun yanında kullanıcıya dair yetkilendirme bilgilerini de client ile edinebilmektir.

  Evet, Keycloak’da token’ı her daim client istemektedir. Ancak kullanıcı adına mı, uygulamanın kendi adına mı yoksa her ikisi adına mı isteyeceği akışa (flow / grant type) bağlıdır.

  Client yapısal olarak içerisinde belli başlı uygulamayla ilgili rolleri (roles) ve uygulamaya dair kimi bilgileri (client scopes) barındırmaktadır.

  Client Roles
  Roller, üstteki satırlarda ifade edildiği gibi Keycloak açısından realm genelinde tanımlanabilen işlevsel yapılardır. Haliyle realm seviyesinde rol varken neden client’a özel rol tanımı sağlanmaktadır? sorusu haklı olarak akıllarda cereyan edebilir. Bu suale kısa ve net bir şekilde cevap vermemiz gerekirse eğer, bir yetkinin yalnızca belirli bir client bağlamında geçerli olmasını sağlamak için client’a özel rol tanımının sağlandığını söyleyebiliriz. Yani -bu kullanıcı, sadece bu client için şu yetkilere sahip olsun- şeklinde bir yetkilendirme yapmak istediğimizde bunu teknik olarak client seviyesindeki rol tanımlarıyla gerçekleştirmemiz mümkündür ve davranışsal olarak da bu en sağlıklı yöntemdir.

  Bir client rolü edinilmiş bir token içerisinde aşağıdaki gibi client bazlı görülecektir:

  "resource_access": {
    "order-api": {
      "roles": ["order.read"]
    },
    "payment-api": {
      "roles": ["payment.read"]
    }
  }
  

  Eğer ki mevzu bahis realm rolü olsaydı aşağıdaki gibi görülecekti:

  "realm_access": {
    "roles": ["admin"]
  }
  

  Peki rollerin hepsini realm seviyesinde tanımlasak olmaz mı?
  Evet, teknik olarak bu mümkündür ancak mimarisel olarak tam bir felakettir. Tüm rollerin realm seviyesinde tanımlanması, bir rolün hangi servise ait olduğunu muallakta bırakır. Bunun yanında onlarca rolden kaynaklı meydana gelecek karışıklık ister istemez olası güvenlik açıkları da meydana getirebilir. Düşünün;

  refund
  delete
  approve
  

  bunlar realm seviyesinde tanımlanmış roller olsaydı hangisi, hangi servis ve hangi bağlam için oluşturulmuştur? sorusuna nasıl cevap verilebilirdi… Verilemezdi 🙂 Üç tanesini bile zahiren ayırt etmek zorken, onlarca rolün söz konusu olacağı gerçek çalışmalarda bu yaklaşım hiç de doğru olmayacaktır.

  Ayrıca client credentials flow davranışını bilenler bilir… Bu davranışta kullanıcı yoktur. Sadece client doğrulama sağlar. Haliyle bu akışın kullanıldığı çalışmalarda client seviyesinde rol yapılanması oldukça fark yaratacaktır. Aksi taktirde bizler client credentials flow’un kullanıldığı service-to-service senaryolarında hangi uygulamanın hangi role sahip olduğunu anlamak için ciddi çırpınışlarda bulunuyor olacaktık.

  Client Scopes
  Client Scopes, bir client’ın hangi bilgileri (claim’leri) token içerisinde isteyerek edinebileceğini tanımlayan kapsam sözleşmesidir.

  Burada rol ile scope arasındaki farka temas etmekte fayda görmekteyim. Rol, bildiğiniz yetki veren değerlerdir. Scope ise yetki vermez, yalnızca tokena bilgi taşıyan / açan ifadelerdir. Dolayısıyla rol, -ne yapabilirim?- sorusuna cevap verirken, scope -hangi bilgiyi görebilirim?- sorusuna cevap vermektedir.

  Scope’un mantığını tam kavramak için aşağıdaki örnek token formatı üzerinden gidebiliriz:

  {
    "sub": "...",
    "email": "...",
    "roles": [...],
    "tenant_id": "...",
    "phone": "...",
    "salary": "..."
  }
  

  Şimdi düşünürseniz eğer her client’ın bu bilgilerin hepsini görmesine gerek olmadığı aşikar. İşte bu noktada scope devreye girer ve şu soruyu sorarak cevabını verir: -bu client token’da hangi bilgileri görebilir?-

  Dolayısıyla client scope; hangi claim’lerin token’a gireceğinin, hangi mapper’ların çalışacağının, hangi bilgilerin paylaşılacağının ve hangi client’ların bu bilgileri edinebileceğinin kontrolünü sağlar.

  Client scope, özel olarak oluşturulabildiği gibi sistem tarafından bizlere standart olarak sunulanlarda mevcuttur. Hemen standartları masaya yatırırsak eğer;

  Standart Scope	Hangi bilgiyi açar	Token’a claim ekler mi?
  openid	OIDC’yi aktive eder. OIDC Nedir? OIDC’yi tam anlamak için öncelikle OAuth’u anlamak gerekmektedir. OAuth, ‘bu uygulama, bu API’ye erişebilir mi?’ sorusuna cevap verebilir, ancak ‘kullanıcı kim?’, ‘adı ne?’, ‘login oldu mu?’, ‘bu token bir insana mı ait?’ sorularının cevabını veremez. Yani OAuth yalnızca bir authorization (yetkilendirme) protokolüdür. OIDC, OAuth 2.0 üzerine eklenmiş bir kimlik katmanıdır ve yukarıdaki soruların cevaplarını rahatlıkla verebilir. Haliyle openid scope’u bir OIDC isteği sağlamaktadır ve bu istek neticesinde kullanıcıyı temsil eden ve kimliğini tanımlayan ID Token üretimini sağlar. Ekstradan bilgi Access Token, bir isteğin resource server’a (yani API’lere) erişmeye yetkili olup olmadığını kanıtlarken; ID Token ise bir kullanıcının gerçekten login olduğunu ve kim olduğunu kanıtlar. Kısaca; openid scope’u, OAuth isteğini kimlik doğrulama isteğine çeviren bir anahtardır. OIDC ise OAuth’un tek başına çözemediği -kullanıcı kimdir?- problemini standart, güvenli ve doğrulanabilir şekilde çözen bir protokoldür.	❌
  profile	name, surname	✔
  email	email claim	✔
  address	adress	✔
  phone	phone_number	✔
  offline_access	refresh token	❌
  acr	Authentication Context Class Reference Kullanıcını nasıl login olduğunu ifade eder! Şifreyle mi? MFA ile mi? SMS OTP ile mi? vs. Token içinde: "acr": "urn:mfa" bilgisi sağlar. Bu sayede API’lere -ben sadece MFA ile login olmuş kullanıcıları kabul edebilirim- şeklinde bir şart koyma şansı tanır. Bu yöntem regülasyonlu sistemlerde (bankalar, e-devlet) olmazsa olmazdır.	✔

  Özel olarak oluşturulan scope’lardan bahsedebilmemiz için ise Mapper’ları ele almamız gerekecektir. Ee haliyle bu içeriğin sınırlarını haddinden fazla zorlamamak ve sonraki başlıklarda birebir incelemek üzere burada noktalıyorum.

  Evet… Keycloak’da ki client’ların tabi ki de daha farklı özellikleri ve bizler için bahse konu edilmeye değer daha fazla gerekli davranışları mevcuttur. Ama şimdilik konuya dair bu kadar detayın yeterli olduğunu düşünüyor ve geri kalan noktaları sonraki içeriklerimizde hususi olarak incelemeye bırakıyorum.

• User
  Keycloak’da ki kullanıcıları ifade etmektedir.
• Group
  Kullanıcıların toplu yönetimini sağlayan, rol ve attribute atanabilen yapılardır. Group’a atanan roller kullanıcı tarafından miras alınır ve claim olarak token’a eklenir.
• Claim
  Claim, token içerisindeki bilgidir. Mapper ile üretilmektedir.
• Mapper
  Keycloak’da ki en kritik ama en az anlaşılan özelliktir. Mapper, bir bilginin (claim) token’a nasıl gireceğinin kuralını belirlemektedir. Yani bir başka deyişle, bir bilginin token’ın hangi noktasına yerleştirileceğinin kararını mapper vermektedir.

  Bunu şöyle örneklendirelim; diyelim ki herhangi bir kullanıcı üzerinde aşağıdaki gibi bir attribute bilgisinin eklendiğini varsayalım:

  Attribute:
  tenant_id = 42
  

  Bu attribute eklendiğinde artık Keycloak veritabanında bu bilginin var olduğunu söyleyebiliriz, değil mi? Heh işte, bizler bu bilgiyi token’a eklemek istiyorsak tam da bu noktada mapper devreye girecektir. Çünkü Keycloak, bir attribute’un üretilecek token’a koyulup koyulmaması gerektiğini biri tarafından kendisine söylenmesini bekleyecektir. İşte bunun için bir mapper’a ihtiyaç olacaktır. Mapper tanımlandığı taktirde; hangi attribute’un, hangi claim’e karşılık gelecek şekilde access token içerisine ekleneceğini ifade edebilmekteyiz.

  Keycloak’ta, token’a giren tüm claim’ler mapper’lar aracılığıyla belirlenir; ancak bazı roller ve standart scope’lar Keycloak tarafından otomatik mapper’larla zaten tanımlı gelir.

• Scope
  Token’ın içeriğini belirleyen bilgilerdir.
• Attribute
  Kullanıcıya yahut gruba dair ham verileri temsil eder. Yetki değildir ve otomatik olarak token’a eklenmez. Yalnızca Keycloak’ın içinde duran bilgidir.
• Token Türleri
  • Access Token
    Resource server’lara erişim için kullanılır. Role & Claim bilgisi taşır.
  • ID Token
    Kullanıcı kimliğine dair bilgiler taşır. Genellikle frontend için kullanılır.
  • Refresh Token
    Yeni token almak içindir. Access token’a nazaran daha uzun ömürlüdür.

Master Realm Nedir?

Master Realm, Keycloak’ı gerçekten doğru kullananlarla, sadece çalıştıranları ayıran bir kavramdır.

Master Realm, Keycloak sunucusunun kendisini yönetebilmek için var olan, özel ve ayrıcalıklı yönetim (administration) realm’idir. Yani, kullanıcılar için değil, Keycloak için varlık göstermektedir.

Bizler master realm sayesinde kimlik altyapısını yönetenlerle, bu altyapıyı kullananları ayırmak isteriz. Dolayısıyla bu ikisini aynı realm’de tutmak olası güvenlik hataları ve karışıklıklara mahal verebileceğinden dolayı en baştan böyle bir kabulle yola çıkmak en doğrusudur diyebiliriz.

Master Realm Neyi Yönetir?

Master Realm, Keycloak’ın root yetkisine sahip realm’idir.

Bizler master realm ile yeni realm oluşturabilmekte, mevcut olan bir realm’i silebilmekte ve var olan realm ayarlarını değiştirebilmekteyiz. Bu yetenekler özellikle Multi-Tenant olarak kurguladığımız sistemlerde, yönetim panelinden yeni bir kooperatif ya da müşteri için istediğimiz yapılandırmalarda dinamik realm oluşturabilmemizi yahut aynı şekilde var olan bir müşterinin realm’ini ortadan kaldırarak tüm verileri programatik olarak yönetebilmemizi sağlamaktadır.

Peki diğer realm’ler ne yapar?
Master realm’in dışındaki realm’ler, kullanıcıları ve client’ları tutar, token üretir ve login akışlarını yönetir.

Peki master realm token üretebilir mi?
Evet, üretebilir. Ancak bu token resource server’lara erişim için üretilen token değildir. Sadece Keycloak yönetim işlemleri için programatik tasarlanan bir servis varsa eğer, onu master realm ile yetkilendirebilmek için üretilen token’dır. Bir başka deyişle master realm; diğer realm’lerin üstünde çalışan, token’ları diğer realm’ler de geçerli olan super realm değildir!

Master realm token’ı ile başka realm API’sine erişilemez!

Olayı bu mantıkla değerlendirdiğimizde frontend login durumlarında, uygulama kullanıcı işlemlerinde ve resource server’lara authentication süreçlerinde master realm kullanılmaması gerekmektedir.

Nihai olarak;
Bu içeriğimizde genel anlamda Keycloak’u tanımış ve teoride incelemiş bulunuyoruz. Bundan sonraki içeriklerimizde yavaş yavaş Keycloak ile ilgili hususi noktaları kritik edecek ve yavaş yavaş pratiksel dokunuşlarla Keycloak’u keşfetmeye devam ediyor olacağız.

İlgilenenlerin faydalanması dileğiyle…
Sonraki yazılarımda görüşmek üzere…
İyi çalışmalar…