Mapper T\u00fcr\u00fc<\/th>\n	A\u00e7\u0131klama<\/th>\n	\u00d6rnek<\/th>\n<\/tr>\n<\/thead>\n
User Attribute<\/td>\n	Keycloak’da bir kullan\u0131c\u0131n\u0131n sahip oldu\u011fu ek bilgileri (attribute’lar\u0131) al\u0131p token i\u00e7ine eklemeye yarayan bir mapper t\u00fcr\u00fcd\u00fcr. \u00d6rne\u011fin; kullan\u0131c\u0131 profilinde tan\u0131ml\u0131 olan `department = IT<\/code> gibi bir de\u011feri, bu mapper sayesinde token olu\u015fturma s\u00fcrecinde uygun bir claim olarak token’a yerle\u015ftirebilir ve nihai olarak \u00fcretilen token i\u00e7inde \u00f6rnekte verildi\u011fi \u015fekilde okunabilir bir de\u011fer \u00fcretilebilir. B\u00f6ylece API’lerden yahut frontend’den ekstra bir sorgu yapmaks\u0131z\u0131n bu bilgiye do\u011frudan token \u00fczerinden eri\u015filebilir.<\/td>\n`	\n {\r\n \"department\": \"IT\"\r\n}<\/pre>\n<\/td>\n<\/tr>\n
Role Mapper<\/td>\n	Keycloak’da kullan\u0131c\u0131n\u0131n sahip oldu\u011fu rolleri al\u0131p token i\u00e7erisine claim olarak ekleyen bir mapper t\u00fcr\u00fcd\u00fcr. Yani kullan\u0131c\u0131ya atanm\u0131\u015f olan ‘admin’ veya ‘user’ gibi roller, token olu\u015fturulurken otomatik olarak toplan\u0131r ve \u00f6rnekteki \u015fekilde token i\u00e7ine yerle\u015ftirilebilir. Bu vesileyle API veya uygulama taraf\u0131 yine ek bir sorguya ihtiya\u00e7 duymaks\u0131z\u0131n kullan\u0131c\u0131n\u0131n yetkilerini do\u011frudan token \u00fczerinden okuyabilir ve hatta bu de\u011ferlere g\u00f6re authorization i\u015flemlerini de ger\u00e7ekle\u015ftirebilir.<\/td>\n	\n {\r\n \"roles\": [\"admin\",\"user\"]\r\n}<\/pre>\n<\/td>\n<\/tr>\n
Hardcoded<\/td>\n	Hardcoded mapper, Keycloak’da herhangi bir veri kayna\u011f\u0131na ihtiya\u00e7 duymaks\u0131z\u0131n token i\u00e7erisine sabit (statik) bir de\u011fer eklenmesine yaramaktad\u0131r. Kullan\u0131c\u0131ya veya role ba\u011fl\u0131 olmaks\u0131z\u0131n \u00f6nceden belirlenen bir bilgiyi her token olu\u015fturuldu\u011funda otomatik olarak i\u00e7ine yerle\u015ftirir.<\/td>\n	\n {\r\n \"app\": \"mobile\"\r\n}<\/pre>\n<\/td>\n<\/tr>\n
Group Mapper<\/td>\n	Kullan\u0131c\u0131n\u0131n dahil oldu\u011fu gruplar\u0131 alarak bunlar\u0131 token i\u00e7erisine claim olarak ekleyen bir mapper t\u00fcr\u00fcd\u00fcr. Kullan\u0131c\u0131 hangi gruplara \u00fcyeyse bu bilgiler token olu\u015fturulurken toplan\u0131r ve \u00f6rnekteki \u015fekilde token i\u00e7erisine yerle\u015ftirilir. B\u00f6ylece uygulamalar kullan\u0131c\u0131n\u0131n grup bazl\u0131 yetkilerini do\u011frudan token \u00fczerinden edinebilme \u015fans\u0131 elde etmi\u015f olur.<\/td>\n	\n {\r\n \"groups\": [\"admin-group\"]\r\n}<\/pre>\n<\/td>\n<\/tr>\n
Script Mapper<\/td>\n	Script mapper, yukar\u0131daki standart mapper’lar\u0131n sundu\u011fu sabit ve do\u011frudan veri ta\u015f\u0131ma mant\u0131\u011f\u0131n\u0131n \u00f6tesine ge\u00e7erek JavaScript tabanl\u0131 \u00f6zel bir mant\u0131k \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131na imkan veren geli\u015fmi\u015f bir mapper t\u00fcr\u00fcd\u00fcr. Bu mapper ile kullan\u0131c\u0131ya ait rol, attribute veya di\u011fer bilgiler \u00fczerinde i\u015flem yap\u0131labilir, bunlar birle\u015ftirilebilir ya da belirli ko\u015fullara g\u00f6re yeni claim’ler \u00fcretilebilir. Misal olarak kullan\u0131c\u0131 rol\u00fc ‘admin’ ise token i\u00e7erisine `permission = full<\/code> gibi dinamik bir de\u011fer eklenerek daha esnek ve senaryoya \u00f6zel bir yap\u0131 kurulabilir.<\/td>\n`	\n {\r\n \"permission\": \"full\"\r\n}<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n <\/span>Token Mapper’lar\u0131n \u0130\u00e7 Yap\u0131s\u0131<\/span><\/h3>\n Mimarisel olarak her bir mapper, token’a claim eklemeyi sa\u011flayan birer plugin’dir.<\/em><\/p><\/blockquote>\n Bir mapper’\u0131n i\u00e7 yap\u0131s\u0131nda a\u015fa\u011f\u0131daki gibi d\u00f6rt ana husus s\u00f6z konusudur;<\/p>\n \n Yap\u0131land\u0131rma<\/strong>: Keycloak dashboard’da g\u00f6r\u00fclen alanlar yap\u0131land\u0131rma kapsam\u0131nda de\u011ferlendirilir. Bu a\u015famada kurgulanan yap\u0131land\u0131rma sayesinde runtime’da mapper’a nas\u0131l davranaca\u011f\u0131 s\u00f6ylenir.<\/li>\n Veri Kayna\u011f\u0131<\/strong>: Mapper’\u0131n beslendi\u011fi kaynaklard\u0131r. Mapper, -veriyi nereden alaca\u011f\u0131m?-<\/em> sorusuna buradan cevap bulacakt\u0131r.<\/li>\n D\u00f6n\u00fc\u015ft\u00fcrme (Mapping Logic)<\/strong>: Mapper’\u0131n kaynaktan elde etti\u011fi veriyi claim format\u0131na d\u00f6n\u00fc\u015ft\u00fcrmesidir.<\/li>\n Token’a Entekte Etme<\/strong>: Nihai olarak elde edilen veri token i\u00e7erisine yerle\u015ftirilir.<\/li>\n<\/ul>\n <\/span>Token Mapper’lar\u0131 Kullan\u0131rken Nelere Dikkat Edilmelidir?<\/span><\/h3>\n Token mapper’larda olay sadece ‘claim eklemek’ de\u011fildir! Esas\u0131nda performans, g\u00fcvenlik ve mimarisel dengeyi do\u011fru kurgulamak gerekmektedir! Keycloak’u kullanan \u00e7o\u011fu sistemin bu noktada hata yapt\u0131\u011f\u0131n\u0131 s\u00f6yleyebilirim. Haliyle bu a\u00e7\u0131dan olay\u0131 de\u011ferlendirdi\u011fimizde sahada en ideal olabilecek yakla\u015f\u0131m i\u00e7in dikkat edilmesi gereken noktalara temas etmekte fayda g\u00f6rmekteyim…<\/p>\n \n Token gereksiz yere \u015fi\u015firilmemelidir!<\/strong> \nToken mapper kullan\u0131rken en kritik noktalardan biri token’\u0131n gereksiz verilerle l\u00fczumsuz yere \u015fi\u015firilmemesine \u00f6zen g\u00f6sterilmesidir. \u00c7\u00fcnk\u00fc, JWT her istekte client ile server aras\u0131nda ta\u015f\u0131nacakt\u0131r. Ee bu durumda her fazladan verinin a\u011f trafi\u011fine maliyet olarak yans\u0131yaca\u011f\u0131 anlam\u0131na gelmektedir. Bu durum, \u00f6zellikle mobil veya d\u00fc\u015f\u00fck bant geni\u015fli\u011fine sahip ortamlarda ciddi performans problemlerine yol a\u00e7abilir. Bu y\u00fczden en do\u011fru yakla\u015f\u0131m, her istekte sadece ger\u00e7ekten ihtiya\u00e7 duyulan minimum bilginin token i\u00e7erisine konulmas\u0131d\u0131r.\n<\/li>\n Token’a hassas veriler koyulmamal\u0131d\u0131r!<\/strong> \nToken mapper kullan\u0131rken dikkat edilmesi gereken en \u00f6nemli konulardan biri de hassas verilerin token i\u00e7ine konulmamas\u0131na dikkat edilmesidir. Malumunuz, JWT yap\u0131sal olarak sadece base64 ile encode edilir ve asl\u0131nda \u015fifrelenmemektedir! Yani token’\u0131 ele ge\u00e7iren herkes \u00e7ok kolay bir \u015fekilde decode ederek i\u00e7eri\u011fini okuyabilir! Bu nedenle TCKN, gereksiz e-posta bilgileri yahut \u00f6zel kullan\u0131c\u0131 verileri gibi hassas bilgiler token i\u00e7ine eklenmemelidir.\n<\/li>\n Access Token ile ID Token ayr\u0131m\u0131 ger\u00e7ekle\u015ftirilmelidir!<\/strong> \nToken mapper kullan\u0131rken en s\u0131k yap\u0131lan olas\u0131 hatalardan biri de Access Token ile ID Token ayr\u0131m\u0131n\u0131n g\u00f6zetilmemesidir! Access Token, asl\u0131nda API’lerin kullanmas\u0131 ve yetkilendirme gibi backend tarafl\u0131 kontrollerin sa\u011flanmas\u0131 i\u00e7in tasarlanm\u0131\u015fken, ID Token ise genellikle frontend uygulamalar\u0131n\u0131n kullan\u0131c\u0131ya ait bilgilere eri\u015febilmesi i\u00e7in tasarlanm\u0131\u015ft\u0131r. Bu teorik ayr\u0131mdan yola \u00e7\u0131karak rol ve yetki gibi authorization s\u00fcrecini ilgilendiren veriler Access Token i\u00e7erisinde yer almal\u0131yken; kullan\u0131c\u0131 ad\u0131, anas\u0131n\u0131n k\u0131zl\u0131k soyad\u0131 vs. gibi frontend’in ilgilenece\u011fi veriler ise ID Token’da bulunmal\u0131d\u0131r.\n<\/li>\n Token’\u0131n de\u011fi\u015ftirilemez (immutable) oldu\u011fu unutulmamal\u0131d\u0131r!<\/strong> \nToken mapper kullan\u0131rken g\u00f6zden ka\u00e7\u0131r\u0131lmamas\u0131 gereken bir di\u011fer nokta ise token’\u0131n de\u011fi\u015ftirilemez (immutable) olmas\u0131d\u0131r. Yani kullan\u0131c\u0131ya ait bir rol veya yetki de\u011fi\u015fti\u011finde daha \u00f6nce \u00fcretilmi\u015f token’lar bu de\u011fi\u015fiklikten etkilenmeyecek ve eski bilgileri ta\u015f\u0131maya devam edecektir! Bu durum, zaman zaman sistemde istemsizce tutars\u0131zl\u0131klara yol a\u00e7abilecektir. \u0130\u015fte bundan kaynakl\u0131 bu durumu y\u00f6netebilmek ad\u0131na token s\u00fcrelerini k\u0131sa tutmal\u0131 ve m\u00fcmk\u00fcnse refresh token<\/a> mekanizmas\u0131yla s\u00fcre\u00e7 desteklenerek gerekti\u011fi taktirde kullan\u0131c\u0131y\u0131 sistemden d\u00fc\u015f\u00fcr\u00fcp (revoke\/logout) yeni token almas\u0131 sa\u011flanmal\u0131d\u0131r. Bu ve buna benzer stratejilerle s\u00fcre\u00e7 daha korunakl\u0131 ve g\u00fcvenilir hale getirilmelidir.\n<\/li>\n Script mapper’lar dikkatli kullan\u0131lmal\u0131d\u0131r!<\/strong> \nScript mapper’lar olduk\u00e7a g\u00fc\u00e7l\u00fc olmalar\u0131na ra\u011fmen beraberinde kritik riskler bar\u0131nd\u0131rmaktad\u0131rlar. Bu mapper’lar JavaScript tabanl\u0131 \u00f6zel logic \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131 i\u00e7in her token \u00fcretiminde ekstra i\u015flem y\u00fck\u00fc olu\u015fturabilir ve bu da \u00f6zellikle yo\u011fun sistemlerde performans d\u00fc\u015f\u00fc\u015f\u00fcne neden olabilir. Ayr\u0131ca bu t\u00fcr dinamik yap\u0131lar\u0131n debug edilmesi zor oldu\u011fu i\u00e7in bak\u0131m maliyetlerinin y\u00fcksek hale gelebilme olas\u0131l\u0131\u011f\u0131 s\u00f6z konusudur. Bu y\u00fczden, Script mapper’lar\u0131n yaln\u0131zca standart mapper’lar\u0131n yeterli olmad\u0131\u011f\u0131 ve ger\u00e7ekten \u00f6zel bir i\u015f kural\u0131na ihtiya\u00e7 duyuldu\u011fu durumlarda tercih edilmesine \u00f6zen g\u00f6sterilmelidir.\n<\/li>\n Claim isimlendirme standard\u0131na \u00f6zen g\u00f6sterilmelidir!<\/strong> \nGeli\u015fi g\u00fczel veya belirsiz isimler kullanmak zamanla sistemde ciddi bir karma\u015faya yol a\u00e7abilir. Bu her konuda ge\u00e7erli oldu\u011fu gibi claim’ler i\u00e7in de ge\u00e7erlidir. Neyi temsil etti\u011fi belli olmayan alanlar yerine a\u00e7\u0131k ve anlaml\u0131 isimler tercih edilmeli ve m\u00fcmk\u00fcn mertebe `camelCase<\/code> yahut snake_case<\/code> gibi isimlendirme standard\u0131 benimsenmelidir. Ve daha da \u00f6nemlisi OpenID Connect (OIDC) taraf\u0131ndan zaten tan\u0131mlanm\u0131\u015f standart claim isimleri mevcutsa bunlara sad\u0131k kal\u0131nmal\u0131d\u0131r.\n<\/li>\n` Yerine g\u00f6re client scope kullan\u0131lmal\u0131d\u0131r!<\/strong> \nToken mapper kullan\u0131m\u0131nda yap\u0131lan bir di\u011fer hata ise bir mapper’\u0131 birden fazla client i\u00e7in tekrar tekrar tan\u0131mlamakt\u0131r. Bu yakla\u015f\u0131m, k\u0131sa vadede \u00e7al\u0131\u015fsa da uzun vadede ciddi bir y\u00f6netim ve bak\u0131m karma\u015fas\u0131na yol a\u00e7acakt\u0131r. \u00c7\u00fcnk\u00fc, herhangi bir de\u011fi\u015fiklik gerekti\u011finde t\u00fcm client’larda tek tek g\u00fcncelleme yapmak gerekecektir. Bunun yerine Keycloak’ta`Client Scope<\/a> kullanarak mapper’lar\u0131 merkezi bir yap\u0131ya almak \u00e7ok daha do\u011fru bir yakla\u015f\u0131m olacakt\u0131r. B\u00f6ylece ilgili mapper’\u0131 bir kez tan\u0131mlayabilir ve ihtiya\u00e7 duyulan t\u00fcm client’lara bu scope’u ba\u011flayarak hem tekrar\u0131n \u00f6n\u00fcne ge\u00e7ilebilir hem de daha temiz, s\u00fcrd\u00fcr\u00fclebilir ve \u00f6l\u00e7eklenebilir bir yap\u0131 kurulabilir.\n<\/li>\n` Gereksiz mapper yazmaktan \u00e7ekinilmelidir!<\/strong> \nHer mapper, uygulaman\u0131n login ve authentication s\u00fcre\u00e7lerinde ekstra bir katman olarak devreye girecektir. Bu da her istekte ek i\u015flem, bellek kullan\u0131m\u0131 ve CPU maliyeti anlam\u0131na gelir. \u00d6zellikle birden fazla mapper kulland\u0131\u011f\u0131n\u0131zda bu etki katlanarak b\u00fcy\u00fcyebilir ve auth i\u015flemlerinde belirgin \u015fekilde yava\u015flama s\u00f6z konusu olabilir. Bu y\u00fczden prensip \u00e7ok nettir! M\u00fcmk\u00fcn oldu\u011funca az ve ger\u00e7ekten gerekliyse mapper yaz\u0131lmal\u0131d\u0131r…\n<\/li>\n Token boyutu test edilmelidir!<\/strong> \nJWT token boyutu, \u00e7o\u011fu geli\u015ftiricinin g\u00f6z ard\u0131 etti\u011fi ama performans a\u00e7\u0131s\u0131ndan olduk\u00e7a kritik bir konudur. Token ne kadar b\u00fcy\u00fckse, her HTTP iste\u011finin header’\u0131nda o kadar fazla veri ta\u015f\u0131nacak, bu da a\u011f trafi\u011fini \u015fi\u015firecek ve latency’yi art\u0131racakt\u0131r. Bundan kaynakl\u0131 token’\u0131n ka\u00e7 KB oldu\u011fu mutlaka test edilmeli ve header size’\u0131 \u00f6l\u00e7\u00fclmelidir. \u0130deal olarak token boyutunu m\u00fcmk\u00fcn mertebe 2-3 KB’\u0131n alt\u0131nda tutmakt\u0131r. Bu kontrol performans optimizasyonunun bir par\u00e7as\u0131d\u0131r.<\/u>\n<\/li>\n Microservice uyumu d\u00fc\u015f\u00fcn\u00fclmelidir!<\/strong> \nMapper’\u0131 tasarlarken en \u00f6nemli sorulardan biri -bu veri ger\u00e7ekten t\u00fcm microservice’lerde laz\u0131m m\u0131?-<\/em> sorusudur… E\u011fer cevap evet ise, yani veri bir\u00e7ok servisin ortak ihtiyac\u0131ysa, o taktirde token’a koymakta fayda olacakt\u0131r. Yok e\u011fer birka\u00e7 servise \u00f6zg\u00fc bir veri ise token’\u0131 \u015fi\u015firmek yerine o verinin o servislere \u00f6zel olarak ba\u015fka \u015fekillerde ta\u015f\u0131nmas\u0131 daha ak\u0131ll\u0131ca olacakt\u0131r. Bu hassasiyet, token boyutunu gereksiz yere b\u00fcy\u00fctmeksizin microservice mimarisindeki veri ak\u0131\u015f\u0131n\u0131 daha temiz ve verimli hale getirecektir.\n<\/li>\n Versiyonlama \u00f6nemsenmelidir!<\/strong> \nToken yap\u0131s\u0131 de\u011fi\u015fti\u011finde (yeni claim eklendi\u011finde, mevcut bir claim’in yap\u0131s\u0131 yahut ad\u0131 de\u011fi\u015fti\u011finde) eski versiyona tabii client’lar aniden patlayabilir ve kullan\u0131c\u0131lar giri\u015f yapamaz hale gelebilir. Bu riski \u00f6nlemenin ileri seviye \u00e7\u00f6z\u00fcm\u00fc, token’lara claim versiyonlamas\u0131 eklemek ve her daim backward compatibility’yi (geriye d\u00f6n\u00fck uyumluluk) g\u00f6zetmektir. B\u00f6ylece yeni token yap\u0131s\u0131na ge\u00e7ilse bile eski client’lar sorunsuz \u00e7al\u0131\u015fmaya devam edecektir. Versiyonlama sayesinde token yap\u0131s\u0131n\u0131 \u00f6zg\u00fcrce evriltebilir ve yeni \u00f6zellikler ekleyebilirken bir yandan da mevcut kullan\u0131c\u0131 deneyimini koruyabiliriz. Bu yakla\u015f\u0131m, uzun \u00f6m\u00fcrl\u00fc ve sa\u011flam bir authentication sistemi kurman\u0131n en kritik par\u00e7alar\u0131ndan birisidir.\n<\/li>\n<\/ul>\n<\/span>13 Kritik Soru \/ 13 Kritik Cevap<\/span><\/h3>\n\nSoru 1 \| Token Mapper olmasayd\u0131 ne yapard\u0131k?<\/span><\/summary>\nMapper, token i\u00e7ine veri koyarak stateless authentication sa\u011flar. Dolay\u0131s\u0131yla olmasayd\u0131, her request’te eri\u015fmemiz gereken verilere DB \/ UserInfo endpoint’lerini \u00e7a\u011f\u0131rarak eri\u015fmemiz gerecekti! B\u00f6ylece latency artacak, sistem yava\u015flayacak ve microservice’lerde de ba\u011f\u0131ml\u0131l\u0131k riski s\u00f6z konusu olabilecektir. Mapper’lar sayesinde laz\u0131m olan veriler her servisin direkt okuyaca\u011f\u0131 \u015fekilde ba\u015ftan token’a koyulmaktad\u0131r. Bu da bizlere performans ve olas\u0131 maliyetler a\u00e7\u0131s\u0131ndan b\u00fcy\u00fck avantajlar sa\u011flamaktad\u0131r. \n<\/details>\n\nSoru 2 \| Token’a neler koyulmamal\u0131d\u0131r?<\/span><\/summary>\n\u015eifreler, TCKN gibi hassas ki\u015fisel veriler koyulmamal\u0131d\u0131r. \u00c7\u00fcnk\u00fc, token decode edilerek hassas veriler ba\u015fkalar\u0131 taraf\u0131ndan rahatl\u0131kla elde edilebilmektedir.<\/p>\n Ayr\u0131ca listeler ve JSON blob’lar gibi b\u00fcy\u00fck veriler de koyulmamal\u0131d\u0131r! \u00c7\u00fcnk\u00fc, token boyutu performans\u0131 etkilemektedir. \n<\/details>\n\nSoru 3 \| Mapper’\u0131 access token’a m\u0131 yoksa ID token’a m\u0131 eklemeliyiz?<\/span><\/summary>\nE\u011fer API’de kullan\u0131lacaksa access token’a, yok e\u011fer UI’da kullan\u0131lacaksa ID token’a eklenmelidir. \n<\/details>\n\nSoru 4 \| Neden client scope diye bir \u015fey var?<\/span><\/summary>\nClient scope, mapper’lar\u0131 tek tek her client manuel olarak eklemek yerine, reusable bir paket olarak y\u00f6netilmesini sa\u011flayan ak\u0131ll\u0131 bir mekanizmad\u0131r. Misal olarak; 10 adet microservice’in s\u00f6z konusu oldu\u011fu bir senaryoda bir mapper’\u0131 hepsinde kullanmak gerekiyorsa her servise ayr\u0131 ayr\u0131 mapper eklemek hem zaman hem de bak\u0131m a\u00e7\u0131s\u0131ndan k\u00fclfettir. Bunun yerine bir client scope olu\u015fturup mapper’\u0131 bu scope’un i\u00e7ine koyar, ard\u0131ndan ilgili t\u00fcm client’lar bu scope’a ba\u011flan\u0131rsa, hem mapper tek bir yerden y\u00f6netilmi\u015f hem de t\u00fcm client’lara otomatik olarak uygulanm\u0131\u015f olacakt\u0131r. Bu sayede merkezi yap\u0131land\u0131rma e\u015fli\u011finde temiz ve d\u00fczenli bir y\u00f6netim sa\u011flanm\u0131\u015f olur. \n<\/details>\n \nSoru 5 \| Mapper runtime’da m\u0131 \u00e7al\u0131\u015f\u0131r yoksa login s\u0131ras\u0131nda m\u0131?<\/span><\/summary>\nSadece token olu\u015fturulurken yani login s\u0131ras\u0131nda \u00e7al\u0131\u015f\u0131r! Ayr\u0131ca refresh token kullan\u0131ld\u0131\u011f\u0131nda da \u00e7al\u0131\u015facakt\u0131r. \n<\/details>\n \nSoru 6 \| Token’daki veri g\u00fcncel de\u011filse ne olur?<\/span><\/summary>\nToken immutable’d\u0131r. Haliyle eski token’lar da eski veriler mevcuttur. \u00c7\u00f6z\u00fcm olarak k\u0131sa token \u00f6mr\u00fc verilmeli, m\u00fcmk\u00fcn mertebe refresh token ve revoke mekanizmas\u0131ndan istifade edilmelidir. \n<\/details>\n \nSoru 7 \| Mapper ile authorization yap\u0131l\u0131r m\u0131?<\/span><\/summary>\nMapper sadece token’a veri ta\u015f\u0131r. \n<\/details>\n \nSoru 8 \| Script Mapper ne zaman kullan\u0131l\u0131r?<\/span><\/summary>\n\nVeri transform edilecekse<\/li>\n Birden fazla attribute birle\u015fecekse<\/li>\n Conditional logic gerekiyorsa<\/li>\n<\/ul>\nBu durumlarda script mapper tercih edilebilir. Misal olarak; role + department \u2192 permission<\/code> \u00fcretimi gibi durumlar i\u00e7in akla gelmelidir.<\/p>\n Ama unutulmamal\u0131d\u0131r ki, performans maliyeti mevcuttur ve bak\u0131m s\u00fcreci ister istemez zorla\u015fmaktad\u0131r. \n<\/details>\n \nSoru 9 \| Mapper performans\u0131 etkiler mi?<\/span><\/summary>\nElbet etkileyecektir. \u00d6zellikle login s\u00fcrecinde mapper’lar\u0131n devreye girmesi hem s\u00fcreci uzataca\u011f\u0131 hem de token boyutunu b\u00fcy\u00fctece\u011fi i\u00e7in t\u00fcm bunlar network maliyetine yans\u0131yacakt\u0131r.<\/p>\n \u00d6zellikle script mapper ve external data mapper durumlar\u0131 haddinden fazla maliyetli olaca\u011f\u0131 i\u00e7in dikkat edilmelidir. \n<\/details>\n \nSoru 10 \| Mapper ile multi-tenant yap\u0131 kurulur mu? Ya da bir ba\u015fka deyi\u015fle tenant bilgisi mapper ile y\u00f6netilebilir mi?<\/span><\/summary>\nMapper’lar kullan\u0131larak multi-tenant<\/a> bir yap\u0131 kurmak olduk\u00e7a yayg\u0131n ve pratik bir yakla\u015f\u0131md\u0131r. Kullan\u0131c\u0131ya ait tenant bilgisi token i\u00e7ine bir claim olarak eklenerek her istekte bu bilginin ta\u015f\u0131nmas\u0131 sa\u011flan\u0131r ve b\u00f6ylece backend taraf\u0131nda gelen request’lerdeki tenant bilgisi ile token’daki tenant kar\u015f\u0131la\u015ft\u0131r\u0131larak yetki kontrol\u00fc ilgili tenant kapsam\u0131nda ger\u00e7ekle\u015ftirilip i\u015flemler y\u00fcr\u00fct\u00fcl\u00fcr. \n<\/details>\n \nSoru 11 \| Mapper ile dynamic permission yap\u0131l\u0131r m\u0131?<\/span><\/summary>\nHay\u0131r… Mapper, permission’\u0131 token’a koyar ama runtime’da de\u011fi\u015ftiremez! Yani bu ihtiya\u00e7 i\u00e7in token mapper’lar yetersiz kalmaktad\u0131r. Dinamik yetkilendirme senaryolar\u0131n\u0131 \u00e7\u00f6zebilmek i\u00e7in policy engine veya DB lookup gibi \u00e7\u00f6z\u00fcmlere gidilmesi \u00f6nerilmektedir.<\/p>\n Policy Engine<\/strong><\/em>, yetki kararlar\u0131n\u0131 sabit token i\u00e7inden okumak yerine, d\u0131\u015far\u0131da \u00e7al\u0131\u015fan bir karar motoruna<\/u> soran bir yap\u0131lanmad\u0131r. \u00d6rne\u011fin; Open Policy Agent (OPA)<\/em>, -bu kullan\u0131c\u0131 \u015fu kayna\u011fa eri\u015febilir mi?-<\/em> sorusunu runtime’da kurallara g\u00f6re de\u011ferlendirerek dinamik bir \u015fekilde y\u00f6nlendirmede bulunabilir. B\u00f6ylece roller veya claim’ler statik de\u011fildir, bilakis anl\u0131k kurallar ve ba\u011flama g\u00f6re \u015fekillenecektir.<\/p>\n DB lookup<\/strong><\/em> ise daha basit olsa da yine de dinamik bir davran\u0131\u015f sergileyen yakla\u015f\u0131md\u0131r. Burada uygulama, gelen request’teki kullan\u0131c\u0131 bilgisine bak\u0131p veritaban\u0131na gider ve g\u00fcncel yetkileri, tenant bilgisini veya izinleri o anda \u00e7eker. ani token’daki bilgiye k\u00f6r\u00fc k\u00f6r\u00fcne g\u00fcvenmek yerine -en g\u00fcncel veri ne?-<\/em> diyerek her istekte kontrol sa\u011flar. \n<\/details>\n\nSoru 12 \| Mapper ile UserInfo endpoint fark\u0131 nedir?<\/span><\/summary>\nMapper ile UserInfo ayn\u0131 amaca hizmet eden iki farkl\u0131 yakla\u015f\u0131md\u0131r.<\/p>\n Mapper, Keycloak i\u00e7inde tan\u0131mlanan bir \u00f6zelliktir, yani config’tir. Login an\u0131nda \u00e7al\u0131\u015f\u0131r ve kullan\u0131c\u0131 bilgilerini token’\u0131n i\u00e7ine g\u00f6mmemizi sa\u011flar. Sonras\u0131nda ise uygulama bu bilgileri ba\u015fka hi\u00e7bir yere gitmeye gerek kalmaks\u0131z\u0131n direkt token i\u00e7erisinden okuyabilir. Yani stateless’dir.<\/p>\n UserInfo ise endpoint’tir. Token’\u0131 al\u0131p Keycloak’a tekrar istek atarak kullan\u0131c\u0131ya dair bilgiler edinilmesini sa\u011flar. Keycloak, bu istek neticesinde o anki bilgiyi d\u00f6ner. Dolay\u0131s\u0131yla her seferinde bir d\u0131\u015f \u00e7a\u011fr\u0131 gerektirir. Bundan kaynakl\u0131 stateful’dur.<\/p>\nStateless, sistemin \u00e7al\u0131\u015fmak i\u00e7in ekstra bir yere (DB, servis vs.) gidip bilgi talep etmesine gerek olmamas\u0131, yani t\u00fcm gerekli bilginin token’da bulunmas\u0131d\u0131r.<\/p>\n Stateful ise, sistmein karar verebilmesi i\u00e7in her istekte d\u0131\u015f bir kayna\u011fa gidip g\u00fcncel durumu kontrol etmesi demektir.<\/em><\/p><\/blockquote>\n Mapper \u2192 Bilgiyi ba\u015ftan cebime koyar\u0131m… \nUserInfo \u2192 Bilgi gerektik\u00e7e gidip sorar\u0131m… \n<\/details>\n\nSoru 13 \| Mapper ile security a\u00e7\u0131\u011f\u0131 olu\u015fur mu?<\/span><\/summary>\nEvet! token’\u0131n public olmas\u0131ndan dolay\u0131 hassas verilerin s\u0131zd\u0131r\u0131lmas\u0131 olas\u0131d\u0131r. Dikkat edilmelidir! \n<\/details>\n<\/span>Token Mapper’lar\u0131n Kullan\u0131m\u0131<\/span><\/h3>\n\u015eimdi s\u0131ra token mapper’lar\u0131 deneyimlemeye geldi.<\/p>\n\u0130lk olarak Keycloak’da bir kullan\u0131c\u0131n\u0131n edindi\u011fi token’\u0131n en sade haliyle nas\u0131l bir i\u00e7eri\u011fe sahip oldu\u011funu inceleyelim… \n<\/a>Evet… G\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere bir kullan\u0131c\u0131da varsay\u0131lan olarak a\u015fa\u011f\u0131 yukar\u0131 yandaki g\u00f6rseldeki gibi i\u00e7eri\u011fe sahip bir token yap\u0131s\u0131 gelmektedir.<\/p>\n Tabi ki de kullan\u0131c\u0131ya rol yahut yetki verdik\u00e7e buradaki payload \u015fekillenecektir. \u00c7\u00fcnk\u00fc bu claim’ler zaten bu kaynaklardan beslenmektedir. Ancak ana claim’lerin yan\u0131na ekstradan bir kullan\u0131c\u0131 bilgisi eklemek isterseniz burada attribute olu\u015fturup mapper’lar ile eklemeniz en do\u011fru yakla\u015f\u0131m olacakt\u0131r. Bu yakla\u015f\u0131m, yukar\u0131daki sat\u0131rlarda Mapper T\u00fcrleri Nelerdir?<\/a> ba\u015fl\u0131\u011f\u0131 alt\u0131nda de\u011ferlendirdi\u011fimiz User Attribute Mapper<\/strong> t\u00fcr\u00fcne kar\u015f\u0131l\u0131k gelmektedir.<\/p>\n Diyelim ki, kullan\u0131c\u0131lar\u0131n department<\/code> bilgisini token’a claim olarak eklemek istiyoruz. Tabi bunun i\u00e7in \u00f6ncelikle ilgili isimde bir attribute eklenmesi gerekecektir.<\/p>\n Bu da Realm settings<\/code> \u00fczerinden User profile<\/code> sekmesine gelerek ger\u00e7ekle\u015ftirilebilir.<\/a>\u015eimdi normal \u015fartlarda, bu attribute’u ekledikten sonra a\u015fa\u011f\u0131daki gibi kullan\u0131c\u0131 detaylar\u0131ndan doldurulup kaydedildi\u011finde token’a gelmesini bekleyebilirsiniz.<\/a>Ancak nafile… Bu attribute taraf\u0131m\u0131zca olu\u015fturuldu\u011fu ve sistem taraf\u0131ndan bilinmedi\u011fi i\u00e7in bizim taraf\u0131m\u0131zdan token’a eklenmesi gerekecektir. Bunun i\u00e7in mapper olu\u015fturulmas\u0131 gerekmektedir.<\/p>\n <\/span>Token Mapper Olu\u015fturma<\/span><\/h4>\n<\/a>Token mapper olu\u015fturman\u0131n en temiz ve do\u011fru yolu scope olarak olu\u015fturmakt\u0131r. Bunun i\u00e7in Client Scopes<\/code> men\u00fcs\u00fcne gelerek bir scope olu\u015fturulmal\u0131d\u0131r.<\/p>\n \u015eimdi bu scope’a olu\u015fturaca\u011f\u0131m\u0131z mapper ile hem istedi\u011fimiz attribute’u token’a ekleyebilece\u011fiz hem de istedi\u011fimiz client’ta bu scope’u \u00e7a\u011f\u0131rarak, o client’tan olacak login s\u00fcre\u00e7lerinde mapper’dan istifade edebiliyor olaca\u011f\u0131z. B\u00f6ylece bir mapper’\u0131 scope \u00fczerinden tek seferde tan\u0131mlay\u0131p, farkl\u0131 client’larda kullanabilecek ve tekrar tekrar tan\u0131mlama zahmetinden kurtulmu\u015f olaca\u011f\u0131z.<\/p>\n Devam etmeden \u00f6nce ak\u0131llara gelebilecek olan ideal olan her mapper i\u00e7in ayr\u0131 bir scope olu\u015fturmak m\u0131?<\/strong><\/em> sorusunu cevapland\u0131ral\u0131m istiyorum… El-cevap: Hay\u0131r. Her mapper i\u00e7in ayr\u0131 bir scope olu\u015fturmak do\u011fru bir kabul olmayacakt\u0131r. \u00c7\u00fcnk\u00fc, scope dedi\u011fimiz \u015fey esas\u0131nda mant\u0131ksal bir paket gibi d\u00fc\u015f\u00fcn\u00fclebilir. Yani claim’leri tek tek ayr\u0131 scope’lara da\u011f\u0131tmak yerine, birbiriyle ili\u015fkili olanlar\u0131 ayn\u0131 scope i\u00e7ine toplamak en do\u011frusu olacakt\u0131r. Misal olarak; profile-data<\/code> diye bir scope a\u00e7\u0131p i\u00e7ine name<\/em>, surname<\/em>, department<\/em> vs. gibi mapper’lar\u0131 koymak ya da authorization-data<\/code> diye bir scope i\u00e7erisine de roles<\/em>, groups<\/em> vs. gibi claim’leri depolamak en mant\u0131kl\u0131s\u0131d\u0131r. Olaya mant\u0131ksal olarak bakarsak e\u011fer; mapper’lar, tekil kuralken, scope’lar ise bu kurallar\u0131n mant\u0131kl\u0131 grupland\u0131\u011f\u0131 paketler olarak d\u00fc\u015f\u00fcn\u00fclebilir. O y\u00fczden her mapper’a ayr\u0131 bir scope de\u011fil, anlaml\u0131 gruplara g\u00f6re scope olu\u015fturmak en sa\u011fl\u0131kl\u0131 kabul olacakt\u0131r.<\/p>\n Velhas\u0131l…<\/p>\n \u0130lgili scope’a t\u0131klay\u0131p Mappers sekmesine geldi\u011fimizde bizleri a\u015fa\u011f\u0131daki gibi iki se\u00e7enek kar\u015f\u0131layacakt\u0131r:<\/a><\/p>\n\n\n\nAdd predefined mapper<\/div>\nHaz\u0131r mapper\u2019lar\u0131 tek t\u0131kla eklemesini sa\u011flar, ekstra config gerektirmez.<\/div>\nemail, preferred_username, roles<\/code><\/div>\n<\/td>\n \nConfigure a new mapper<\/div>\nCustom mapper olu\u015fturulmas\u0131n\u0131 sa\u011flar, claim tamamen taraf\u0131m\u0131zca tan\u0131mlan\u0131r.<\/div>\ndepartment \u2192 \"IT\"<\/code><\/div>\n<\/td>\n<\/tr>\n<\/table>\nBizler senaryomuza uygun olarak Configure a new mapper<\/strong><\/em> se\u00e7ene\u011finden devam edece\u011fiz.<\/p>\n <\/span>User Attribute Mapper Olu\u015fturma<\/span><\/h5>\n\u0130lgili se\u00e7ene\u011fe t\u0131klad\u0131\u011f\u0131m\u0131zda a\u00e7\u0131lan pencereden a\u015fa\u011f\u0131daki gibi User Attribute<\/strong> t\u00fcr\u00fc se\u00e7ilmeli,<\/a><\/a>ve ard\u0131ndan yandaki gibi ilgili mapper yap\u0131land\u0131r\u0131lmal\u0131d\u0131r.<\/p>\n Buradaki yap\u0131land\u0131rmalara de\u011finmemiz gerekirse e\u011fer;<\/p>\n \nMapper type<\/strong>: Mapper’\u0131n t\u00fcr\u00fcn\u00fc ifade etmektedir.<\/li>\n Name<\/strong>: Teknik olarak hi\u00e7bir \u015feye etki etmiyor olsa da mapper’\u0131n Keycloak i\u00e7indeki ismine kar\u015f\u0131l\u0131k gelmektedir.<\/li>\n User Attribute<\/strong>: User’\u0131n hangi attribute’una kar\u015f\u0131l\u0131k bu mapper’\u0131n olu\u015fturuldu\u011fu belirlenmektedir.<\/li>\n Token Claim Name<\/strong>: Token’da hangi claim’e kar\u015f\u0131l\u0131k bu de\u011ferin eklenece\u011fi belirlenmektedir.<\/li>\n Claim JSON Type<\/strong>: Verinin tipi belirlenmektedir.<\/li>\n Add to ID token<\/strong>: Claim’in ID token’a eklenip eklenmeyece\u011fini yap\u0131land\u0131rmaktad\u0131r.<\/li>\n Add to access token<\/strong>: Benzer mant\u0131kla claim’in access token’a eklenip eklenmeyece\u011fini yap\u0131land\u0131rmaktad\u0131r.<\/li>\n Add to lightweight access token<\/strong>: Standart kullan\u0131m\u0131n d\u0131\u015f\u0131nda kalan bir optimizasyondur. Keycloak, token’\u0131 k\u00fc\u00e7\u00fcltmek ve daha h\u0131zl\u0131 ta\u015f\u0131yabilmek i\u00e7in kimi zaman hafif (lightweight) access token \u00fcretimi ger\u00e7ekle\u015ftirebilmektedir. \u0130\u015fte bu ayar, bu durumlarda ilgili claim’in eklenip eklenmeyece\u011fini yap\u0131land\u0131rmaktad\u0131r.<\/li>\n Add to userinfo<\/strong>: UserInfo endpoint’i \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda bu verinin d\u00f6n\u00fcp d\u00f6nmeyece\u011fi belirlenmektedir.<\/li>\n Add to token introspection<\/strong>: Token introspection endpoint’inde bu claim’in g\u00f6r\u00fcn\u00fcp g\u00f6r\u00fcnmeyece\u011fi yap\u0131land\u0131r\u0131lmaktad\u0131r.<\/li>\nMultivalued<\/strong>: \u0130lgili claim’in de\u011ferinin \u00e7oklu olup olmayaca\u011f\u0131n\u0131 yap\u0131land\u0131rmaktad\u0131r. E\u011fer \u00e7oklu olursa de\u011feri bir array i\u00e7erisinde getirecektir.\n\nOff<\/em>\n\"department\": \"IT\"<\/pre>\n<\/li>\nOn<\/em>\n\"department\": [\"IT\", \"HR\"]<\/pre>\n<\/li>\n<\/ul>\n<\/li>\nAggregate attribute values<\/strong>: E\u011fer kullan\u0131c\u0131da ayn\u0131 attribute’tan birden fazla mevcutsa hepsini birle\u015ftirip birle\u015ftirmeyece\u011fini yap\u0131land\u0131rmaktad\u0131r. Kapal\u0131 kald\u0131\u011f\u0131 taktirde ilk de\u011feri alacakt\u0131r.<\/li>\n<\/ul>\nEvet, bu yap\u0131land\u0131rma ayarlar\u0131nda bir mapper’\u0131 olu\u015fturduktan sonra ilgili client \u00fczerinden elde edilen token’\u0131n payload’una g\u00f6z atarsak a\u015fa\u011f\u0131daki gibi department<\/code> de\u011ferinin geldi\u011fini g\u00f6zlemlemi\u015f olaca\u011f\u0131z…<\/a><\/p>\n <\/span>Hardcoded Mapper Olu\u015fturma<\/span><\/h5>\nPeki… \u00d6rne\u011fimizi geni\u015fletmek ad\u0131na bir de sabit de\u011ferlerin token’a nas\u0131l eklendi\u011fini inceleyelim. Tabi bunun i\u00e7in de Hardcoded Mapper<\/strong> olu\u015fturmam\u0131z gerekecektir.<\/p>\n Bu sabit de\u011fer i\u00e7in uygun bir scope olu\u015fturabiliriz. Mesela; info<\/code> ad\u0131nda bir scope’umuz olsun.<\/p>\nBu scope’a Configure a new mapper<\/em><\/strong> se\u00e7ene\u011fi \u00fczerinden Hardcoded claim<\/strong>‘i se\u00e7erek sabit bir de\u011fer ekleyebiliriz. <\/a>Evet, g\u00f6rselde eksik kalan yap\u0131land\u0131rmalar\u0131 \u00f6nceki sat\u0131rdakilerle ayn\u0131 olaca\u011f\u0131 i\u00e7in es ge\u00e7mi\u015f bulunuyorum. Bu \u015fekilde bir mapper’\u0131 olu\u015fturup, info<\/code> scope’unu da ilgili client’a ekleyerek bir token talep edersek, bu token i\u00e7erisinde a\u015fa\u011f\u0131daki g\u00f6rselde oldu\u011fu gibi sabit de\u011ferin de geldi\u011fini g\u00f6rm\u00fc\u015f olaca\u011f\u0131z.<\/a><\/p>\n \u0130\u015fte bu kadar…<\/p>\n Geri kalan mapper t\u00fcrlerini tecr\u00fcbe etmeyi sizlere b\u0131rak\u0131yorum \ud83d\ude09<\/p>\n Nihai olarak;<\/p>\n Token’a koyulan her veri, esas\u0131nda sisteme at\u0131lan bir imzad\u0131r… Ya performans\u0131 h\u0131zland\u0131r\u0131r ya da fark etmeden sistemi yava\u015flat\u0131r… Ya g\u00fcveli\u011fi g\u00fc\u00e7lendirir ya da zafiyet olu\u015fturabilir… Token Mapper’lar bu y\u00fczden basit bir \u00f6zellik de\u011fildir, bilakis do\u011fru kullan\u0131ld\u0131\u011f\u0131nda ihtiya\u00e7 gideren ancak yanl\u0131\u015f kullan\u0131ld\u0131\u011f\u0131nda aya\u011fa dola\u015f\u0131p t\u00f6kezleten stratejik bir yap\u0131lanmad\u0131r. Bu y\u00fczden mesele hi\u00e7bir zaman -token’a ne koyabilirim?-<\/em> sorusu de\u011fildir! -ger\u00e7ekten neyi koymal\u0131y\u0131m?-<\/em> sorusudur… Bu soruya verilen cevap, kurulan sistemin kalitesiyle do\u011fru orant\u0131l\u0131d\u0131r.<\/p>\n \u0130lgilenenlerin faydalanmas\u0131 dile\u011fiyle… \nSonraki yaz\u0131lar\u0131mda g\u00f6r\u00fc\u015fmek \u00fczere… \n\u0130yi \u00e7al\u0131\u015fmalar…<\/p>\n","protected":false},"excerpt":{"rendered":" Merhaba, Bu i\u00e7eri\u011fimizde, Keycloak’da \u00fcretilen token’lar\u0131n i\u00e7ine ek veri eklenmesini sa\u011flayan Token Mapper mekanizmas\u0131n\u0131 mercek alt\u0131na al\u0131yor olacak ve nedir, ne i\u015fe yarar ve hangi senaryolarda kullan\u0131l\u0131r? gibi sorulara cevap ararken, konuyu sadece teoride...<\/p>\n","protected":false},"author":1,"featured_media":28235,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5206,5554],"tags":[5690,1136,5689,5686,5555,5692,5693,5588,5688,5691,5685,5687],"class_list":["post-28550","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-net","category-keycloak","tag-group-mapper","tag-hardcoded","tag-hardcoded-mapper","tag-introspection","tag-keycloak","tag-opa","tag-open-policy-agent","tag-policy-engine","tag-role-mapper","tag-script-mapper","tag-token-mapper","tag-user-attribute"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28550","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/comments?post=28550"}],"version-history":[{"count":15,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28550\/revisions"}],"predecessor-version":[{"id":28580,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28550\/revisions\/28580"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media\/28235"}],"wp:attachment":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media?parent=28550"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/categories?post=28550"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/tags?post=28550"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}

<\/div>\n

Merhaba,
\n
\nBu i\u00e7eri\u011fimizde, Keycloak’da \u00fcretilen token’lar\u0131n i\u00e7ine ek veri eklenmesini sa\u011flayan Token Mapper<\/strong> mekanizmas\u0131n\u0131 mercek alt\u0131na al\u0131yor olacak ve nedir<\/em>, ne i\u015fe yarar<\/em> ve hangi senaryolarda kullan\u0131l\u0131r?<\/em> gibi sorulara cevap ararken, konuyu sadece teoride b\u0131rakmay\u0131p pratik \u00f6rneklerle de peki\u015ftirerek ad\u0131m ad\u0131m inceliyor olaca\u011f\u0131z. Evet, haz\u0131rsan\u0131z ba\u015flayabiliriz…<\/p>\n

\n
\n
Ba\u015fl\u0131klar<\/p>\nToggle<\/span>
Token Mapper Nedir?<\/a><\/li>
Ne Amaca Hizmet Etmektedir?<\/a><\/li>
Mapper’lar Nerelerde Kullan\u0131l\u0131r?<\/a><\/li>
Mapper’lar Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/a><\/li>
Mapper T\u00fcrleri Nelerdir?<\/a><\/li>
Token Mapper’lar\u0131n \u0130\u00e7 Yap\u0131s\u0131<\/a><\/li>
Token Mapper’lar\u0131 Kullan\u0131rken Nelere Dikkat Edilmelidir?<\/a><\/li>
13 Kritik Soru \/ 13 Kritik Cevap<\/a><\/li>
Token Mapper’lar\u0131n Kullan\u0131m\u0131<\/a>
Token Mapper Olu\u015fturma<\/a>
User Attribute Mapper Olu\u015fturma<\/a><\/li>
Hardcoded Mapper Olu\u015fturma<\/a><\/li><\/ul><\/li><\/ul><\/li><\/ul><\/nav><\/div>\n
<\/span>Token Mapper Nedir?<\/span><\/h3>\n
Token Mapper, Keycloak’un token issuance (token \u00fcretme) s\u00fcrecinde kullan\u0131c\u0131 bilgilerini, rollerini, grup bilgilerini, session notlar\u0131n\u0131 vs. access token, ID token ve UserInfo endpoint gibi OIDC token’lar\u0131na eklememizi sa\u011flayan olduk\u00e7a kullan\u0131\u015fl\u0131 ve kritik bir mekanizmad\u0131r.<\/p>\n
Token Mapper’lar ile kullan\u0131c\u0131dan gelen veri token’daki bir claim haline getirilmekte, yani “Token’\u0131n i\u00e7ine ne koyay\u0131m?”<\/em> sorusunun cevab\u0131 verilmektedir…<\/p>\n
<\/span>Ne Amaca Hizmet Etmektedir?<\/span><\/h3>\n
Token Mapper, Keycloak’ta olu\u015fturulan token’lar\u0131n i\u00e7ine varsay\u0131lan olarak gelen kullan\u0131c\u0131 id, username ve s\u00fcre gibi temel bilgilerin \u00f6tesine ge\u00e7erek, ger\u00e7ek hayatta ihtiya\u00e7 duyulan rol, yetki, departman, \u00f6zel alanlar veya d\u0131\u015f sistemlerden gelen verileri eklemeye yaramaktad\u0131r. Yani sistemdeki farkl\u0131 veri kaynaklar\u0131ndan belirli bilgileri al\u0131p bunlar\u0131 token i\u00e7inde anlaml\u0131 claim’ler olarak yerle\u015ftirir ve b\u00f6ylece API’lerin veya uygulamalar\u0131n ekstra bir sorguya ihtiya\u00e7 duymadan bu bilgilere do\u011frudan token \u00fczerinden eri\u015fmesini sa\u011flar.<\/p>\n
\n Introspection nedir?<\/em><\/strong>
\nBir token’\u0131n ge\u00e7erli olup olmad\u0131\u011f\u0131n\u0131 ve i\u00e7eri\u011fini auth server’a sorarak \u00f6\u011frenme y\u00f6ntemidir.<\/p>\n
JWT h\u0131zl\u0131d\u0131r ama eski veriye sahip olabilir. Ancak introspection yava\u015f olsa da her zaman do\u011fru veriyi getirecektir.<\/p>\n
Bunu \u015f\u00f6yle \u00f6rneklendirebiliriz;<\/p>\n
Token bir kere, de\u011fi\u015ftirilemez \u015fekilde olu\u015fturulur. Misal olarak ‘admin’ rol\u00fcne sahip bir kullan\u0131c\u0131ya token \u00fcretildi\u011finde bu token’a role: admin<\/code> claim’i eklenecektir. Kullan\u0131c\u0131dan bu rol al\u0131nsa dahi ilgili token \u00f6mr\u00fcn\u00fcn sonuna kadar o yetkiye sahip olacakt\u0131r. Ancak introspection’da ise her istekte gidip en g\u00fcncel durum elde edilecek ve kullan\u0131c\u0131 ‘admin’ de\u011filse bu o anda fark edilecektir!\n<\/div>\n
Token Mapper, token i\u00e7eri\u011finin uygulaman\u0131n ihtiya\u00e7lar\u0131na g\u00f6re esnek bi\u00e7imde \u015fekillendirilmesini sa\u011flayarak sadece gerekli verilerin eklenmesini ve gereksiz ya da hassas bilgilerin d\u0131\u015far\u0131da b\u0131rak\u0131lmas\u0131n\u0131 m\u00fcmk\u00fcn k\u0131lmaktad\u0131r. Bu sayede hem g\u00fcvenlik hem de token boyutu optimize edilirken; sub<\/em>, name<\/em>, email<\/em>, roles<\/em> gibi standart claim’ler dahil edilebilir ya da tamamen ihtiyaca \u00f6zel custom claim’ler \u00fcretilebilir. Ayr\u0131ca farkl\u0131 client’lar i\u00e7in farkl\u0131 claim set’leri tan\u0131mlanarak her uygulaman\u0131n yaln\u0131zca kendi ihtiya\u00e7 duydu\u011fu veriyi almas\u0131 da sa\u011flanabilir. Bunun yan\u0131nda kullan\u0131c\u0131ya g\u00f6sterilecek bilgilerin consent ekranlar\u0131nda kontrol edilmesine imkan tan\u0131r ve lightweight access token, token exchange veya introspection gibi ileri seviye kimlik do\u011frulama ve yetkilendirme senaryolar\u0131yla da uyumlu \u00e7al\u0131\u015farak sistemin hem esnek hem de \u00f6l\u00e7eklenebilir olmas\u0131na katk\u0131 sa\u011flayabilir.<\/p>\n
<\/span>Mapper’lar Nerelerde Kullan\u0131l\u0131r?<\/span><\/h3>\n
\n
Authorization (Yetkilendirme) S\u00fcre\u00e7lerinde<\/em><\/strong>
\nAuthorization senaryolar\u0131nda token mapper kullan\u0131m\u0131, kullan\u0131c\u0131 sisteme giri\u015f yapt\u0131\u011f\u0131 taktirde sahip oldu\u011fu rol ve izinlerin (\u00f6rne\u011fin admin<\/code> rol\u00fc ya da read<\/code>, write<\/code> gibi yetkiler) token i\u00e7ine eklenmesi ve API’nin her istekte bu bilgileri okuyarak karar vermesi mant\u0131\u011f\u0131na dayanmaktad\u0131r. Yani API ekstra bir veritaban\u0131 sorgusu yapmaks\u0131z\u0131n, sadece token i\u00e7indeki role<\/code> veya permissions<\/code> gibi claim’lere bakarak kullan\u0131c\u0131n\u0131n belirli bir i\u015flemi yapmaya yetkisi olup olmad\u0131\u011f\u0131n\u0131 h\u0131zl\u0131 ve do\u011frudan kontrol edebilir.\n<\/li>\n
Microservice Mimarisinde<\/em><\/strong> \nMicroservice mimarisinde her servisin kullan\u0131c\u0131 bilgisi i\u00e7in ayr\u0131 ayr\u0131 veritaban\u0131na gitmesini engellemek amac\u0131yla kullan\u0131c\u0131 ad\u0131, rol\u00fc veyahut farkl\u0131 \u00f6zellikleri gibi gerek duyulan kullan\u0131c\u0131 verileri token i\u00e7erisine token mapper’lar arac\u0131l\u0131\u011f\u0131yla \u00f6nceden eklenerek t\u00fcm servislerin bu bilgileri do\u011frudan token \u00fczerinden okumas\u0131 sa\u011flan\u0131p olduk\u00e7a h\u0131zl\u0131 ve ba\u011f\u0131ms\u0131z bir \u00e7al\u0131\u015fma sergilenebilir.\n<\/li>\n
External Sistem Entegrasyonunda<\/em><\/strong> \nExternal sistem entegrasyonu ba\u011flam\u0131nda token mapper kullan\u0131m\u0131, kullan\u0131c\u0131ya ait bilgilerin sadece Keycloak i\u00e7inden de\u011fil, LDAP, veritaban\u0131 veya ba\u015fka bir \u00f6zel kaynaktan al\u0131narak token i\u00e7ine eklenmesini ifade etmektedir. Yani, kullan\u0131c\u0131ya ait bir attribute d\u0131\u015f bir sistemde tutuluyor olsa bile, bu bilgi login s\u0131ras\u0131nda \u00e7ekilip token’a yerle\u015ftirilir ve b\u00f6ylece uygulamalar bu veriye do\u011frudan token \u00fczerinden eri\u015febilir, ekstra bir entegrasyon \u00e7a\u011fr\u0131s\u0131 yapma ihtiyac\u0131 ortadan kalkar.<\/li>\n
Frontend Kullan\u0131m\u0131nda<\/em><\/strong> \nFrontend kullan\u0131m\u0131nda token mapper ise kullan\u0131c\u0131 giri\u015f yapt\u0131ktan sonra gerekli baz\u0131 bilgilerin (\u00f6rne\u011fin kullan\u0131c\u0131 ad\u0131, rol veya feature flag gibi verilerin) token i\u00e7ine eklenmesini sa\u011flayarak frontend uygulamas\u0131n\u0131n bu bilgilere ekstradan bir API \u00e7a\u011fr\u0131s\u0131 yapmadan do\u011frudan token \u00fczerinden ula\u015fmas\u0131n\u0131 sa\u011flamakta ve b\u00f6ylece hem performans\u0131 art\u0131rmakta hem de uygulaman\u0131n daha h\u0131zl\u0131 ve ba\u011f\u0131ms\u0131z \u00e7al\u0131\u015fmas\u0131na imkan tan\u0131maktad\u0131r.\n<\/li>\n<\/ol>\n
<\/span>Mapper’lar Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/span><\/h3>\n
Token mapper’lar, token \u00fcretim pipeline’\u0131n\u0131n bir par\u00e7as\u0131d\u0131r.<\/em><\/p><\/blockquote>\n
$\"Keycloak'da$ <\/a>Token mapper’lar\u0131n \u00e7al\u0131\u015fma mant\u0131\u011f\u0131 yukar\u0131daki g\u00f6rseldeki gibidir… Burada tek dikkat edilmesi gereken 2. ad\u0131m olan bilgi toplama a\u015famas\u0131d\u0131r. Evet… Keycloak, token \u00fcretmeden \u00f6nce a\u015fa\u011f\u0131daki bilgileri toplamaya koyulmaktad\u0131r:<\/p>\n
\n
User Bilgileri<\/strong>\n
\n
id<\/li>\n
username<\/li>\n
attributes<\/li>\n
roles<\/li>\n<\/ul>\n<\/li>\n
Client Bilgileri<\/strong>\n
\n
hangi uygulama istek att\u0131?<\/li>\n
bu client’\u0131n mapper’lar\u0131 nelerdir?<\/li>\n
hangi scope’lar ba\u011fl\u0131?<\/li>\n<\/ul>\n<\/li>\n
Realm Bilgileri<\/strong>\n
\n
global ayarlar<\/li>\n
default scope’lar<\/li>\n
realm-level roller<\/li>\n<\/ul>\n<\/li>\n<\/li>\n<\/ul>\n
Ard\u0131ndan sistemdeki t\u00fcm mapper’lar\u0131 toplayarak, bu bilgiler e\u015fli\u011finde bu mapper’lar\u0131 \u00e7al\u0131\u015ft\u0131racakt\u0131r.<\/p>\n
Mapper veri \u00fcretmez, var olan veriyi ta\u015f\u0131r \/ d\u00f6n\u00fc\u015ft\u00fcr\u00fcr.<\/em><\/p><\/blockquote>\n
<\/span>Mapper T\u00fcrleri Nelerdir?<\/span><\/h3>\n
\u015eimdi gelin en \u00f6nemli mapper t\u00fcrlerine dair fark\u0131ndal\u0131k olu\u015ftural\u0131m…<\/p>\n\n\n\n\n\n\n\n\n\n
Mapper T\u00fcr\u00fc<\/th>\n A\u00e7\u0131klama<\/th>\n \u00d6rnek<\/th>\n<\/tr>\n<\/thead>\n
User Attribute<\/td>\n Keycloak’da bir kullan\u0131c\u0131n\u0131n sahip oldu\u011fu ek bilgileri (attribute’lar\u0131) al\u0131p token i\u00e7ine eklemeye yarayan bir mapper t\u00fcr\u00fcd\u00fcr. \u00d6rne\u011fin; kullan\u0131c\u0131 profilinde tan\u0131ml\u0131 olan department = IT<\/code> gibi bir de\u011feri, bu mapper sayesinde token olu\u015fturma s\u00fcrecinde uygun bir claim olarak token’a yerle\u015ftirebilir ve nihai olarak \u00fcretilen token i\u00e7inde \u00f6rnekte verildi\u011fi \u015fekilde okunabilir bir de\u011fer \u00fcretilebilir. B\u00f6ylece API’lerden yahut frontend’den ekstra bir sorgu yapmaks\u0131z\u0131n bu bilgiye do\u011frudan token \u00fczerinden eri\u015filebilir.<\/td>\n \n
{\r\n \"department\": \"IT\"\r\n}<\/pre>\n<\/td>\n<\/tr>\n
Role Mapper<\/td>\n Keycloak’da kullan\u0131c\u0131n\u0131n sahip oldu\u011fu rolleri al\u0131p token i\u00e7erisine claim olarak ekleyen bir mapper t\u00fcr\u00fcd\u00fcr. Yani kullan\u0131c\u0131ya atanm\u0131\u015f olan ‘admin’ veya ‘user’ gibi roller, token olu\u015fturulurken otomatik olarak toplan\u0131r ve \u00f6rnekteki \u015fekilde token i\u00e7ine yerle\u015ftirilebilir. Bu vesileyle API veya uygulama taraf\u0131 yine ek bir sorguya ihtiya\u00e7 duymaks\u0131z\u0131n kullan\u0131c\u0131n\u0131n yetkilerini do\u011frudan token \u00fczerinden okuyabilir ve hatta bu de\u011ferlere g\u00f6re authorization i\u015flemlerini de ger\u00e7ekle\u015ftirebilir.<\/td>\n \n
{\r\n \"roles\": [\"admin\",\"user\"]\r\n}<\/pre>\n<\/td>\n<\/tr>\n
Hardcoded<\/td>\n Hardcoded mapper, Keycloak’da herhangi bir veri kayna\u011f\u0131na ihtiya\u00e7 duymaks\u0131z\u0131n token i\u00e7erisine sabit (statik) bir de\u011fer eklenmesine yaramaktad\u0131r. Kullan\u0131c\u0131ya veya role ba\u011fl\u0131 olmaks\u0131z\u0131n \u00f6nceden belirlenen bir bilgiyi her token olu\u015fturuldu\u011funda otomatik olarak i\u00e7ine yerle\u015ftirir.<\/td>\n \n
{\r\n \"app\": \"mobile\"\r\n}<\/pre>\n<\/td>\n<\/tr>\n
Group Mapper<\/td>\n Kullan\u0131c\u0131n\u0131n dahil oldu\u011fu gruplar\u0131 alarak bunlar\u0131 token i\u00e7erisine claim olarak ekleyen bir mapper t\u00fcr\u00fcd\u00fcr. Kullan\u0131c\u0131 hangi gruplara \u00fcyeyse bu bilgiler token olu\u015fturulurken toplan\u0131r ve \u00f6rnekteki \u015fekilde token i\u00e7erisine yerle\u015ftirilir. B\u00f6ylece uygulamalar kullan\u0131c\u0131n\u0131n grup bazl\u0131 yetkilerini do\u011frudan token \u00fczerinden edinebilme \u015fans\u0131 elde etmi\u015f olur.<\/td>\n \n
{\r\n \"groups\": [\"admin-group\"]\r\n}<\/pre>\n<\/td>\n<\/tr>\n
Script Mapper<\/td>\n Script mapper, yukar\u0131daki standart mapper’lar\u0131n sundu\u011fu sabit ve do\u011frudan veri ta\u015f\u0131ma mant\u0131\u011f\u0131n\u0131n \u00f6tesine ge\u00e7erek JavaScript tabanl\u0131 \u00f6zel bir mant\u0131k \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131na imkan veren geli\u015fmi\u015f bir mapper t\u00fcr\u00fcd\u00fcr. Bu mapper ile kullan\u0131c\u0131ya ait rol, attribute veya di\u011fer bilgiler \u00fczerinde i\u015flem yap\u0131labilir, bunlar birle\u015ftirilebilir ya da belirli ko\u015fullara g\u00f6re yeni claim’ler \u00fcretilebilir. Misal olarak kullan\u0131c\u0131 rol\u00fc ‘admin’ ise token i\u00e7erisine permission = full<\/code> gibi dinamik bir de\u011fer eklenerek daha esnek ve senaryoya \u00f6zel bir yap\u0131 kurulabilir.<\/td>\n \n
{\r\n \"permission\": \"full\"\r\n}<\/pre>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
<\/span>Token Mapper’lar\u0131n \u0130\u00e7 Yap\u0131s\u0131<\/span><\/h3>\n
Mimarisel olarak her bir mapper, token’a claim eklemeyi sa\u011flayan birer plugin’dir.<\/em><\/p><\/blockquote>\n
Bir mapper’\u0131n i\u00e7 yap\u0131s\u0131nda a\u015fa\u011f\u0131daki gibi d\u00f6rt ana husus s\u00f6z konusudur;<\/p>\n
\n
Yap\u0131land\u0131rma<\/strong>: Keycloak dashboard’da g\u00f6r\u00fclen alanlar yap\u0131land\u0131rma kapsam\u0131nda de\u011ferlendirilir. Bu a\u015famada kurgulanan yap\u0131land\u0131rma sayesinde runtime’da mapper’a nas\u0131l davranaca\u011f\u0131 s\u00f6ylenir.<\/li>\n
Veri Kayna\u011f\u0131<\/strong>: Mapper’\u0131n beslendi\u011fi kaynaklard\u0131r. Mapper, -veriyi nereden alaca\u011f\u0131m?-<\/em> sorusuna buradan cevap bulacakt\u0131r.<\/li>\n
D\u00f6n\u00fc\u015ft\u00fcrme (Mapping Logic)<\/strong>: Mapper’\u0131n kaynaktan elde etti\u011fi veriyi claim format\u0131na d\u00f6n\u00fc\u015ft\u00fcrmesidir.<\/li>\n
Token’a Entekte Etme<\/strong>: Nihai olarak elde edilen veri token i\u00e7erisine yerle\u015ftirilir.<\/li>\n<\/ul>\n
<\/span>Token Mapper’lar\u0131 Kullan\u0131rken Nelere Dikkat Edilmelidir?<\/span><\/h3>\n
Token mapper’larda olay sadece ‘claim eklemek’ de\u011fildir! Esas\u0131nda performans, g\u00fcvenlik ve mimarisel dengeyi do\u011fru kurgulamak gerekmektedir! Keycloak’u kullanan \u00e7o\u011fu sistemin bu noktada hata yapt\u0131\u011f\u0131n\u0131 s\u00f6yleyebilirim. Haliyle bu a\u00e7\u0131dan olay\u0131 de\u011ferlendirdi\u011fimizde sahada en ideal olabilecek yakla\u015f\u0131m i\u00e7in dikkat edilmesi gereken noktalara temas etmekte fayda g\u00f6rmekteyim…<\/p>\n
\n
Token gereksiz yere \u015fi\u015firilmemelidir!<\/strong>
\nToken mapper kullan\u0131rken en kritik noktalardan biri token’\u0131n gereksiz verilerle l\u00fczumsuz yere \u015fi\u015firilmemesine \u00f6zen g\u00f6sterilmesidir. \u00c7\u00fcnk\u00fc, JWT her istekte client ile server aras\u0131nda ta\u015f\u0131nacakt\u0131r. Ee bu durumda her fazladan verinin a\u011f trafi\u011fine maliyet olarak yans\u0131yaca\u011f\u0131 anlam\u0131na gelmektedir. Bu durum, \u00f6zellikle mobil veya d\u00fc\u015f\u00fck bant geni\u015fli\u011fine sahip ortamlarda ciddi performans problemlerine yol a\u00e7abilir. Bu y\u00fczden en do\u011fru yakla\u015f\u0131m, her istekte sadece ger\u00e7ekten ihtiya\u00e7 duyulan minimum bilginin token i\u00e7erisine konulmas\u0131d\u0131r.\n<\/li>\n
Token’a hassas veriler koyulmamal\u0131d\u0131r!<\/strong>
\nToken mapper kullan\u0131rken dikkat edilmesi gereken en \u00f6nemli konulardan biri de hassas verilerin token i\u00e7ine konulmamas\u0131na dikkat edilmesidir. Malumunuz, JWT yap\u0131sal olarak sadece base64 ile encode edilir ve asl\u0131nda \u015fifrelenmemektedir! Yani token’\u0131 ele ge\u00e7iren herkes \u00e7ok kolay bir \u015fekilde decode ederek i\u00e7eri\u011fini okuyabilir! Bu nedenle TCKN, gereksiz e-posta bilgileri yahut \u00f6zel kullan\u0131c\u0131 verileri gibi hassas bilgiler token i\u00e7ine eklenmemelidir.\n<\/li>\n
Access Token ile ID Token ayr\u0131m\u0131 ger\u00e7ekle\u015ftirilmelidir!<\/strong>
\nToken mapper kullan\u0131rken en s\u0131k yap\u0131lan olas\u0131 hatalardan biri de Access Token ile ID Token ayr\u0131m\u0131n\u0131n g\u00f6zetilmemesidir! Access Token, asl\u0131nda API’lerin kullanmas\u0131 ve yetkilendirme gibi backend tarafl\u0131 kontrollerin sa\u011flanmas\u0131 i\u00e7in tasarlanm\u0131\u015fken, ID Token ise genellikle frontend uygulamalar\u0131n\u0131n kullan\u0131c\u0131ya ait bilgilere eri\u015febilmesi i\u00e7in tasarlanm\u0131\u015ft\u0131r. Bu teorik ayr\u0131mdan yola \u00e7\u0131karak rol ve yetki gibi authorization s\u00fcrecini ilgilendiren veriler Access Token i\u00e7erisinde yer almal\u0131yken; kullan\u0131c\u0131 ad\u0131, anas\u0131n\u0131n k\u0131zl\u0131k soyad\u0131 vs. gibi frontend’in ilgilenece\u011fi veriler ise ID Token’da bulunmal\u0131d\u0131r.\n<\/li>\n
Token’\u0131n de\u011fi\u015ftirilemez (immutable) oldu\u011fu unutulmamal\u0131d\u0131r!<\/strong>
\nToken mapper kullan\u0131rken g\u00f6zden ka\u00e7\u0131r\u0131lmamas\u0131 gereken bir di\u011fer nokta ise token’\u0131n de\u011fi\u015ftirilemez (immutable) olmas\u0131d\u0131r. Yani kullan\u0131c\u0131ya ait bir rol veya yetki de\u011fi\u015fti\u011finde daha \u00f6nce \u00fcretilmi\u015f token’lar bu de\u011fi\u015fiklikten etkilenmeyecek ve eski bilgileri ta\u015f\u0131maya devam edecektir! Bu durum, zaman zaman sistemde istemsizce tutars\u0131zl\u0131klara yol a\u00e7abilecektir. \u0130\u015fte bundan kaynakl\u0131 bu durumu y\u00f6netebilmek ad\u0131na token s\u00fcrelerini k\u0131sa tutmal\u0131 ve m\u00fcmk\u00fcnse refresh token<\/a> mekanizmas\u0131yla s\u00fcre\u00e7 desteklenerek gerekti\u011fi taktirde kullan\u0131c\u0131y\u0131 sistemden d\u00fc\u015f\u00fcr\u00fcp (revoke\/logout) yeni token almas\u0131 sa\u011flanmal\u0131d\u0131r. Bu ve buna benzer stratejilerle s\u00fcre\u00e7 daha korunakl\u0131 ve g\u00fcvenilir hale getirilmelidir.\n<\/li>\n
Script mapper’lar dikkatli kullan\u0131lmal\u0131d\u0131r!<\/strong>
\nScript mapper’lar olduk\u00e7a g\u00fc\u00e7l\u00fc olmalar\u0131na ra\u011fmen beraberinde kritik riskler bar\u0131nd\u0131rmaktad\u0131rlar. Bu mapper’lar JavaScript tabanl\u0131 \u00f6zel logic \u00e7al\u0131\u015ft\u0131rd\u0131\u011f\u0131 i\u00e7in her token \u00fcretiminde ekstra i\u015flem y\u00fck\u00fc olu\u015fturabilir ve bu da \u00f6zellikle yo\u011fun sistemlerde performans d\u00fc\u015f\u00fc\u015f\u00fcne neden olabilir. Ayr\u0131ca bu t\u00fcr dinamik yap\u0131lar\u0131n debug edilmesi zor oldu\u011fu i\u00e7in bak\u0131m maliyetlerinin y\u00fcksek hale gelebilme olas\u0131l\u0131\u011f\u0131 s\u00f6z konusudur. Bu y\u00fczden, Script mapper’lar\u0131n yaln\u0131zca standart mapper’lar\u0131n yeterli olmad\u0131\u011f\u0131 ve ger\u00e7ekten \u00f6zel bir i\u015f kural\u0131na ihtiya\u00e7 duyuldu\u011fu durumlarda tercih edilmesine \u00f6zen g\u00f6sterilmelidir.\n<\/li>\n
Claim isimlendirme standard\u0131na \u00f6zen g\u00f6sterilmelidir!<\/strong>
\nGeli\u015fi g\u00fczel veya belirsiz isimler kullanmak zamanla sistemde ciddi bir karma\u015faya yol a\u00e7abilir. Bu her konuda ge\u00e7erli oldu\u011fu gibi claim’ler i\u00e7in de ge\u00e7erlidir. Neyi temsil etti\u011fi belli olmayan alanlar yerine a\u00e7\u0131k ve anlaml\u0131 isimler tercih edilmeli ve m\u00fcmk\u00fcn mertebe camelCase<\/code> yahut snake_case<\/code> gibi isimlendirme standard\u0131 benimsenmelidir. Ve daha da \u00f6nemlisi OpenID Connect (OIDC) taraf\u0131ndan zaten tan\u0131mlanm\u0131\u015f standart claim isimleri mevcutsa bunlara sad\u0131k kal\u0131nmal\u0131d\u0131r.\n<\/li>\n
Yerine g\u00f6re client scope kullan\u0131lmal\u0131d\u0131r!<\/strong> \nToken mapper kullan\u0131m\u0131nda yap\u0131lan bir di\u011fer hata ise bir mapper’\u0131 birden fazla client i\u00e7in tekrar tekrar tan\u0131mlamakt\u0131r. Bu yakla\u015f\u0131m, k\u0131sa vadede \u00e7al\u0131\u015fsa da uzun vadede ciddi bir y\u00f6netim ve bak\u0131m karma\u015fas\u0131na yol a\u00e7acakt\u0131r. \u00c7\u00fcnk\u00fc, herhangi bir de\u011fi\u015fiklik gerekti\u011finde t\u00fcm client’larda tek tek g\u00fcncelleme yapmak gerekecektir. Bunun yerine Keycloak’taClient Scope<\/a> kullanarak mapper’lar\u0131 merkezi bir yap\u0131ya almak \u00e7ok daha do\u011fru bir yakla\u015f\u0131m olacakt\u0131r. B\u00f6ylece ilgili mapper’\u0131 bir kez tan\u0131mlayabilir ve ihtiya\u00e7 duyulan t\u00fcm client’lara bu scope’u ba\u011flayarak hem tekrar\u0131n \u00f6n\u00fcne ge\u00e7ilebilir hem de daha temiz, s\u00fcrd\u00fcr\u00fclebilir ve \u00f6l\u00e7eklenebilir bir yap\u0131 kurulabilir.\n<\/li>\n
Gereksiz mapper yazmaktan \u00e7ekinilmelidir!<\/strong> \nHer mapper, uygulaman\u0131n login ve authentication s\u00fcre\u00e7lerinde ekstra bir katman olarak devreye girecektir. Bu da her istekte ek i\u015flem, bellek kullan\u0131m\u0131 ve CPU maliyeti anlam\u0131na gelir. \u00d6zellikle birden fazla mapper kulland\u0131\u011f\u0131n\u0131zda bu etki katlanarak b\u00fcy\u00fcyebilir ve auth i\u015flemlerinde belirgin \u015fekilde yava\u015flama s\u00f6z konusu olabilir. Bu y\u00fczden prensip \u00e7ok nettir! M\u00fcmk\u00fcn oldu\u011funca az ve ger\u00e7ekten gerekliyse mapper yaz\u0131lmal\u0131d\u0131r…\n<\/li>\n
Token boyutu test edilmelidir!<\/strong> \nJWT token boyutu, \u00e7o\u011fu geli\u015ftiricinin g\u00f6z ard\u0131 etti\u011fi ama performans a\u00e7\u0131s\u0131ndan olduk\u00e7a kritik bir konudur. Token ne kadar b\u00fcy\u00fckse, her HTTP iste\u011finin header’\u0131nda o kadar fazla veri ta\u015f\u0131nacak, bu da a\u011f trafi\u011fini \u015fi\u015firecek ve latency’yi art\u0131racakt\u0131r. Bundan kaynakl\u0131 token’\u0131n ka\u00e7 KB oldu\u011fu mutlaka test edilmeli ve header size’\u0131 \u00f6l\u00e7\u00fclmelidir. \u0130deal olarak token boyutunu m\u00fcmk\u00fcn mertebe 2-3 KB’\u0131n alt\u0131nda tutmakt\u0131r. Bu kontrol performans optimizasyonunun bir par\u00e7as\u0131d\u0131r.<\/u>\n<\/li>\n
Microservice uyumu d\u00fc\u015f\u00fcn\u00fclmelidir!<\/strong> \nMapper’\u0131 tasarlarken en \u00f6nemli sorulardan biri -bu veri ger\u00e7ekten t\u00fcm microservice’lerde laz\u0131m m\u0131?-<\/em> sorusudur… E\u011fer cevap evet ise, yani veri bir\u00e7ok servisin ortak ihtiyac\u0131ysa, o taktirde token’a koymakta fayda olacakt\u0131r. Yok e\u011fer birka\u00e7 servise \u00f6zg\u00fc bir veri ise token’\u0131 \u015fi\u015firmek yerine o verinin o servislere \u00f6zel olarak ba\u015fka \u015fekillerde ta\u015f\u0131nmas\u0131 daha ak\u0131ll\u0131ca olacakt\u0131r. Bu hassasiyet, token boyutunu gereksiz yere b\u00fcy\u00fctmeksizin microservice mimarisindeki veri ak\u0131\u015f\u0131n\u0131 daha temiz ve verimli hale getirecektir.\n<\/li>\n
Versiyonlama \u00f6nemsenmelidir!<\/strong> \nToken yap\u0131s\u0131 de\u011fi\u015fti\u011finde (yeni claim eklendi\u011finde, mevcut bir claim’in yap\u0131s\u0131 yahut ad\u0131 de\u011fi\u015fti\u011finde) eski versiyona tabii client’lar aniden patlayabilir ve kullan\u0131c\u0131lar giri\u015f yapamaz hale gelebilir. Bu riski \u00f6nlemenin ileri seviye \u00e7\u00f6z\u00fcm\u00fc, token’lara claim versiyonlamas\u0131 eklemek ve her daim backward compatibility’yi (geriye d\u00f6n\u00fck uyumluluk) g\u00f6zetmektir. B\u00f6ylece yeni token yap\u0131s\u0131na ge\u00e7ilse bile eski client’lar sorunsuz \u00e7al\u0131\u015fmaya devam edecektir. Versiyonlama sayesinde token yap\u0131s\u0131n\u0131 \u00f6zg\u00fcrce evriltebilir ve yeni \u00f6zellikler ekleyebilirken bir yandan da mevcut kullan\u0131c\u0131 deneyimini koruyabiliriz. Bu yakla\u015f\u0131m, uzun \u00f6m\u00fcrl\u00fc ve sa\u011flam bir authentication sistemi kurman\u0131n en kritik par\u00e7alar\u0131ndan birisidir.\n<\/li>\n<\/ul>\n<\/span>13 Kritik Soru \/ 13 Kritik Cevap<\/span><\/h3>\n\nSoru 1 | Token Mapper olmasayd\u0131 ne yapard\u0131k?<\/span><\/summary>\nMapper, token i\u00e7ine veri koyarak stateless authentication sa\u011flar. Dolay\u0131s\u0131yla olmasayd\u0131, her request’te eri\u015fmemiz gereken verilere DB \/ UserInfo endpoint’lerini \u00e7a\u011f\u0131rarak eri\u015fmemiz gerecekti! B\u00f6ylece latency artacak, sistem yava\u015flayacak ve microservice’lerde de ba\u011f\u0131ml\u0131l\u0131k riski s\u00f6z konusu olabilecektir. Mapper’lar sayesinde laz\u0131m olan veriler her servisin direkt okuyaca\u011f\u0131 \u015fekilde ba\u015ftan token’a koyulmaktad\u0131r. Bu da bizlere performans ve olas\u0131 maliyetler a\u00e7\u0131s\u0131ndan b\u00fcy\u00fck avantajlar sa\u011flamaktad\u0131r. \n<\/details>\n\nSoru 2 | Token’a neler koyulmamal\u0131d\u0131r?<\/span><\/summary>\n\u015eifreler, TCKN gibi hassas ki\u015fisel veriler koyulmamal\u0131d\u0131r. \u00c7\u00fcnk\u00fc, token decode edilerek hassas veriler ba\u015fkalar\u0131 taraf\u0131ndan rahatl\u0131kla elde edilebilmektedir.<\/p>\n Ayr\u0131ca listeler ve JSON blob’lar gibi b\u00fcy\u00fck veriler de koyulmamal\u0131d\u0131r! \u00c7\u00fcnk\u00fc, token boyutu performans\u0131 etkilemektedir. \n<\/details>\n\nSoru 3 | Mapper’\u0131 access token’a m\u0131 yoksa ID token’a m\u0131 eklemeliyiz?<\/span><\/summary>\nE\u011fer API’de kullan\u0131lacaksa access token’a, yok e\u011fer UI’da kullan\u0131lacaksa ID token’a eklenmelidir. \n<\/details>\n\nSoru 4 | Neden client scope diye bir \u015fey var?<\/span><\/summary>\nClient scope, mapper’lar\u0131 tek tek her client manuel olarak eklemek yerine, reusable bir paket olarak y\u00f6netilmesini sa\u011flayan ak\u0131ll\u0131 bir mekanizmad\u0131r. Misal olarak; 10 adet microservice’in s\u00f6z konusu oldu\u011fu bir senaryoda bir mapper’\u0131 hepsinde kullanmak gerekiyorsa her servise ayr\u0131 ayr\u0131 mapper eklemek hem zaman hem de bak\u0131m a\u00e7\u0131s\u0131ndan k\u00fclfettir. Bunun yerine bir client scope olu\u015fturup mapper’\u0131 bu scope’un i\u00e7ine koyar, ard\u0131ndan ilgili t\u00fcm client’lar bu scope’a ba\u011flan\u0131rsa, hem mapper tek bir yerden y\u00f6netilmi\u015f hem de t\u00fcm client’lara otomatik olarak uygulanm\u0131\u015f olacakt\u0131r. Bu sayede merkezi yap\u0131land\u0131rma e\u015fli\u011finde temiz ve d\u00fczenli bir y\u00f6netim sa\u011flanm\u0131\u015f olur. \n<\/details>\n \nSoru 5 | Mapper runtime’da m\u0131 \u00e7al\u0131\u015f\u0131r yoksa login s\u0131ras\u0131nda m\u0131?<\/span><\/summary>\nSadece token olu\u015fturulurken yani login s\u0131ras\u0131nda \u00e7al\u0131\u015f\u0131r! Ayr\u0131ca refresh token kullan\u0131ld\u0131\u011f\u0131nda da \u00e7al\u0131\u015facakt\u0131r. \n<\/details>\n \nSoru 6 | Token’daki veri g\u00fcncel de\u011filse ne olur?<\/span><\/summary>\nToken immutable’d\u0131r. Haliyle eski token’lar da eski veriler mevcuttur. \u00c7\u00f6z\u00fcm olarak k\u0131sa token \u00f6mr\u00fc verilmeli, m\u00fcmk\u00fcn mertebe refresh token ve revoke mekanizmas\u0131ndan istifade edilmelidir. \n<\/details>\n \nSoru 7 | Mapper ile authorization yap\u0131l\u0131r m\u0131?<\/span><\/summary>\nMapper sadece token’a veri ta\u015f\u0131r. \n<\/details>\n \nSoru 8 | Script Mapper ne zaman kullan\u0131l\u0131r?<\/span><\/summary>\n\nVeri transform edilecekse<\/li>\n Birden fazla attribute birle\u015fecekse<\/li>\n Conditional logic gerekiyorsa<\/li>\n<\/ul>\nBu durumlarda script mapper tercih edilebilir. Misal olarak; role + department \u2192 permission<\/code> \u00fcretimi gibi durumlar i\u00e7in akla gelmelidir.<\/p>\n Ama unutulmamal\u0131d\u0131r ki, performans maliyeti mevcuttur ve bak\u0131m s\u00fcreci ister istemez zorla\u015fmaktad\u0131r. \n<\/details>\n \nSoru 9 | Mapper performans\u0131 etkiler mi?<\/span><\/summary>\nElbet etkileyecektir. \u00d6zellikle login s\u00fcrecinde mapper’lar\u0131n devreye girmesi hem s\u00fcreci uzataca\u011f\u0131 hem de token boyutunu b\u00fcy\u00fctece\u011fi i\u00e7in t\u00fcm bunlar network maliyetine yans\u0131yacakt\u0131r.<\/p>\n \u00d6zellikle script mapper ve external data mapper durumlar\u0131 haddinden fazla maliyetli olaca\u011f\u0131 i\u00e7in dikkat edilmelidir. \n<\/details>\n \nSoru 10 | Mapper ile multi-tenant yap\u0131 kurulur mu? Ya da bir ba\u015fka deyi\u015fle tenant bilgisi mapper ile y\u00f6netilebilir mi?<\/span><\/summary>\nMapper’lar kullan\u0131larak multi-tenant<\/a> bir yap\u0131 kurmak olduk\u00e7a yayg\u0131n ve pratik bir yakla\u015f\u0131md\u0131r. Kullan\u0131c\u0131ya ait tenant bilgisi token i\u00e7ine bir claim olarak eklenerek her istekte bu bilginin ta\u015f\u0131nmas\u0131 sa\u011flan\u0131r ve b\u00f6ylece backend taraf\u0131nda gelen request’lerdeki tenant bilgisi ile token’daki tenant kar\u015f\u0131la\u015ft\u0131r\u0131larak yetki kontrol\u00fc ilgili tenant kapsam\u0131nda ger\u00e7ekle\u015ftirilip i\u015flemler y\u00fcr\u00fct\u00fcl\u00fcr. \n<\/details>\n \nSoru 11 | Mapper ile dynamic permission yap\u0131l\u0131r m\u0131?<\/span><\/summary>\nHay\u0131r… Mapper, permission’\u0131 token’a koyar ama runtime’da de\u011fi\u015ftiremez! Yani bu ihtiya\u00e7 i\u00e7in token mapper’lar yetersiz kalmaktad\u0131r. Dinamik yetkilendirme senaryolar\u0131n\u0131 \u00e7\u00f6zebilmek i\u00e7in policy engine veya DB lookup gibi \u00e7\u00f6z\u00fcmlere gidilmesi \u00f6nerilmektedir.<\/p>\n Policy Engine<\/strong><\/em>, yetki kararlar\u0131n\u0131 sabit token i\u00e7inden okumak yerine, d\u0131\u015far\u0131da \u00e7al\u0131\u015fan bir karar motoruna<\/u> soran bir yap\u0131lanmad\u0131r. \u00d6rne\u011fin; Open Policy Agent (OPA)<\/em>, -bu kullan\u0131c\u0131 \u015fu kayna\u011fa eri\u015febilir mi?-<\/em> sorusunu runtime’da kurallara g\u00f6re de\u011ferlendirerek dinamik bir \u015fekilde y\u00f6nlendirmede bulunabilir. B\u00f6ylece roller veya claim’ler statik de\u011fildir, bilakis anl\u0131k kurallar ve ba\u011flama g\u00f6re \u015fekillenecektir.<\/p>\n DB lookup<\/strong><\/em> ise daha basit olsa da yine de dinamik bir davran\u0131\u015f sergileyen yakla\u015f\u0131md\u0131r. Burada uygulama, gelen request’teki kullan\u0131c\u0131 bilgisine bak\u0131p veritaban\u0131na gider ve g\u00fcncel yetkileri, tenant bilgisini veya izinleri o anda \u00e7eker. ani token’daki bilgiye k\u00f6r\u00fc k\u00f6r\u00fcne g\u00fcvenmek yerine -en g\u00fcncel veri ne?-<\/em> diyerek her istekte kontrol sa\u011flar. \n<\/details>\n\nSoru 12 | Mapper ile UserInfo endpoint fark\u0131 nedir?<\/span><\/summary>\nMapper ile UserInfo ayn\u0131 amaca hizmet eden iki farkl\u0131 yakla\u015f\u0131md\u0131r.<\/p>\n Mapper, Keycloak i\u00e7inde tan\u0131mlanan bir \u00f6zelliktir, yani config’tir. Login an\u0131nda \u00e7al\u0131\u015f\u0131r ve kullan\u0131c\u0131 bilgilerini token’\u0131n i\u00e7ine g\u00f6mmemizi sa\u011flar. Sonras\u0131nda ise uygulama bu bilgileri ba\u015fka hi\u00e7bir yere gitmeye gerek kalmaks\u0131z\u0131n direkt token i\u00e7erisinden okuyabilir. Yani stateless’dir.<\/p>\n UserInfo ise endpoint’tir. Token’\u0131 al\u0131p Keycloak’a tekrar istek atarak kullan\u0131c\u0131ya dair bilgiler edinilmesini sa\u011flar. Keycloak, bu istek neticesinde o anki bilgiyi d\u00f6ner. Dolay\u0131s\u0131yla her seferinde bir d\u0131\u015f \u00e7a\u011fr\u0131 gerektirir. Bundan kaynakl\u0131 stateful’dur.<\/p>\nStateless, sistemin \u00e7al\u0131\u015fmak i\u00e7in ekstra bir yere (DB, servis vs.) gidip bilgi talep etmesine gerek olmamas\u0131, yani t\u00fcm gerekli bilginin token’da bulunmas\u0131d\u0131r.<\/p>\n Stateful ise, sistmein karar verebilmesi i\u00e7in her istekte d\u0131\u015f bir kayna\u011fa gidip g\u00fcncel durumu kontrol etmesi demektir.<\/em><\/p><\/blockquote>\n Mapper \u2192 Bilgiyi ba\u015ftan cebime koyar\u0131m… \nUserInfo \u2192 Bilgi gerektik\u00e7e gidip sorar\u0131m… \n<\/details>\n\nSoru 13 | Mapper ile security a\u00e7\u0131\u011f\u0131 olu\u015fur mu?<\/span><\/summary>\nEvet! token’\u0131n public olmas\u0131ndan dolay\u0131 hassas verilerin s\u0131zd\u0131r\u0131lmas\u0131 olas\u0131d\u0131r. Dikkat edilmelidir! \n<\/details>\n<\/span>Token Mapper’lar\u0131n Kullan\u0131m\u0131<\/span><\/h3>\n\u015eimdi s\u0131ra token mapper’lar\u0131 deneyimlemeye geldi.<\/p>\n\u0130lk olarak Keycloak’da bir kullan\u0131c\u0131n\u0131n edindi\u011fi token’\u0131n en sade haliyle nas\u0131l bir i\u00e7eri\u011fe sahip oldu\u011funu inceleyelim… \n<\/a>Evet… G\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere bir kullan\u0131c\u0131da varsay\u0131lan olarak a\u015fa\u011f\u0131 yukar\u0131 yandaki g\u00f6rseldeki gibi i\u00e7eri\u011fe sahip bir token yap\u0131s\u0131 gelmektedir.<\/p>\n Tabi ki de kullan\u0131c\u0131ya rol yahut yetki verdik\u00e7e buradaki payload \u015fekillenecektir. \u00c7\u00fcnk\u00fc bu claim’ler zaten bu kaynaklardan beslenmektedir. Ancak ana claim’lerin yan\u0131na ekstradan bir kullan\u0131c\u0131 bilgisi eklemek isterseniz burada attribute olu\u015fturup mapper’lar ile eklemeniz en do\u011fru yakla\u015f\u0131m olacakt\u0131r. Bu yakla\u015f\u0131m, yukar\u0131daki sat\u0131rlarda Mapper T\u00fcrleri Nelerdir?<\/a> ba\u015fl\u0131\u011f\u0131 alt\u0131nda de\u011ferlendirdi\u011fimiz User Attribute Mapper<\/strong> t\u00fcr\u00fcne kar\u015f\u0131l\u0131k gelmektedir.<\/p>\n Diyelim ki, kullan\u0131c\u0131lar\u0131n department<\/code> bilgisini token’a claim olarak eklemek istiyoruz. Tabi bunun i\u00e7in \u00f6ncelikle ilgili isimde bir attribute eklenmesi gerekecektir.<\/p>\n Bu da Realm settings<\/code> \u00fczerinden User profile<\/code> sekmesine gelerek ger\u00e7ekle\u015ftirilebilir.<\/a>\u015eimdi normal \u015fartlarda, bu attribute’u ekledikten sonra a\u015fa\u011f\u0131daki gibi kullan\u0131c\u0131 detaylar\u0131ndan doldurulup kaydedildi\u011finde token’a gelmesini bekleyebilirsiniz.<\/a>Ancak nafile… Bu attribute taraf\u0131m\u0131zca olu\u015fturuldu\u011fu ve sistem taraf\u0131ndan bilinmedi\u011fi i\u00e7in bizim taraf\u0131m\u0131zdan token’a eklenmesi gerekecektir. Bunun i\u00e7in mapper olu\u015fturulmas\u0131 gerekmektedir.<\/p>\n <\/span>Token Mapper Olu\u015fturma<\/span><\/h4>\n<\/a>Token mapper olu\u015fturman\u0131n en temiz ve do\u011fru yolu scope olarak olu\u015fturmakt\u0131r. Bunun i\u00e7in Client Scopes<\/code> men\u00fcs\u00fcne gelerek bir scope olu\u015fturulmal\u0131d\u0131r.<\/p>\n \u015eimdi bu scope’a olu\u015fturaca\u011f\u0131m\u0131z mapper ile hem istedi\u011fimiz attribute’u token’a ekleyebilece\u011fiz hem de istedi\u011fimiz client’ta bu scope’u \u00e7a\u011f\u0131rarak, o client’tan olacak login s\u00fcre\u00e7lerinde mapper’dan istifade edebiliyor olaca\u011f\u0131z. B\u00f6ylece bir mapper’\u0131 scope \u00fczerinden tek seferde tan\u0131mlay\u0131p, farkl\u0131 client’larda kullanabilecek ve tekrar tekrar tan\u0131mlama zahmetinden kurtulmu\u015f olaca\u011f\u0131z.<\/p>\n Devam etmeden \u00f6nce ak\u0131llara gelebilecek olan ideal olan her mapper i\u00e7in ayr\u0131 bir scope olu\u015fturmak m\u0131?<\/strong><\/em> sorusunu cevapland\u0131ral\u0131m istiyorum… El-cevap: Hay\u0131r. Her mapper i\u00e7in ayr\u0131 bir scope olu\u015fturmak do\u011fru bir kabul olmayacakt\u0131r. \u00c7\u00fcnk\u00fc, scope dedi\u011fimiz \u015fey esas\u0131nda mant\u0131ksal bir paket gibi d\u00fc\u015f\u00fcn\u00fclebilir. Yani claim’leri tek tek ayr\u0131 scope’lara da\u011f\u0131tmak yerine, birbiriyle ili\u015fkili olanlar\u0131 ayn\u0131 scope i\u00e7ine toplamak en do\u011frusu olacakt\u0131r. Misal olarak; profile-data<\/code> diye bir scope a\u00e7\u0131p i\u00e7ine name<\/em>, surname<\/em>, department<\/em> vs. gibi mapper’lar\u0131 koymak ya da authorization-data<\/code> diye bir scope i\u00e7erisine de roles<\/em>, groups<\/em> vs. gibi claim’leri depolamak en mant\u0131kl\u0131s\u0131d\u0131r. Olaya mant\u0131ksal olarak bakarsak e\u011fer; mapper’lar, tekil kuralken, scope’lar ise bu kurallar\u0131n mant\u0131kl\u0131 grupland\u0131\u011f\u0131 paketler olarak d\u00fc\u015f\u00fcn\u00fclebilir. O y\u00fczden her mapper’a ayr\u0131 bir scope de\u011fil, anlaml\u0131 gruplara g\u00f6re scope olu\u015fturmak en sa\u011fl\u0131kl\u0131 kabul olacakt\u0131r.<\/p>\n Velhas\u0131l…<\/p>\n \u0130lgili scope’a t\u0131klay\u0131p Mappers sekmesine geldi\u011fimizde bizleri a\u015fa\u011f\u0131daki gibi iki se\u00e7enek kar\u015f\u0131layacakt\u0131r:<\/a><\/p>\n\n\n\nAdd predefined mapper<\/div>\nHaz\u0131r mapper\u2019lar\u0131 tek t\u0131kla eklemesini sa\u011flar, ekstra config gerektirmez.<\/div>\nemail, preferred_username, roles<\/code><\/div>\n<\/td>\n \nConfigure a new mapper<\/div>\nCustom mapper olu\u015fturulmas\u0131n\u0131 sa\u011flar, claim tamamen taraf\u0131m\u0131zca tan\u0131mlan\u0131r.<\/div>\ndepartment \u2192 \"IT\"<\/code><\/div>\n<\/td>\n<\/tr>\n<\/table>\nBizler senaryomuza uygun olarak Configure a new mapper<\/strong><\/em> se\u00e7ene\u011finden devam edece\u011fiz.<\/p>\n <\/span>User Attribute Mapper Olu\u015fturma<\/span><\/h5>\n\u0130lgili se\u00e7ene\u011fe t\u0131klad\u0131\u011f\u0131m\u0131zda a\u00e7\u0131lan pencereden a\u015fa\u011f\u0131daki gibi User Attribute<\/strong> t\u00fcr\u00fc se\u00e7ilmeli,<\/a><\/a>ve ard\u0131ndan yandaki gibi ilgili mapper yap\u0131land\u0131r\u0131lmal\u0131d\u0131r.<\/p>\n Buradaki yap\u0131land\u0131rmalara de\u011finmemiz gerekirse e\u011fer;<\/p>\n \nMapper type<\/strong>: Mapper’\u0131n t\u00fcr\u00fcn\u00fc ifade etmektedir.<\/li>\n Name<\/strong>: Teknik olarak hi\u00e7bir \u015feye etki etmiyor olsa da mapper’\u0131n Keycloak i\u00e7indeki ismine kar\u015f\u0131l\u0131k gelmektedir.<\/li>\n User Attribute<\/strong>: User’\u0131n hangi attribute’una kar\u015f\u0131l\u0131k bu mapper’\u0131n olu\u015fturuldu\u011fu belirlenmektedir.<\/li>\n Token Claim Name<\/strong>: Token’da hangi claim’e kar\u015f\u0131l\u0131k bu de\u011ferin eklenece\u011fi belirlenmektedir.<\/li>\n Claim JSON Type<\/strong>: Verinin tipi belirlenmektedir.<\/li>\n Add to ID token<\/strong>: Claim’in ID token’a eklenip eklenmeyece\u011fini yap\u0131land\u0131rmaktad\u0131r.<\/li>\n Add to access token<\/strong>: Benzer mant\u0131kla claim’in access token’a eklenip eklenmeyece\u011fini yap\u0131land\u0131rmaktad\u0131r.<\/li>\n Add to lightweight access token<\/strong>: Standart kullan\u0131m\u0131n d\u0131\u015f\u0131nda kalan bir optimizasyondur. Keycloak, token’\u0131 k\u00fc\u00e7\u00fcltmek ve daha h\u0131zl\u0131 ta\u015f\u0131yabilmek i\u00e7in kimi zaman hafif (lightweight) access token \u00fcretimi ger\u00e7ekle\u015ftirebilmektedir. \u0130\u015fte bu ayar, bu durumlarda ilgili claim’in eklenip eklenmeyece\u011fini yap\u0131land\u0131rmaktad\u0131r.<\/li>\n Add to userinfo<\/strong>: UserInfo endpoint’i \u00e7a\u011fr\u0131ld\u0131\u011f\u0131nda bu verinin d\u00f6n\u00fcp d\u00f6nmeyece\u011fi belirlenmektedir.<\/li>\n Add to token introspection<\/strong>: Token introspection endpoint’inde bu claim’in g\u00f6r\u00fcn\u00fcp g\u00f6r\u00fcnmeyece\u011fi yap\u0131land\u0131r\u0131lmaktad\u0131r.<\/li>\nMultivalued<\/strong>: \u0130lgili claim’in de\u011ferinin \u00e7oklu olup olmayaca\u011f\u0131n\u0131 yap\u0131land\u0131rmaktad\u0131r. E\u011fer \u00e7oklu olursa de\u011feri bir array i\u00e7erisinde getirecektir.\n\nOff<\/em>\n\"department\": \"IT\"<\/pre>\n<\/li>\nOn<\/em>\n\"department\": [\"IT\", \"HR\"]<\/pre>\n<\/li>\n<\/ul>\n<\/li>\nAggregate attribute values<\/strong>: E\u011fer kullan\u0131c\u0131da ayn\u0131 attribute’tan birden fazla mevcutsa hepsini birle\u015ftirip birle\u015ftirmeyece\u011fini yap\u0131land\u0131rmaktad\u0131r. Kapal\u0131 kald\u0131\u011f\u0131 taktirde ilk de\u011feri alacakt\u0131r.<\/li>\n<\/ul>\nEvet, bu yap\u0131land\u0131rma ayarlar\u0131nda bir mapper’\u0131 olu\u015fturduktan sonra ilgili client \u00fczerinden elde edilen token’\u0131n payload’una g\u00f6z atarsak a\u015fa\u011f\u0131daki gibi department<\/code> de\u011ferinin geldi\u011fini g\u00f6zlemlemi\u015f olaca\u011f\u0131z…<\/a><\/p>\n <\/span>Hardcoded Mapper Olu\u015fturma<\/span><\/h5>\nPeki… \u00d6rne\u011fimizi geni\u015fletmek ad\u0131na bir de sabit de\u011ferlerin token’a nas\u0131l eklendi\u011fini inceleyelim. Tabi bunun i\u00e7in de Hardcoded Mapper<\/strong> olu\u015fturmam\u0131z gerekecektir.<\/p>\n Bu sabit de\u011fer i\u00e7in uygun bir scope olu\u015fturabiliriz. Mesela; info<\/code> ad\u0131nda bir scope’umuz olsun.<\/p>\nBu scope’a Configure a new mapper<\/em><\/strong> se\u00e7ene\u011fi \u00fczerinden Hardcoded claim<\/strong>‘i se\u00e7erek sabit bir de\u011fer ekleyebiliriz. <\/a>Evet, g\u00f6rselde eksik kalan yap\u0131land\u0131rmalar\u0131 \u00f6nceki sat\u0131rdakilerle ayn\u0131 olaca\u011f\u0131 i\u00e7in es ge\u00e7mi\u015f bulunuyorum. Bu \u015fekilde bir mapper’\u0131 olu\u015fturup, info<\/code> scope’unu da ilgili client’a ekleyerek bir token talep edersek, bu token i\u00e7erisinde a\u015fa\u011f\u0131daki g\u00f6rselde oldu\u011fu gibi sabit de\u011ferin de geldi\u011fini g\u00f6rm\u00fc\u015f olaca\u011f\u0131z.<\/a><\/p>\n \u0130\u015fte bu kadar…<\/p>\n Geri kalan mapper t\u00fcrlerini tecr\u00fcbe etmeyi sizlere b\u0131rak\u0131yorum \ud83d\ude09<\/p>\n Nihai olarak;<\/p>\n Token’a koyulan her veri, esas\u0131nda sisteme at\u0131lan bir imzad\u0131r… Ya performans\u0131 h\u0131zland\u0131r\u0131r ya da fark etmeden sistemi yava\u015flat\u0131r… Ya g\u00fcveli\u011fi g\u00fc\u00e7lendirir ya da zafiyet olu\u015fturabilir… Token Mapper’lar bu y\u00fczden basit bir \u00f6zellik de\u011fildir, bilakis do\u011fru kullan\u0131ld\u0131\u011f\u0131nda ihtiya\u00e7 gideren ancak yanl\u0131\u015f kullan\u0131ld\u0131\u011f\u0131nda aya\u011fa dola\u015f\u0131p t\u00f6kezleten stratejik bir yap\u0131lanmad\u0131r. Bu y\u00fczden mesele hi\u00e7bir zaman -token’a ne koyabilirim?-<\/em> sorusu de\u011fildir! -ger\u00e7ekten neyi koymal\u0131y\u0131m?-<\/em> sorusudur… Bu soruya verilen cevap, kurulan sistemin kalitesiyle do\u011fru orant\u0131l\u0131d\u0131r.<\/p>\n \u0130lgilenenlerin faydalanmas\u0131 dile\u011fiyle… \nSonraki yaz\u0131lar\u0131mda g\u00f6r\u00fc\u015fmek \u00fczere… \n\u0130yi \u00e7al\u0131\u015fmalar…<\/p>\n","protected":false},"excerpt":{"rendered":" Merhaba, Bu i\u00e7eri\u011fimizde, Keycloak’da \u00fcretilen token’lar\u0131n i\u00e7ine ek veri eklenmesini sa\u011flayan Token Mapper mekanizmas\u0131n\u0131 mercek alt\u0131na al\u0131yor olacak ve nedir, ne i\u015fe yarar ve hangi senaryolarda kullan\u0131l\u0131r? gibi sorulara cevap ararken, konuyu sadece teoride...<\/p>\n","protected":false},"author":1,"featured_media":28235,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5206,5554],"tags":[5690,1136,5689,5686,5555,5692,5693,5588,5688,5691,5685,5687],"class_list":["post-28550","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-net","category-keycloak","tag-group-mapper","tag-hardcoded","tag-hardcoded-mapper","tag-introspection","tag-keycloak","tag-opa","tag-open-policy-agent","tag-policy-engine","tag-role-mapper","tag-script-mapper","tag-token-mapper","tag-user-attribute"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28550","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/comments?post=28550"}],"version-history":[{"count":15,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28550\/revisions"}],"predecessor-version":[{"id":28580,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28550\/revisions\/28580"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media\/28235"}],"wp:attachment":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/media?parent=28550"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/categories?post=28550"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/tags?post=28550"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}