Bu i\u00e7eri\u011fimizde, UMA 2.0<\/em> standard\u0131n\u0131 temel alan; klasik rol bazl\u0131 yetkilendirme<\/a> mant\u0131\u011f\u0131ndan \u00e7ok daha g\u00fc\u00e7l\u00fc bir yap\u0131 sunan policy (kural) tabanl\u0131 eri\u015fim kontrol sistemi olan Advanced Authorization Services<\/em> sistemini teorik olarak ele alacak ve edinece\u011fimiz fark\u0131ndal\u0131k \u00fczerine Asp.NET Core’da pratiksel deneyimlerde bulunaca\u011f\u0131z. O halde, konunun temellerini ad\u0131m ad\u0131m inceleyerek ba\u015flayal\u0131m…<\/p>\n

<\/span>Advanced Authorization Services Nedir?<\/span><\/h4>\n
Keycloak Advanced Authorization Services, uygulamalarda eri\u015fim kontrol\u00fcn\u00fc basit rol kontrol\u00fcnden \u00e7\u0131kar\u0131p dinamik, kural tabanl\u0131 ve ba\u011flama duyarl\u0131 hale getiren geli\u015fmi\u015f bir yetkilendirme sistemidir.<\/p>\n
<\/span>Klasik Yetkilendirme Yakla\u015f\u0131m\u0131ndan Fark\u0131 Nedir?<\/span><\/h5>\n
Klasik yetkilendirme yakla\u015f\u0131m\u0131nda kullan\u0131c\u0131 sisteme giri\u015f yapt\u0131ktan sonra yaln\u0131zca token i\u00e7indeki rol\u00fcne bak\u0131larak karar verilir… Buna \u00f6rnek vermemiz gerekirse e\u011fer; -kullan\u0131c\u0131 `admin<\/code> ise izin verilsin, user<\/code> ise verilmesin-<\/em> gibi basit kurallar uygulan\u0131r. Ancak bu y\u00f6ntem eri\u015filen verinin ne oldu\u011fu, kime ait oldu\u011fu ya da hangi ko\u015fullarda eri\u015fildi\u011fi gibi kritik detaylar\u0131 dikkate almad\u0131\u011f\u0131 i\u00e7in ger\u00e7ek d\u00fcnya senaryolar\u0131nda yetersiz kalabilmektedir.<\/p>\n`
Buna kar\u015f\u0131l\u0131k Keycloak Advanced Authorization Services, UMA 2.0 temelli yap\u0131s\u0131yla yetkilendirmeyi sadece role ba\u011fl\u0131 olmaktan \u00e7\u0131kar\u0131p, kullan\u0131c\u0131n\u0131n kim oldu\u011fu, hangi kayna\u011fa eri\u015fmek istedi\u011fi, bu kayna\u011f\u0131n kime ait oldu\u011fu ve eri\u015fimin hangi \u015fartlarda ger\u00e7ekle\u015fti\u011fi gibi dinamik fakt\u00f6rleri de\u011ferlendiren policy (kural) tabanl\u0131 bir sisteme d\u00f6n\u00fc\u015ft\u00fcrerek \u00e7ok daha esnek ve g\u00fc\u00e7l\u00fc bir kontrol mekanizmas\u0131 sa\u011flamaktad\u0131r.<\/p>\n
`Advanced Authorization; -kim, hangi kayna\u011fa, hangi \u015fartlarda eri\u015febilir?-<\/em> sorununa policy (kural) ile \u00e7\u00f6z\u00fcm getirmektedir.<\/em><\/p><\/blockquote>\n`
<\/span>Sistemin 4 Temel Par\u00e7as\u0131<\/span><\/h4>\nKeycloak’un Advanced Authorization yap\u0131s\u0131nda yetkilendirme; korunan varl\u0131klar\u0131 temsil eden resource<\/em>, bu varl\u0131klar \u00fczerinde yap\u0131labilecek i\u015flemleri belirleyen scope<\/em>, eri\u015fim karar\u0131n\u0131 veren kurallar\u0131 i\u00e7eren policy<\/em> ve t\u00fcm bunlar\u0131n birle\u015fimiyle -kim, hangi kayna\u011fa, hangi \u015fartlarda eri\u015febilir?-<\/em> sorusuna cevap veren permission<\/em> bile\u015fenlerinden olu\u015fmaktad\u0131r.<\/p>\n\n\n\n\n\n\nPar\u00e7a<\/th>\n A\u00e7\u0131klama<\/th>\n \u00d6rnek<\/th>\n<\/tr>\n Resource<\/td>\n Korunan varl\u0131kt\u0131r. Yani sistemde eri\u015fimini kontrol etmek istedi\u011fimiz somut “\u015fey”dir. Kullan\u0131c\u0131lar\u0131n g\u00f6rmesini, de\u011fi\u015ftirmesini ya da silmesini s\u0131n\u0131rland\u0131rmak istedi\u011fimiz veri veya varl\u0131kt\u0131r. \u00d6rne\u011fin bir sipari\u015f kayd\u0131, bir dosya ya da bir ayar objesi gibi d\u00fc\u015f\u00fcn\u00fclebilir. Ve Keycloak bu “\u015fey” \u00fczerine kimin ne yapabilece\u011fini belirlemek i\u00e7in onu bir resource olarak tan\u0131mlamaktad\u0131r.<\/td>\n \/orders\/123<\/td>\n<\/tr>\n Scope<\/td>\n Bir kullan\u0131c\u0131n\u0131n tan\u0131mlanan resource \u00fczerinde tam olarak ne yapabilece\u011fini ifade eden yetki tipidir. Yani mesele sadece -eri\u015febilir mi?-<\/em> de\u011fil, -eri\u015fince ne yapabilir?-<\/em> sorusudur! Bu da read<\/em>, write<\/em>, delete<\/em> ve approve<\/em> gibi aksiyonlarla belirlenmektedir. B\u00f6ylece ayn\u0131 kayna\u011fa farkl\u0131 kullan\u0131c\u0131lar farkl\u0131 seviyelerde yetkiyle eri\u015febilir.<\/td>\n read, write<\/td>\n<\/tr>\n Policy<\/td>\n Bir kullan\u0131c\u0131n\u0131n belirli bir resource \u00fczerinde tan\u0131mlanan scope’u kullan\u0131p kullanamayaca\u011f\u0131n\u0131 belirleyen karar\/kural mekanizmas\u0131d\u0131r. Sistemin as\u0131l “akl\u0131” burada \u00e7al\u0131\u015fmaktad\u0131r ve kullan\u0131c\u0131 rol\u00fc, kayna\u011f\u0131n sahibi olup olmad\u0131\u011f\u0131, kullan\u0131c\u0131ya ait \u00f6zellikler ve zaman gibi fakt\u00f6rlere bakarak eri\u015fime izin verir ya da reddeder. Hatta istenirse \u00f6zel kod yaz\u0131larak bu karar tamamen ihtiyaca g\u00f6re \u015fekillendirilebilir.<\/td>\n admin ise izin ver<\/td>\n<\/tr>\n Permission<\/td>\n Resource, scope ve policy’nin bir araya gelerek olu\u015fturdu\u011fu nihai karar yap\u0131s\u0131d\u0131r. Sistemin -bu kullan\u0131c\u0131, \u015fu kayna\u011fa, \u015fu i\u015flemi yapabilir mi?-<\/em> sorusuna verdi\u011fi kesin cevapt\u0131r ve esas\u0131nda tek ba\u015f\u0131na bir \u015fey de\u011fildir! Bu \u00fc\u00e7 bile\u015fenin birle\u015fimiyle olu\u015fan ve eri\u015fime izin verilip verilmeyece\u011fini belirleyen nihai noktad\u0131r.<\/td>\n admin \u2192 \/orders read<\/td>\n<\/tr>\n<\/table>\n<\/span>UMA 2.0 Nedir? Ne Getirmektedir?<\/span><\/h4>\nUMA 2.0 (User-Managed Access 2.0), klasik rol tabanl\u0131 yetkilendirmeden \u00e7ok daha esnek ve kullan\u0131c\u0131 odakl\u0131 bir eri\u015fim kontrol standard\u0131d\u0131r. Temel fikir olarak; kaynak (resource) sahiplerinin, kendi kaynaklar\u0131na kimin hangi ko\u015fullarda eri\u015febilece\u011fini merkezi bir sistem \u00fczerinden y\u00f6netebilmesidir. B\u00f6ylece art\u0131k yetkiyi sadece admin<\/em>, user<\/em> gibi statik rollere de\u011fil, dinamik kurallara ve ko\u015fullara ba\u011fl\u0131 olarak vermeyi sa\u011flamaktad\u0131r.<\/p>\n UMA 2.0 ile gelen temel yenilikler \u015funlard\u0131r:<\/p>\n \nKullan\u0131c\u0131 Kontrol\u00fc<\/em><\/strong> \nKaynak sahibi, kendi verisine kimlerin eri\u015febilece\u011fini y\u00f6netebilir.\n<\/li>\n Ko\u015ful Tabanl\u0131 Eri\u015fim<\/em><\/strong> \nSaat, IP, cihaz, kullan\u0131c\u0131 ge\u00e7mi\u015fi vs. gibi parametreler izin karar\u0131na dahil edilebilir.\n<\/li>\n Merkezi Yetkilendirme<\/em><\/strong> \nAPI veya uygulama client’lar\u0131, merkezi bir izin sunucusuna (Keycloak gibi) eri\u015fim izni sorarak davran\u0131\u015flar\u0131n\u0131 \u015fekillendirebilir.\n<\/li>\n Dinamik Token (RPT \u2013 Requesting Party Token)<\/em><\/strong> \nEri\u015fim iste\u011fi s\u0131ras\u0131nda politika ve kurallar de\u011ferlendirilir, sonucu belirten \u00f6zel token olu\u015fturulur.\n<\/li>\n \u00c7oklu Sistem Entegrasyonu<\/em><\/strong> \nKullan\u0131c\u0131 yahut kaynak bilgisi farkl\u0131 sistemlerde gelebilir. UMA bu tarz heterojen ortamlara da uyum sa\u011flayabilir.\n<\/li>\n<\/ul>\nK\u0131saca UMA 2.0; -kim, neye, ne zaman, hangi ko\u015fullarda eri\u015febilir?-<\/em> sorular\u0131n\u0131 dinamik ve merkezi olarak y\u00f6netebilmemizi sa\u011flayan ve \u00f6zellikle \u00e7ok kullan\u0131c\u0131l\u0131, \u00e7ok sistemli ve hassas veri ortamlar\u0131nda kritik bir esneklik ve g\u00fcvenlik sa\u011flayan bir standartt\u0131r.<\/p>\n <\/span>Nas\u0131l \u00c7al\u0131\u015fmaktad\u0131r?<\/span><\/h4>\n<\/a>UMA 2.0’\u0131n ak\u0131\u015f mant\u0131\u011f\u0131 yukar\u0131daki g\u00f6rselde oldu\u011fu gibi cereyan etmektedir:<\/p>\n \n\u0130stek<\/em>: Client, API’ye istek atar.<\/li>\n Soru<\/em>: API, Keycloak’a -bu kullan\u0131c\u0131 bu resource’a eri\u015febilir mi?-<\/em> diye sorar.<\/li>\n Policy Kontrol<\/em>: Keycloak, policy’leri \u00e7al\u0131\u015ft\u0131r\u0131r ve karar \u00fcretir.<\/li>\nSonu\u00e7<\/em>: Nihai olarak eri\u015fimi izin verilir yahut engellenir.<\/li>\n<\/ol>\nTabi bu \u015fema client bazl\u0131 mant\u0131\u011f\u0131 yans\u0131tmaktad\u0131r. Bir yandan kullan\u0131c\u0131 bazl\u0131 mant\u0131\u011f\u0131 da ele al\u0131rsak;<\/a>\u015feklinde bir ak\u0131\u015f d\u00fc\u015f\u00fcnebiliriz. Burada s\u00fcreci g\u00f6zlemlersek;<\/p>\n \nKullan\u0131c\u0131 login olup, access token al\u0131r.<\/li>\n Ard\u0131ndan API’ye gidip -ben bu resource’a eri\u015fmek istiyorum-<\/em> der.<\/li>\nKeycloak gerekli kontrolleri sa\u011flar ve izin var m\u0131 yok mu de\u011ferlendirir. E\u011fer izin yoksa permission ticket \u00fcretir, varsa da ticket’a gerek kalmaks\u0131z\u0131n RPT \u00fcretilir.\n\nPermission Ticket Nedir?<\/strong><\/em> \nBu ticket, -bu kullan\u0131c\u0131 \u015fu resource’a eri\u015fmek istiyor-<\/em> bilgisini ta\u015f\u0131yan ge\u00e7ici bir izin talebi belgesidir. Keycloak, bu ticket ile client tekrar geldi\u011fi taktirde izin s\u00fcrecini ba\u015flatmaktad\u0131r.<\/p>\nBurada -izin yoksa direkt reddet ge\u00e7-<\/em> mant\u0131\u011f\u0131nda bir davran\u0131\u015f bekleyebilirsiniz. Ancak UMA 2.0’\u0131n amac\u0131 klasik sistemlerden farkl\u0131 olarak reddetmek odakl\u0131 de\u011fil, izin s\u00fcrecini y\u00f6netmek odakl\u0131d\u0131r. Klasik sistemlerde izin yoksa e\u011fer 403 status code’uyla s\u00fcre\u00e7 sonland\u0131r\u0131l\u0131r. Ancak UMA 2.0’da izin olmasa dahi belki al\u0131nabilece\u011fi d\u00fc\u015f\u00fcn\u00fcld\u00fc\u011f\u00fc i\u00e7in s\u00fcre\u00e7 ba\u015flat\u0131l\u0131r. Nas\u0131l belki al\u0131nabilir hoca la…<\/strong><\/em> diye sorarsan\u0131z, d\u00fc\u015f\u00fcn\u00fcn… Kaynak sahibi belki izin verecektir, belki de eri\u015fimi admin onaylayacakt\u0131r ya da sistem ko\u015fullara g\u00f6re izni sa\u011flayacakt\u0131r. Haliyle bu \u015fekilde opsiyonel olan bir s\u00fcreci de\u011ferlendirmek, evet, ad\u0131 \u00fczerinden bir s\u00fcre\u00e7 ba\u015flatmay\u0131 gerektirmektedir. Bunu da yukar\u0131da s\u00f6ylendi\u011fi gibi permission ticket ile ger\u00e7ekle\u015ftirmekteyiz.<\/p>\n Tabi permission ticket davran\u0131\u015f\u0131;<\/p>\n\nkullan\u0131c\u0131lar aras\u0131 veri payla\u015f\u0131m\u0131 s\u00fcre\u00e7lerinde,<\/li>\n dosya \/ belge sistemlerinde,<\/li>\n sosyal platformlarda,<\/li>\n AI agent’lar\u0131n kullan\u0131c\u0131lar ad\u0131na i\u015flem yapt\u0131\u011f\u0131 s\u00fcre\u00e7lerde,<\/li>\n ve dinamik izin ak\u0131\u015flar\u0131nda<\/li>\n<\/ul>\nolduk\u00e7a mant\u0131kl\u0131d\u0131r.<\/p>\n Bunlar\u0131n d\u0131\u015f\u0131nda tabi ki de basit CRUD API’lerinde yahut sadece admin veya user gibi basit ayr\u0131mlar\u0131n ve statik rollerin oldu\u011fu sistemlerde kullan\u0131m\u0131 olduk\u00e7a gereksizdir!\n<\/p><\/div>\n<\/li>\n Client, \u00fcretilen permission ticket ile tekrar Keycloak’a gider.<\/li>\nKeycloak, policy’leri \u00e7al\u0131\u015ft\u0131r\u0131r ve uygunsa RPT \u00fcretir.\n\nRPT (Requesting Party Token) Nedir?<\/strong><\/em> \nRPT, UMA 2.0 kapsam\u0131nda \u00fcretilen, kullan\u0131c\u0131n\u0131n belirli bir resource’a hangi izinlerle eri\u015febilece\u011fini g\u00f6steren \u00f6zel bir access token’d\u0131r. Yani -bu kullan\u0131c\u0131 \u015funlar\u0131 yapabilir-<\/em> bilgisini ta\u015f\u0131yan token’d\u0131r. Ama dikkat edin ki bir access token de\u011fildir! Access token ile RPT evet… birbirlerine benzemektedirler, ikisi de JWT’dir, evet… ikisi de Keycloak taraf\u0131ndan \u00fcretilir, evet… her ikisi de request s\u00fcre\u00e7lerinde authorization header’\u0131 \u00fczerinden API’lere g\u00f6nderilir… Ancak bilinmelidir ki farkl\u0131d\u0131rlar \ud83d\ude42 Access token’\u0131n amac\u0131 kimlikken (authentication), RPT’nin yetkidir (authorization). Access token, -ben kimim-<\/em> sorusuna cevap verirken, RPT ise -ne yapabilirim-<\/em> sorusuna cevap vermektedir. Haliyle bir \u00e7al\u0131\u015fmada access token olmaks\u0131z\u0131n RPT al\u0131nmas\u0131 m\u00fcmk\u00fcn de\u011fildir!\n<\/div>\n<\/li>\n<\/ol>\n<\/span>UMA 2.0’\u0131 Kullan\u0131rken Nelere Dikkat Etmek Gerekmektedir?<\/span><\/h4>\nUMA 2.0 do\u011fru kullan\u0131lmad\u0131\u011f\u0131 taktirde a\u015f\u0131r\u0131 karma\u015f\u0131k bir canavara d\u00f6n\u00fc\u015febilir. Bu nedenle konuya ili\u015fkin pratik ve net uyar\u0131larla dikkat edilmesi gereken hususlara dair fark\u0131ndal\u0131k olu\u015fturmak \u00f6nem arz etmektedir.<\/p>\n\nUMA 2.0 kullan\u0131lacaksa ger\u00e7ekten gerekli mi sorusu sorulmal\u0131d\u0131r!<\/strong> \nUMA 2.0 kullan\u0131rken en kritik mesele, ger\u00e7ekten buna ihtiya\u00e7 olup olmad\u0131\u011f\u0131n\u0131 do\u011fru de\u011ferlendirmektir. \u00c7\u00fcnk\u00fc basit CRUD i\u015flemleri, klasik admin\/user ayr\u0131m\u0131 veya statik rol yap\u0131lar\u0131 olan bir sistemde UMA gereksiz karma\u015fa ve performans maliyeti getirecektir. Buna kar\u015f\u0131l\u0131k kullan\u0131c\u0131lar aras\u0131 veri payla\u015f\u0131m\u0131, dinamik izin talepleri ve onay s\u00fcre\u00e7leri, AI agent’lar\u0131n\u0131n kontroll\u00fc aksiyon almas\u0131 veya multi-tenant<\/a> ve karma\u015f\u0131k eri\u015fim kurallar\u0131 gibi durumlarda ciddi bir esneklik ve g\u00fc\u00e7 sa\u011flayacakt\u0131r. Bu y\u00fczden yanl\u0131\u015f yerde kullan\u0131ld\u0131\u011f\u0131nda sistemi yava\u015flatan bir y\u00fcke d\u00f6n\u00fc\u015febilme ihtimali s\u00f6z konusudur.\n<\/li>\n Resource tasar\u0131m\u0131 do\u011fru yap\u0131lmal\u0131d\u0131r!<\/strong> \nUMA 2.0 kullan\u0131rken resource<\/code> tasar\u0131m\u0131n\u0131 do\u011fru yapmak kritik \u00f6neme sahiptir. \u00c7\u00fcnk\u00fc, her bir veri kayd\u0131n\u0131 ayr\u0131 bir resource olarak tan\u0131mlamak sistemde kontrol edilmesi gereken nesne say\u0131s\u0131n\u0131 a\u015f\u0131r\u0131 art\u0131raca\u011f\u0131 i\u00e7in ciddi performans problemlerine yol a\u00e7abilir. Bunun yerine benzer varl\u0131klar\u0131 mant\u0131kl\u0131 seviyede gruplayarak daha kaba (coarse-grained) bir yap\u0131 kurmak hem y\u00f6netilebilirli\u011fi art\u0131r\u0131r hem de yetkilendirme s\u00fcre\u00e7lerinin daha h\u0131zl\u0131 ve verimli \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar.\n<\/li>\n Scope’lar minimal tutulmal\u0131d\u0131r!<\/strong> \nScope’lar\u0131 m\u00fcmk\u00fcn oldu\u011funca sade ve az say\u0131da tutmak gerekmektedir. Her aksiyonu ayr\u0131 ayr\u0131 tan\u0131mlamak sistemi gereksiz karma\u015f\u0131k hale getirecek ve y\u00f6netimi zorla\u015ft\u0131racakt\u0131r. Bunun yerine read, write, delete gibi temel aksiyonlarla ilerleyip detayl\u0131 ayr\u0131mlar\u0131 policy taraf\u0131nda \u00e7\u00f6zmek hem daha esnek hem de daha s\u00fcrd\u00fcr\u00fclebilir bir yetkilendirme yap\u0131s\u0131 sa\u011flayacakt\u0131r.\n<\/li>\n Policy’ler sade ve deterministik olmal\u0131d\u0131r!<\/strong> \nKeycloak \u00fczerinde UMA 2.0 kullan\u0131rken policy’leri m\u00fcmk\u00fcn oldu\u011funca sade, k\u00fc\u00e7\u00fck ve deterministik tutmak gerekmektedir. \u00c7\u00fcnk\u00fc t\u00fcm mant\u0131\u011f\u0131 tek bir karma\u015f\u0131k policy i\u00e7inde toplamak, \u00f6zellikle JavaScript tabanl\u0131 kurallar\u0131n, d\u0131\u015f sistem \u00e7a\u011fr\u0131lar\u0131n\u0131n ve i\u00e7 i\u00e7e ge\u00e7mi\u015f \u015fartlar\u0131n oldu\u011fu senaryolar sistemi hem anla\u015f\u0131lmaz hem de zor debug edilebilir hale getirecektir. Bunun yerine her policy’nin tek bir i\u015fi yapt\u0131\u011f\u0131, m\u00fcmk\u00fcn oldu\u011funca token i\u00e7inde claim’lere dayanan ve birbirinden ba\u011f\u0131ms\u0131z \u00e7al\u0131\u015fan bir yap\u0131 kurmak hem performans art\u0131racak hem de yetkilendirme kararlar\u0131n\u0131n \u00f6ng\u00f6r\u00fclebilir ve y\u00f6netilebilir olmas\u0131n\u0131 sa\u011flayacakt\u0131r.\n<\/li>\n Token’\u0131n \u015fi\u015fmesine dikkat edilmelidir!<\/strong> \nUMA 2.0 kullan\u0131rken RPT i\u00e7inde ta\u015f\u0131nan resource ve scope bilgilerinin gereksiz yere \u00e7o\u011falt\u0131lmas\u0131 token’\u0131n boyutunu b\u00fcy\u00fcterek hem a\u011f \u00fczerinden ta\u015f\u0131nan veri miktar\u0131n\u0131 art\u0131r\u0131r hem de her istekte do\u011frulama maliyetini y\u00fckselterek performans\u0131 olumsuz etkiler. Bu y\u00fczden m\u00fcmk\u00fcn oldu\u011funca daha genel (coarse-grained) resource tan\u0131mlar\u0131 yapmak ve sadece ger\u00e7ekten gerekli izinleri token’a dahil etmek sistemin daha h\u0131zl\u0131 ve verimli \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flayacakt\u0131r.\n<\/li>\n Performans \u00f6nemsenmelidir! Hafife al\u0131nmamal\u0131d\u0131r!<\/strong> \nUMA 2.0 kullan\u0131rken performans hafife al\u0131nmamal\u0131d\u0131r. \u00c7\u00fcnk\u00fc bu modelde klasik ak\u0131\u015fa ek olarak access token, permission ticket ve RPT \u00fcretimi gibi ekstra istek-cevap (roundtrip) s\u00fcre\u00e7leri s\u00f6z konusu olacakt\u0131r ve bunlar\u0131n her API \u00e7a\u011fr\u0131s\u0131nda tekrar etmesi sistemi ciddi \u015fekilde yava\u015flatacakt\u0131r. Bu y\u00fczden RPT’yi cache’lemek, her istekte tekrar Keycloak’a gitmemek ve backend taraf\u0131nda k\u0131sa s\u00fcreli \u00f6nbellekleme stratejileri kullanmak performans a\u00e7\u0131s\u0131ndan kritik bir optimizasyondur.\n<\/li>\n Stateless ve Stateful fark\u0131n\u0131 iyi anlamak gerekmektedir!<\/strong> \nUMA 2.0 kullan\u0131rken klasik JWT yap\u0131s\u0131n\u0131n tamamen stateless olmas\u0131na kar\u015f\u0131l\u0131k UMA’n\u0131n permission ticket, policy evaluation ve RPT \u00fcretimi gibi s\u00fcre\u00e7lerle k\u0131smen stateful bir yap\u0131ya ge\u00e7ti\u011fini iyi anlamak gerekmektedir. \u00c7\u00fcnk\u00fc bu durum sistemin davran\u0131\u015f\u0131n\u0131 daha dinamik hale getirirken ayn\u0131 zamanda hata ay\u0131klamay\u0131 zorla\u015ft\u0131racak ve kararlar\u0131n sadece token i\u00e7eri\u011fine de\u011fil, anl\u0131k de\u011ferlendirme s\u00fcre\u00e7lerine de ba\u011fl\u0131 olmas\u0131na neden olacakt\u0131r.\n<\/li>\n Debugging plan\u0131n\u0131n haz\u0131r k\u0131ta olmas\u0131 faydal\u0131 olacakt\u0131r!<\/strong> \nUMA 2.0 kullan\u0131rken en zor konulardan biri -neden izin verilmedi?-<\/em> sorusuna cevap aramakt\u0131r… \u00c7\u00fcnk\u00fc kararlar sadece token’a bak\u0131larak de\u011fil, policy’lerin dinamik olarak \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131yla verilmektedir. Bu y\u00fczden Keycloak \u00fczerinde log’lar\u0131 aktif etmek, policy evaluation ara\u00e7lar\u0131n\u0131 kullanmak ve farkl\u0131 senaryolar\u0131 test edebilece\u011fin \u00f6rnek kullan\u0131c\u0131lar olu\u015fturmak, hatalar\u0131 h\u0131zl\u0131 te\u015fhis edebilmek ve sistemin nas\u0131l karar verdi\u011fini anlayabilmek a\u00e7\u0131s\u0131ndan kritik \u00f6neme sahiptir.\n<\/li>\n Client’a g\u00fcvenilmemeli, t\u00fcm yetkilendirme kontrolleri backend taraf\u0131ndan do\u011frulanmal\u0131d\u0131r!<\/strong> \nUMA 2.0 kullan\u0131rken en kritik g\u00fcvenlik noktalar\u0131ndan biri client’a asla g\u00fcvenilmemesi ve t\u00fcm yetkilendirme kontrollerinin backend taraf\u0131nda do\u011frulanmas\u0131 gereklili\u011fidir. \u00d6zellikle RPT i\u00e7indeki izinlerin ger\u00e7ekten ge\u00e7erli olup olmad\u0131\u011f\u0131n\u0131 sunucu taraf\u0131nda kontrol etmek ve yaln\u0131zca token’\u0131n varl\u0131\u011f\u0131na de\u011fil, i\u00e7indeki scope’lar\u0131n ilgili i\u015flem i\u00e7in uygun olup olmad\u0131\u011f\u0131na bakmak gerekmektedir! Aksi taktirde client manip\u00fclasyonlar\u0131 veya eksik kontroller ciddi g\u00fcvenlik a\u00e7\u0131klar\u0131na sebebiyet verebilir.\n<\/li>\n<\/ul>\n<\/span>13 Kritik Soru \/ 13 Kritik Cevap<\/span><\/h4>\n\u015eimdi konuyu daha iyi anlayabilmek ve duvar k\u00f6\u015felerindeki k\u0131r\u0131nt\u0131lara kadar sindirebilmek i\u00e7in akla gelen gelmeyen t\u00fcm sorular\u0131 burada masaya yat\u0131r\u0131p cevapland\u0131rmaya \u00e7al\u0131\u015fal\u0131m:<\/p>\n\n Permission Explosion nedir?<\/em><\/strong> \nPermission Explosion (\u0130zin Patlamas\u0131), Keycloak gibi sistemlerde her kullan\u0131c\u0131, her resource ve her i\u015flem i\u00e7in ayr\u0131 ayr\u0131 izin tan\u0131mland\u0131\u011f\u0131nda ortaya \u00e7\u0131kan kontrols\u00fcz b\u00fcy\u00fcme problemidir. Bu durumda permission say\u0131s\u0131 katlanarak artar, sistem y\u00f6netilemez hale gelir, performans d\u00fc\u015fer ve token’lar \u015fi\u015fer. Bu y\u00fczden do\u011fru yakla\u015f\u0131m her ihtimal i\u00e7in ayr\u0131 izin \u00fcretmek yerine daha genel resource ve scope’lar tan\u0131mlay\u0131p eri\u015fim karar\u0131n\u0131 dinamik policy’lerle vermektir.\n<\/div>\n\nSoru 1 | UMA 2.0 ve normal access token aras\u0131ndaki fark nedir?<\/span><\/summary>\nK\u0131saca ifade etmek gerekirse, UMA 2.0 kapsam\u0131nda access token ve RPT birbirini tamamlayan iki farkl\u0131 roldedir diyebiliriz. Access token, kullan\u0131c\u0131n\u0131n kim oldu\u011funu kan\u0131tlar, yani sisteme -ben \u015fu kullan\u0131c\u0131y\u0131m-<\/em> diyerek bir kimlik do\u011frulama sa\u011flar. Ancak kimli\u011fin do\u011frulanmas\u0131 tek ba\u015f\u0131na bir kayna\u011fa eri\u015fim izni vermeyece\u011finden yetkilendirme s\u00fcre\u00e7lerinde yeterli de\u011fildir. Kullan\u0131c\u0131, belirli bir resource’a eri\u015fmek isterse, sistem bu talebi ayr\u0131ca de\u011ferlendirir ve uygun g\u00f6r\u00fcrse RPT \u00fcretir. RPT, art\u0131k kullan\u0131c\u0131n\u0131n hangi kayna\u011fa, hangi i\u015flemlerle eri\u015febilece\u011fini a\u00e7\u0131k\u00e7a belirten yetkiyi temsil eder. Bu y\u00fczden ak\u0131\u015fta \u00f6nce access token al\u0131n\u0131r, ard\u0131ndan gerekirse RPT \u00fcretilir ve b\u00f6ylece ger\u00e7ek yetkilendirme karar\u0131 RPT \u00fczerinden sa\u011flanm\u0131\u015f olur. \n<\/details>\n\nSoru 2 | Permission Ticket neden \u00fcretilir?<\/span><\/summary>\n\u0130zin yoksa neden permission ticket \u00fcretiliyor?<\/em><\/p><\/blockquote>\n UMA 2.0 i\u00e7inde izin yokken permission ticket \u00fcretilmesinin sebebi, iste\u011fi direkt reddetmek yerine bir izin talebi s\u00fcreci ba\u015flatmakt\u0131r. Yani kullan\u0131c\u0131 o anda yetkili olmasa bile sistem bu talebi kay\u0131t alt\u0131na al\u0131r, resource sahibi ya da ilgili policy’ler bu talebi sonradan de\u011ferlendirebilir ve e\u011fer uygun g\u00f6r\u00fcl\u00fcrse kullan\u0131c\u0131 tekrar geldi\u011finde RPT alarak eri\u015fim kazanabilir. B\u00f6ylece sistem statik izin yoksa s\u00fcreci 403 ile sonland\u0131r<\/em> yakla\u015f\u0131m\u0131 yerine daha dinamik ve y\u00f6netilebilir bir yetkilendirme ak\u0131\u015f\u0131 sunmu\u015f olur.<\/p>\n<\/details>\n\nSoru 3 | Resource ve Scope kavramlar\u0131 nas\u0131l tasarlanmal\u0131d\u0131r?<\/span><\/summary>\nResource scope tasar\u0131m\u0131 m\u00fcmk\u00fcn mertebe sade ve dengeli olmal\u0131d\u0131r. Resource’lar her bir veri kayd\u0131n\u0131 tek tek temsil edecek kadar detayl\u0131 de\u011fil, mant\u0131kl\u0131 gruplar halinde tan\u0131mlanmal\u0131, scope’lar ise gereksiz \u00e7e\u015fitlili\u011fe ka\u00e7madan read<\/em>, write<\/em>, delete<\/em> gibi temel aksiyonlarla s\u0131n\u0131rland\u0131r\u0131lmal\u0131d\u0131r. \u00c7\u00fcnk\u00fc bu yakla\u015f\u0131m, hem token’lar\u0131n \u015fi\u015fmesini engeller hem de policy’lerin daha anla\u015f\u0131l\u0131r, y\u00f6netilebilir ve performansl\u0131 \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flar. \n<\/details>\n \nSoru 4 | Policy olu\u015ftururken nelere dikkat etmeliyiz?<\/span><\/summary>\nPolicy tasarlarken kurallar\u0131n m\u00fcmk\u00fcn oldu\u011funca basit, deterministik ve tek bir amaca odakl\u0131 olmas\u0131 tavsiye edilmektedir. Her policy tek bir i\u015fi \u00e7\u00f6zmeli, m\u00fcmk\u00fcnse token i\u00e7inde claim’ler \u00fczerinden \u00e7al\u0131\u015fmal\u0131 ve karma\u015f\u0131k i\u015flemlerden m\u00fcmk\u00fcn mertebe ka\u00e7\u0131nmal\u0131d\u0131r. Yani anlayaca\u011f\u0131n\u0131z klasik yaz\u0131l\u0131msal ilkelerdeki hassasiyet, policy’lerde de ge\u00e7erlili\u011fini korumaktad\u0131r. \n<\/details>\n \nSoru 5 | UMA’y\u0131 hangi durumlarda kullanmak mant\u0131kl\u0131d\u0131r?<\/span><\/summary>\nUMA 2.0 \u00f6zellikle kullan\u0131c\u0131lar aras\u0131 veri payla\u015f\u0131m\u0131n\u0131n oldu\u011fu ve izinlerin statik rollerle de\u011fil dinamik s\u00fcre\u00e7lerle belirlendi\u011fi durumlarda daha anlaml\u0131d\u0131r. \u00d6rne\u011fin, bir kullan\u0131c\u0131n\u0131n kendi dosyas\u0131n\u0131 ba\u015fkalar\u0131yla payla\u015fabilmesi, eri\u015fim talebinde bulunulup sonradan onay verilmesi veya yetkilerin ge\u00e7ici olarak devredilmesi gibi senaryolarda UMA ciddi bir esneklik sa\u011flamakta, ancak admin\/user<\/em> gibi basit ayr\u0131mlar\u0131n yeterli oldu\u011fu sistmelerde gereksiz karma\u015f\u0131kl\u0131\u011fa sebebiyet vermektedir. \n<\/details>\n \nSoru 6 | Her request’te yetkilendirmeyle ilgili durumu Keycloak’a m\u0131 soraca\u011f\u0131m?<\/span><\/summary>\nHay\u0131r, bu sistemi \u00f6ld\u00fcr\u00fcr. UMA’da al\u0131nan RPT cache’lenmeli ve m\u00fcmk\u00fcn oldu\u011funca backend taraf\u0131nda do\u011frulanmal\u0131d\u0131r. Aksi halde her istekte ekstra roundtrip performans darbo\u011faz\u0131 ka\u00e7\u0131n\u0131lmazd\u0131r! \n<\/details>\n \nSoru 7 | RPT’yi do\u011frulamazsak ne olur?<\/span><\/summary>\nSistem \u00e7\u00f6ker \ud83d\ude42 \u00c7\u00fcnk\u00fc direkt client taraf\u0131na g\u00fcvenilmi\u015f olunur. Bu y\u00fczden RPT mutlaka backend taraf\u0131nda validate edilmeli ve i\u00e7indeki permission’lar ger\u00e7ekten kontrol edilmelidir. \n<\/details>\n \nSoru 8 | Permission Explosion (\u0130zin Patlamas\u0131) nas\u0131l \u00f6nlenir?<\/span><\/summary>\nHer resource + scope kombinasyonunu ayr\u0131 ayr\u0131 \u00fcretirseniz sistem \u00e7\u00f6ker. Bunun yerine genelle\u015ftirilmi\u015f resource’lar + dinamik policy’ler kullan\u0131lmal\u0131d\u0131r. Tabi bu durumun pratik d\u00fczlemde daha net anla\u015f\u0131laca\u011f\u0131 a\u015fikard\u0131r \ud83d\ude09 \n<\/details>\n \nSoru 9 | UMA ger\u00e7ekten gerekli mi, yoksa overengineering mi?<\/span><\/summary>\nE\u011fer sistemde kullan\u0131c\u0131lar aras\u0131 etkile\u015fim yoksa ve izinler statikse y\u00fcksek ihtimal overengineering yap\u0131lmaktad\u0131r. UMA 2.0 ancak dinamik yetki ak\u0131\u015f\u0131 olan senaryolar i\u00e7in anlaml\u0131d\u0131r. \n<\/details>\n \nSoru 10 | Authorization ile business logic s\u0131n\u0131r\u0131 nerede ba\u015flamal\u0131, nerede bitmelidir?<\/span><\/summary>\nEn kritik ayr\u0131mlardan birisi de budur diyebiliriz. Keycloak sadece -eri\u015febilir mi?-<\/em> sorusunu cevaplamal\u0131d\u0131r… -Ne yapmal\u0131?-<\/em> sorusu ise uygulama logic’inde kalmal\u0131d\u0131r… Aksi taktirde t\u00fcm i\u015f kurallar\u0131 Keycloak’a g\u00f6m\u00fcl\u00fcrse sistem kontrol edilemez hale gelecektir. \n<\/details>\n \nSoru 11 | Eventual consistency problemi ya\u015fan\u0131l\u0131r m\u0131?<\/span><\/summary>\nMuhtemelen… \u00c7\u00fcnk\u00fc token (\u00f6zellikle RPT) \u00fcretildikten sonra i\u00e7indeki izinler bir s\u00fcre ge\u00e7erli kalacakt\u0131r. Bu y\u00fczden bir kullan\u0131c\u0131dan izin kald\u0131r\u0131lsa bile eski token ile bir s\u00fcre eri\u015fim devam edecektir. Bunu \u00e7\u00f6zmek i\u00e7in token \u00f6mr\u00fc k\u0131sa tutulmal\u0131 ve re-check mekanizmas\u0131 kurulmal\u0131d\u0131r. \n<\/details>\n \nSoru 12 | Revocation (izin geri alma) nas\u0131l y\u00f6netilir?<\/span><\/summary>\nUMA’da bu kritik bir problemdir. \u0130zin geri al\u0131nd\u0131\u011f\u0131nda eski RPT’ler hala ge\u00e7erli olabilir, bu y\u00fczden ya token s\u00fcresi k\u0131sa tutulmal\u0131 ya da kritik i\u015flemlerde backend taraf\u0131nda ekstradan kontroller sa\u011flanmal\u0131d\u0131r. \n<\/details>\n \nSoru 13 | Policy de\u011fi\u015firse mevcut RPT’ler ne olacak?<\/span><\/summary>\nAsl\u0131nda bunu \u00f6nceki sorularda cevapland\u0131rm\u0131\u015f bulunuyoruz… RPT, verilmi\u015f bir izne kar\u015f\u0131l\u0131k gelmektedir. Haliyle policy de\u011fi\u015fse bile token s\u00fcresi dolana kadar ge\u00e7erlili\u011fini koruyacakt\u0131r. Bu y\u00fczden s\u00fcrekli vurgulad\u0131\u011f\u0131m\u0131z gibi k\u0131sa \u00f6m\u00fcrl\u00fc token kullanman\u0131n yan\u0131nda gerekti\u011fi noktalarda token invalidation uygulanmas\u0131 da gerekmektedir. \n<\/details>\n <\/p>\n <\/span>Keycloak + Asp.NET Core \u2192 Policy-Based Authorization<\/span><\/h4>\nEvet… Art\u0131k konuya dair pratik dokunu\u015flara ge\u00e7ebiliriz. Tabi ilk olarak Keycloak e\u015fli\u011finde Asp.NET Core’da Policy-Based Authorization<\/a>‘\u0131 ele alal\u0131m istiyorum. Bunun nedeni, Asp.NET Core’daki politika yap\u0131lanmas\u0131n\u0131n statik veya yar\u0131-dinamik kontroller e\u015fli\u011finde yetkilendirme davran\u0131\u015f\u0131n\u0131 sa\u011fl\u0131yor olu\u015fudur. Bu yakla\u015f\u0131mda, token’dan gelen bilgilerle belirli davran\u0131\u015fsal \u015fartlar kontrol edilerek endpoint’lere eri\u015fim s\u0131n\u0131rland\u0131rmalar\u0131 getirilebilmektedir. \u015e\u00f6yle ki; application-client<\/code> ad\u0131nda Direct access grants<\/em> ak\u0131\u015f\u0131n\u0131 destekleyen bir client’\u0131m\u0131z olsun. Bu client’tan al\u0131nan token ile a\u015fa\u011f\u0131daki gibi bir politika tabanl\u0131 kontrol sa\u011flanabilir.<\/p>\n \n\r\nvar builder = WebApplication.CreateBuilder(args);\r\n\r\nbuilder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)\r\n .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>\r\n {\r\n options.Authority = "http:\/\/127.0.0.1:8080\/realms\/master";\r\n options.Audience = "account";\r\n options.RequireHttpsMetadata = false;\r\n\r\n options.Events = new JwtBearerEvents\r\n {\r\n OnTokenValidated = context =>\r\n {\r\n var identity = (ClaimsIdentity)context.Principal!.Identity!;\r\n var realmAccess = context.Principal.FindFirst("realm_access")?.Value;\r\n\r\n if (realmAccess != null)\r\n {\r\n var doc = JsonDocument.Parse(realmAccess);\r\n if (doc.RootElement.TryGetProperty("roles", out var roles))\r\n foreach (var role in roles.EnumerateArray())\r\n identity.AddClaim(new Claim(ClaimTypes.Role, role.GetString()!));\r\n }\r\n\r\n return Task.CompletedTask;\r\n }\r\n };\r\n\r\n options.TokenValidationParameters = new Microsoft.IdentityModel.Tokens.TokenValidationParameters\r\n {\r\n RoleClaimType = ClaimTypes.Role,\r\n NameClaimType = ClaimTypes.Name\r\n };\r\n });\r\n\r\nbuilder.Services.AddAuthorization(options =>\r\n{\r\n options.AddPolicy("AdminOnly", policy =>\r\n {\r\n policy.RequireAuthenticatedUser()\r\n .RequireClaim(ClaimTypes.Role, "admin");\r\n });\r\n});\r\n.\r\n.\r\n.\r\n<\/pre>\n<\/div>\n<\/a>Tabi burada, 36 ile 43. sat\u0131r aral\u0131\u011f\u0131nda olu\u015fturulan politika gere\u011fi payload’daki realm_access<\/code> alan\u0131ndaki rollerin de\u011ferlendirilmesi gerekmektedir. Ancak, mimaride bir obje i\u00e7erisindeki dizin i\u00e7inde arama yapacak k\u0131sa yol olmad\u0131\u011f\u0131 i\u00e7in 12 ile 27. sat\u0131r aral\u0131\u011f\u0131nda ilgili alandaki roller elde edilerek identity’e ClaimTypes.Role<\/code> type’\u0131 kar\u015f\u0131l\u0131\u011f\u0131nda verilmektedir, ki AdminOnly<\/code> politikas\u0131nda, istek g\u00f6nderen kullan\u0131c\u0131n\u0131n admin<\/code> rol\u00fcne sahip olup olmad\u0131\u011f\u0131 de\u011ferlendirilebilsin.<\/p>\n Burada ekstradan 12 ile 27. sat\u0131r aral\u0131\u011f\u0131ndaki claim ay\u0131klama i\u015flemini a\u015fa\u011f\u0131daki gibi harici bir transformation s\u0131n\u0131f\u0131nda y\u00fcr\u00fctebilir ve b\u00f6ylece daha temiz bir \u00e7al\u0131\u015fma ger\u00e7ekle\u015ftirebiliriz.<\/p>\n \n\r\n public class KeycloakRolesTransformer : IClaimsTransformation\r\n {\r\n public Task<ClaimsPrincipal> TransformAsync(ClaimsPrincipal principal)\r\n {\r\n var identity = (ClaimsIdentity)principal.Identity!;\r\n var realmAccess = identity.FindFirst("realm_access");\r\n\r\n if (realmAccess is not null)\r\n {\r\n var json = JsonDocument.Parse(realmAccess.Value);\r\n if (json.RootElement.TryGetProperty("roles", out var roles))\r\n foreach (var role in roles.EnumerateArray())\r\n {\r\n var r = role.GetString();\r\n if (!string.IsNullOrEmpty(r))\r\n identity.AddClaim(new Claim(ClaimTypes.Role, r));\r\n }\r\n }\r\n\r\n return Task.FromResult(principal);\r\n }\r\n }\r\n<\/pre>\n<\/div>\n\n\r\nbuilder.Services.AddScoped<IClaimsTransformation, KeycloakRolesTransformer>();\r\n<\/pre>\n<\/div>\n\u0130\u015fte bu kadar…<\/p>\n <\/span>Keycloak + Asp.NET Core \u2192 Resource-Based Authorization (RBA)<\/span><\/h4>\n\u015eimdi de esas konumuz olan UMA 2.0’\u0131n davran\u0131\u015f\u0131na daha yak\u0131n olan Resource-Based Authorization’\u0131 tecr\u00fcbe edelim. Tabi \u00f6ncelikle ne oldu\u011funu izah edelim…<\/p>\n Resource-Based Authorization Nedir?<\/strong> \nResource-Based Authorization’\u0131n ne oldu\u011funu anlayabilmek i\u00e7in \u00f6ncelikle normal authorization yap\u0131lanmas\u0131n\u0131 anlamland\u0131rmam\u0131z gerekmektedir. Malumunuz, normal authorization -bu user admin mi?-<\/em> \u015feklinde soru sorar ve evet\/hay\u0131r mant\u0131\u011f\u0131nda davran\u0131\u015f sergiler. Resource-Based Authorization’da ise sorunun mahiyeti biraz de\u011fi\u015fecektir ve -bu user bu spesifik kayna\u011fa (resource) eri\u015febilir mi?-<\/em> formuna b\u00fcr\u00fcnecektir. Bu kaynak kullan\u0131c\u0131n\u0131n kendi olu\u015fturdu\u011fu postu ya da sipari\u015fi olabilir. Yani anlayaca\u011f\u0131n\u0131z, eri\u015filmesi gereken resource bazl\u0131 bir ko\u015ful ortaya koyulmas\u0131 gereken senaryolarda bu yakla\u015f\u0131m olduk\u00e7a idealdir.<\/p>\n \u015eimdi bu mant\u0131kta bir authorization \u00e7al\u0131\u015fmas\u0131 i\u00e7in a\u015fa\u011f\u0131daki gibi yap\u0131lar\u0131n tan\u0131mlanmas\u0131 gerekmektedir:<\/p>\n \nRequirement olu\u015fturulmal\u0131d\u0131r<\/em> \nBu sa\u011flanmas\u0131 beklenen ko\u015fulu temsil eden bir s\u0131n\u0131ft\u0131r. Ya da bir ba\u015fka deyi\u015fle kural\u0131n ad\u0131d\u0131r. Teknik olarak IAuthorizationRequirement<\/code> interface’inden implemente edilmesi gerekmektedir.<\/p>\n\n\r\n public class EditPostRequirement : IAuthorizationRequirement\r\n {\r\n }\r\n<\/pre>\n<\/div>\nBu s\u0131n\u0131f\u0131n i\u00e7eri\u011finin dolu olmas\u0131 elzem de\u011fildir. Zahiren bak\u0131ld\u0131\u011f\u0131 zaman bir kullan\u0131c\u0131n\u0131n post edit’leyebilmesi i\u00e7in sa\u011flamas\u0131 gereken \u015fart\u0131 ifade etti\u011fi g\u00f6r\u00fclmektedir. Ki unutulmamal\u0131d\u0131r ki requirement s\u0131n\u0131flar\u0131nda hi\u00e7bir logic bulunmamaktad\u0131r!<\/p>\n As\u0131l i\u015f handler s\u0131n\u0131f\u0131ndad\u0131r…\n<\/li>\n Handler olu\u015fturulmal\u0131d\u0131r<\/em> \nHandler, bir requirement’\u0131n ger\u00e7ekten sa\u011flan\u0131p sa\u011flanmad\u0131\u011f\u0131n\u0131 kontrol eden karar mekanizmas\u0131d\u0131r. AuthorizationHandler<TRequirement, TResource><\/code> abstract class’\u0131ndan implemente edilmesi gerekmektedir.<\/p>\n\n\r\n public class EditPostHandler : AuthorizationHandler<EditPostRequirement, Post>\r\n {\r\n protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, EditPostRequirement requirement, Post resource)\r\n {\r\n \/\/ClaimTypes.NameIdentifier : sub\r\n if (resource.OwnerId.ToString() == context.User.FindFirst(ClaimTypes.NameIdentifier)?.Value)\r\n context.Succeed(requirement);\r\n\r\n return Task.CompletedTask;\r\n }\r\n }\r\n<\/pre>\n<\/div>\nBurada g\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere, resource olan Post’un editlenme s\u00fcrecinde ilgili kullan\u0131c\u0131ya ait olup olmad\u0131\u011f\u0131 EditPostRequirement<\/code>‘\u0131n \u00f6zelinde de\u011ferlendirilmektedir.\n<\/li>\n IoC Container’a eklenmelidir<\/em> \nHandler s\u0131n\u0131f\u0131n\u0131n i\u015flevsel olabilmesi i\u00e7in IoC Container’a eklenmesi gerekmektedir.<\/p>\n\n\r\nbuilder.Services.AddScoped<IAuthorizationHandler, EditPostHandler>();\r\n<\/pre>\n<\/div>\n<\/li>\nVe gereken noktada kullan\u0131lmal\u0131d\u0131r<\/em> \nResource-Based Authorization, \u00e7o\u011funlukla ne Authorize<\/code> attribute’u ile ne de RequireAuthorization<\/code> metodu ile de\u011fil \u00e7o\u011funlukla kod i\u00e7erisinde (imperative) kontrol sa\u011flamaktad\u0131r.<\/p>\n\u015e\u00f6yle ki; Authorize<\/code> ve RequireAuthorization<\/code> yap\u0131lar\u0131, request bazl\u0131 \u00e7al\u0131\u015fmakta ve sadece User \u00fczerinden karar vermektedirler. Haliyle resource nedir bilmezler. Resource-Based Authorization’da ise hem user hem resource birlikte de\u011ferlendirilmekte ve kontrol runtime’da, veri \u00e7ekildikten sonra ger\u00e7ekle\u015ftirilmektedir. Bu y\u00fczden genelde<\/p>\n \n await _authorizationService.AuthorizeAsync(User, resource, requirement); \n<\/strong>\n<\/div>\n\u015feklinde kullan\u0131lmaktad\u0131r. Dolay\u0131s\u0131yla a\u015fa\u011f\u0131daki gibi bir kullan\u0131m durumu s\u00f6z konusu olacakt\u0131r:<\/p>\n \n\r\napp.MapPut("\/post-edit", async (IAuthorizationService authorizationService, HttpContext httpContext) =>\r\n{\r\n Post post = new()\r\n {\r\n OwnerId = new Guid("af3787e6-1c79-4ba4-a935-442851a4c529")\r\n };\r\n\r\n var result = await authorizationService.AuthorizeAsync(httpContext.User, post, new EditPostRequirement());\r\n\r\n if (!result.Succeeded)\r\n return Results.Forbid();\r\n\r\n return Results.Ok();\r\n});\r\n<\/pre>\n<\/div>\nAma burada kritik bir nokta var. O da Authorize<\/code> ve RequireAuthorization<\/code> yap\u0131lar\u0131n\u0131n yine de g\u00f6zden ka\u00e7\u0131r\u0131lmamas\u0131, yani kullan\u0131lmas\u0131 gereklili\u011fidir. Bu yap\u0131lar, kullan\u0131c\u0131n\u0131n login olup olmad\u0131\u011f\u0131n\u0131 garanti eder. B\u00f6ylece zaten token’\u0131 olmayan bir kullan\u0131c\u0131n\u0131n endpoint’e eri\u015fememesi sa\u011flanarak ideal davran\u0131\u015f g\u00f6sterilmi\u015f olur. Ha kimli\u011fi do\u011frulanm\u0131\u015f kullan\u0131c\u0131n\u0131n bu kayna\u011fa eri\u015fip eri\u015fmeyece\u011fi ise art\u0131k bu kontrol\u00fcn tekelindedir…\n<\/li>\n<\/ul>\n Evet… Resource-Based Authorization’da bundan ibarettir…<\/p>\n <\/span>Keycloak + Asp.NET Core \u2192 UMA 2.0<\/span><\/h4>\nArt\u0131k nihai olarak esas konumuzla pratik y\u00fczle\u015fmeye geldik diyebiliriz…<\/p>\n Yukar\u0131daki Resource-Based Authorization yakla\u015f\u0131m\u0131nda kimin hangi kayna\u011fa eri\u015fece\u011fi belirlenmektedir. Bunu yaparken, kurallar kodda ya da policy’de olacak \u015fekilde backend’de tan\u0131mlama ger\u00e7ekle\u015ftirdik. Yani t\u00fcm kontrol tamamen yaz\u0131lan authorization logic’te tutulmaktad\u0131r.<\/p>\n UMA 2.0’da ise kaynak sahibi, kimin neye eri\u015febilece\u011fine kendisi karar verecektir. Bunda ise yetkiyi uygulama de\u011fil, resource owner y\u00f6netecektir. Haliyle dinamik olarak yetki de\u011fi\u015fikli\u011fi ve kontrol\u00fc sa\u011flanabilir.<\/p>\n \n\n Resource-Based Authorization<\/strong><\/p>\n\n\nBu kullan\u0131c\u0131 bu document’in owner’\u0131 m\u0131?<\/li>\n Bu user bu resource’a ait mi?<\/li>\n Bu token’a sahip ki\u015fi, \u015fu scope’lara eri\u015febilir.<\/li>\n<\/ul>\n<\/div>\ncoarse-grained, yani daha az detay, daha genel bir yakla\u015f\u0131m…<\/div>\n<\/p><\/div>\n\n UMA 2.0<\/strong><\/p>\n\n\nAhmet bu dosyay\u0131 g\u00f6rebilir.<\/li>\n Mehmet sadece okuyabilir.<\/li>\n \u015euayip, Hilmi’nin “123” numaral\u0131 faturas\u0131na (resource’una\/kayna\u011f\u0131na) okuma<\/u> yapabilsin mi?<\/li>\n<\/ul>\n<\/div>\nfine-grained, yani daha fazla detay, daha hassas yakla\u015f\u0131m…<\/div>\n<\/p><\/div>\n<\/div>\nOAuth 2.0’da karar\u0131 sunucu verirken, UMA’da ise kaynak sahibi verir, Keycloak ise bu karar\u0131 uygular.<\/em><\/p><\/blockquote>\n \u015eimdi UMA 2.0’\u0131 uygulayabilmek i\u00e7in ad\u0131m ad\u0131m hem Keycloak’da hem de uygulama taraf\u0131nda hassas \u00e7al\u0131\u015fmalar ger\u00e7ekle\u015ftirmemiz gerekmektedir. Bu yetkilendirme yakla\u015f\u0131m\u0131n\u0131 tam olarak kurgulayabilmek i\u00e7in burada yapaca\u011f\u0131m\u0131z yap\u0131land\u0131rmalar olduk\u00e7a \u00f6nem arz etmektedir.<\/p>\n Tabi bu yap\u0131land\u0131rmalara ge\u00e7meden \u00f6nce UMA’n\u0131n getirdi\u011fi konseptteki terminolik kavramlar\u0131 masaya yat\u0131rmakta fayda g\u00f6rmekteyim;<\/p>\n\n\n\n\n\nKavram<\/th>\n A\u00e7\u0131klama<\/th>\n<\/tr>\n Resource Owner<\/td>\n Kayna\u011f\u0131n sahibi (\u00f6rn: Hilmi, kendi faturalar\u0131n\u0131n sahibi)<\/td>\n<\/tr>\n Resource Server (RS)<\/td>\n API’nin kendisi \u2014 kaynaklar\u0131 koruyan sunucu<\/td>\n<\/tr>\n Authorization Server (AS)<\/td>\n Keycloak \u2014 kimin neye eri\u015febilece\u011fine karar veren<\/td>\n<\/tr>\n<\/table>\nBunlar\u0131n yan\u0131nda UMA’y\u0131 uygularken her ad\u0131mda kar\u015f\u0131m\u0131za \u00e7\u0131kabilecek \u00fc\u00e7 token yap\u0131s\u0131n\u0131 da tekrar \u00f6zetleyip notumuzu alal\u0131m;<\/p>\n\n\n\n\n\nToken<\/th>\n A\u00e7\u0131klama<\/th>\n<\/tr>\n PAT (Protection API Token)<\/td>\n \n\nResource Server’\u0131n (API’nin) Keycloak’a -ben buyum-<\/em> demek i\u00e7in kulland\u0131\u011f\u0131 token’d\u0131r.<\/li>\n API, Keycloak’a resource kaydetmek i\u00e7in bu token’\u0131 kullanmaktad\u0131r.<\/li>\n Client Credentials grant<\/a> ile al\u0131n\u0131r (kullan\u0131c\u0131 yok, makine-makine)<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n Permission Ticket<\/td>\n \n\n-Bu kayna\u011fa eri\u015fmek istiyorum-<\/em> talebinin makbuzudur.<\/li>\n RS (API), client’a -git Keycloak’tan bununla izin al-<\/em> der.<\/li>\n Tek kullan\u0131ml\u0131kd\u0131r, k\u0131sa \u00f6m\u00fcrl\u00fcd\u00fcr.<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n RPT (Requesting Party Token)<\/td>\n \n\nPermission Ticket’\u0131 Keycloak’a g\u00f6t\u00fcr\u00fcnce al\u0131nan as\u0131l yetki token’\u0131d\u0131r.<\/li>\n \u0130\u00e7inde hangi kayna\u011fa hangi scope ile eri\u015filebildi\u011fi yazmaktad\u0131r.<\/li>\n API bunu do\u011frular ve eri\u015fime izin verir ya da vermez.<\/li>\n<\/ul>\n<\/td>\n<\/tr>\n<\/table>\nHadi ba\u015flayal\u0131m…<\/p>\n \nAd\u0131m 1<\/strong> (Resource Server Client Olu\u015fturma)<\/em> \n\u0130lk olarak Asp.NET Core uygulamam\u0131z i\u00e7in Keycloak’da bir kimlik edas\u0131nda client olu\u015fturaca\u011f\u0131z. Keycloak bu client \u00fczerinden kaynak ve izin tan\u0131mlar\u0131n\u0131 tutacakt\u0131r.<\/a>Olu\u015fturulacak bu client’\u0131n ayarlar\u0131 a\u015fa\u011f\u0131daki gibi olacakt\u0131r;<\/a>Buradaki yap\u0131land\u0131rmalardan bahsetmemiz gerekirse e\u011fer;<\/p>\n\nClient authentication<\/a><\/strong>: Bu a\u00e7\u0131k oldu\u011fu s\u00fcrece client Keycloak’a kendini tan\u0131tmak mecburiyetindedir. Client ID ve Client Secret de\u011ferlerini \u00fcretir. Haliyle bir confidential client<\/a> \u00fcretecektir.<\/li>\n Authorization<\/strong>: Bu ayar, Keycloak’da Authorization Services’\u0131n kapsam\u0131nda olan policy, permission vs. gibi \u00f6zellikleri a\u00e7maktad\u0131r. UMA 2.0 i\u00e7in \u015fart bir yap\u0131land\u0131rmad\u0131r!<\/li>\n Standard flow<\/strong>: Authorization Code Flow<\/a>‘u sa\u011flar. <\/li>\n Direct access grants<\/strong>: Resource Owner Password Credentials<\/a>‘\u0131 sa\u011flar.<\/li>\n<\/ul>\nSonra a\u015fa\u011f\u0131daki yap\u0131land\u0131rmalarla client olu\u015fturulmal\u0131d\u0131r.<\/p>\n \nRoot URL: https:\/\/localhost:7086 \nHome URL: https:\/\/localhost:7086 \nValid redirect URIs: https:\/\/localhost:7086\/* \nWeb origins: \n<\/div>\n<\/li>\n Ad\u0131m 2<\/strong> (Authorization Ayarlar\u0131n\u0131 Yap\u0131land\u0131rma)<\/em> \n\u015eimdi de olu\u015fturdu\u011fumuz client’\u0131n authorization ayarlar\u0131n\u0131 yap\u0131land\u0131raca\u011f\u0131z. Yani bir ba\u015fka deyi\u015fle, sadece kimlik do\u011frulama (login) de\u011fil, ayn\u0131 zamanda kullan\u0131c\u0131n\u0131n neye eri\u015febilece\u011finin sorusunu da y\u00f6netiyor olaca\u011f\u0131z.<\/p>\nBunun i\u00e7in olu\u015fturdu\u011fumuz client’\u0131n detaylar\u0131ndan ‘Authorization’ sekmesine gelelim ve a\u015fa\u011f\u0131daki gibi yap\u0131land\u0131rmada bulunal\u0131m;<\/a><\/p>\n \nPolicy enforcement mode (Politika Uygulama Modu)<\/strong>: Bu ayar politika uygulama modunu ayarlamam\u0131z\u0131 sa\u011flamaktad\u0131r. G\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere \u00fc\u00e7 se\u00e7enekten olu\u015fmaktad\u0131r;\n\nEnforcing (Zorlay\u0131c\u0131)<\/u>: En g\u00fcvenli moddur. Policy yoksa yahut var olan policy \u015fartlar\u0131 sa\u011flanmad\u0131ysa eri\u015fim reddedilecektir.<\/li>\n Permissive (Esnek)<\/u>: E\u011fer bu eri\u015fimi kontrol eden hi\u00e7bir policy yoksa varsay\u0131lan olarak izin verecektir. Ancak policy var ve a\u00e7\u0131k\u00e7a \u015fartlar\u0131 sa\u011flanm\u0131yorsa o taktirde eri\u015fim engellenecektir.<\/li>\n Disabled (Kapal\u0131)<\/u>: Authorization’\u0131 tamamen devre d\u0131\u015f\u0131 b\u0131rakacakt\u0131r. Keycloak sadece login yapacakt\u0131r ancak yetki kontrol\u00fc yapmayacakt\u0131r.<\/li>\n<\/ul>\n<\/li>\nDecision strategy (Karar Stratejisi)<\/strong>: Birden fazla policy’nin s\u00f6z konusu oldu\u011fu senaryolarda son karar\u0131n nas\u0131l verilece\u011fini belirleyen stratejiyi yap\u0131land\u0131rmaktad\u0131r.\n\nUnanimous (Oybirli\u011fi)<\/u>: T\u00fcm policy’lerin \u015fartlar\u0131 sa\u011flan\u0131rsa eri\u015fim olacakt\u0131r. Aralar\u0131ndan bir tane bile ‘deny’ varsa eri\u015fim reddedilecektir.<\/li>\n Affirmative (\u00c7o\u011funluk\/En az biri yeter)<\/u>: En az bir policy izin verirse eri\u015fim sa\u011flanacakt\u0131r. Di\u011ferleri reddetse bile izin \u00e7\u0131kabilir. Esnek senaryolarda ge\u00e7erlidir.<\/li>\n<\/ul>\n<\/li>\n Remote resource management<\/strong>: Bu yap\u0131land\u0131rma a\u00e7\u0131k oldu\u011fu s\u00fcrece uygulama (API vs.) Keycloak’a ba\u011flant\u0131 sa\u011flayarak resource’lar\u0131, policy’leri ve permission’lar\u0131 dinamik olarak y\u00f6netebilecektir.<\/li>\n<\/ul>\n<\/li>\nAd\u0131m 3<\/strong> (Scope Tan\u0131mlama)<\/em> \nUMA’da scope kavram\u0131, bir kaynak \u00fczerinde yap\u0131labilecek i\u015flem t\u00fcr\u00fcn\u00fc ifade etmektedir.<\/p>\n<\/p>\n \n UMA 2.0’daki Scope vs Client Scope\n <\/div>\n \nUMA 2.0’daki scope, authorization scope’dur. User-Managed Access (UMA) i\u00e7inde kullan\u0131lan bir kavramd\u0131r. Bir kaynak \u00fczerinde yap\u0131labilecek aksiyonu temsil etmektedir ve -bu kullan\u0131c\u0131 bu kayna\u011f\u0131 ne yapabilir?-<\/em> sorusunu cevaplar…<\/p>\nClient scope ise Keycloak i\u00e7inde OAuth\/OIDC taraf\u0131na aittir ve token i\u00e7ine hangi bilgilerin (claim’lerin) eklenece\u011fini belirlemektedir.<\/p>\n UMA Scope \u2192 yetki \nClient Scope \u2192 veri\n <\/p><\/div>\n<\/div>\n Haliyle bizler yine ilgili client’\u0131n ‘Authorization’ \u2192 ‘Scopes’ kombinasyonuna gelerek a\u015fa\u011f\u0131daki gibi scope’lar\u0131 olu\u015ftural\u0131m:<\/a>\n<\/li>\n Ad\u0131m 4<\/strong> (Resource Tan\u0131mlama)<\/em> \n\u015eimdi de Asp.NET Core uygulamam\u0131zda hangi kayna\u011f\u0131 koruma alt\u0131na almak istiyorsak onu resource olarak tan\u0131mlayaca\u011f\u0131z. Bunun i\u00e7in ‘Authorization’ \u2192 ‘Resources’ kombinasyonuna gelerek a\u015fa\u011f\u0131daki gibi bir resource tasarlayal\u0131m:<\/a>Buradaki yap\u0131land\u0131rmaya bakarsan\u0131z Asp.NET Core’daki \/api\/documents\/{id}<\/code> endpoint’i ile bu resource’u e\u015fle\u015ftirerek, Keycloak’a hangi kayna\u011f\u0131 korumas\u0131 gerekti\u011fini ifade etmi\u015f oluyoruz. Ayr\u0131ca ‘Authorization scopes<\/em> alan\u0131nda g\u00f6r\u00fcld\u00fc\u011f\u00fc gibi olu\u015fturdu\u011fumuz scope’lar\u0131 bu resource’la ili\u015fkilendirerek yetkisel davran\u0131\u015flar\u0131 da belirlemi\u015f oluyoruz.<\/p>\nBurada ayr\u0131ca ‘Type’ alan\u0131ndaki garip urn:uma-resource-server:resources:document<\/code> de\u011ferine dikkatinizi \u00e7ekmek istiyorum. Bu format, g\u00f6z\u00fcn\u00fcz\u00fc korkutmas\u0131n… di\u011fer resource’larla bir \u00e7ak\u0131\u015fma olmamas\u0131 i\u00e7in bu \u015fekilde bir format benimsenmektedir. \u00d6zellikle farkl\u0131 ekiplerin s\u00f6z konusu oldu\u011fu microservice mimarilerde resource’lar\u0131n \u00e7ak\u0131\u015fmas\u0131 \u00e7ok tecr\u00fcbe edildi\u011fi i\u00e7in bu tarz bir isimlendirme tercih edilmektedir.<\/p>\n ‘User-Managed Access enabled’ alan\u0131 ise resource sahibinin (user) eri\u015fim kararlar\u0131na do\u011frudan dahil olaca\u011f\u0131n\u0131 belirlemektedir. Yani yetkiyi kullan\u0131c\u0131 y\u00f6netmektedir.\n<\/li>\n Ad\u0131m 5<\/strong> (Role & User Policy’leri Tan\u0131mlama)<\/em> \nEvet… Art\u0131k s\u0131ra bir policy tan\u0131malaya gelmi\u015ftir. Policy, -kim eri\u015febilir?-<\/em> sorusunun cevab\u0131d\u0131r… Bunun i\u00e7in de ‘Authorization’ \u2192 ‘Policies’ sekmesine gelinmesi gerekmektedir.<\/p>\nPolicy, a\u015fa\u011f\u0131daki gibi birka\u00e7 t\u00fcr\u00fc olan bir yap\u0131ya sahiptir:<\/p>\n\n\n\n\n\n\n\n\n\n\n\nPolicy T\u00fcr\u00fc<\/th>\n A\u00e7\u0131klama<\/th>\n Ne Zaman Kullan\u0131l\u0131r?<\/th>\n<\/tr>\n<\/thead>\n Client<\/td>\n Belirli bir uygulaman\u0131n (client) eri\u015fmesine izin verir. Ya da bir ba\u015fka deyi\u015fle, belirli bir client \u00fczerinden gelen taleplere izin verir.<\/td>\n Sadece belirli servisler\/API\u2019ler eri\u015febilsin istiyorsan<\/td>\n<\/tr>\n Client Scope<\/td>\n Token i\u00e7indeki client scope\u2019a g\u00f6re eri\u015fim verir.<\/td>\n Token\u2019da belirli scope varsa izin ver senaryosu<\/td>\n<\/tr>\n Group<\/td>\n Kullan\u0131c\u0131n\u0131n ait oldu\u011fu gruba g\u00f6re karar verir.<\/td>\n Departman \/ organizasyon bazl\u0131 yetkilendirme<\/td>\n<\/tr>\n Regex<\/td>\n Belirli bir pattern (regex) e\u015fle\u015firse izin verir.<\/td>\n Dinamik veya string bazl\u0131 kurallar gerekti\u011finde<\/td>\n<\/tr>\n Role<\/td>\n Kullan\u0131c\u0131n\u0131n rol\u00fcne g\u00f6re eri\u015fim kontrol\u00fc yapar.<\/td>\n En yayg\u0131n: admin, user, manager gibi roller<\/td>\n<\/tr>\n Time<\/td>\n Belirli zaman aral\u0131klar\u0131nda eri\u015fime izin verir.<\/td>\n Mesai saatleri, kampanya s\u00fcresi vb.<\/td>\n<\/tr>\n User<\/td>\n Belirli kullan\u0131c\u0131(lar)a \u00f6zel eri\u015fim verir.<\/td>\n Spesifik ki\u015filere izin vermek istedi\u011finde<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nBiz burada Role-Based ve User-Based olmak \u00fczere iki policy uygulayaca\u011f\u0131z. Haliyle ilk olarak Role-Based policy’le ba\u015flayal\u0131m…<\/p>\n Role-Based Policy;<\/em> \n<\/a>Burada dikkat edilirse bu politikaya uygun kullan\u0131c\u0131lar\u0131n sadece ‘user’ rol\u00fcne sahip olup olmamas\u0131 yeterli g\u00f6r\u00fclmektedir. (Tabi \u00f6nceden Realm roles sekmesinden ‘user’ rol\u00fcn\u00fcn olu\u015fturulmu\u015f olmas\u0131 gerekmektedir.) Burada Fetch Roles<\/strong>, kullan\u0131c\u0131n\u0131n alt (inherited) rollerinin de hesaba kat\u0131l\u0131p kat\u0131lmamas\u0131n\u0131 yap\u0131land\u0131rmaktad\u0131r. Yani bu yap\u0131land\u0131rma kapal\u0131 kald\u0131\u011f\u0131 taktirde sadece direkt atanm\u0131\u015f roller kontrol edilecektir. A\u00e7\u0131l\u0131rsa e\u011fer composite (i\u00e7 i\u00e7e) roller de dahil edilecek ve b\u00f6ylece rol hiyerar\u015fisi de \u00f6nem kazanm\u0131\u015f olacakt\u0131r. Logic<\/strong> alan\u0131 ise policy’nin sonucuna g\u00f6re nas\u0131l davran\u0131\u015f sergileyece\u011fini belirlemektedir. Positive<\/em>, \u015fart sa\u011fland\u0131\u011f\u0131 s\u00fcrece eri\u015fime izin verecekken; Negative<\/em> ise \u015fart sa\u011fland\u0131\u011f\u0131 taktirde eri\u015fimi reddedecektir. Negative<\/em>‘i blacklist gibi d\u00fc\u015f\u00fcnebilirsiniz… -\u015fu role sahip olanlar asla giremesin-<\/em> mant\u0131\u011f\u0131nda bir davran\u0131\u015f i\u00e7in tercih edilebilir…<\/p>\n User-Based Policy;<\/em> \n<\/a>Burada da \u00f6rne\u011fimizi zenginle\u015ftirmek i\u00e7in kullan\u0131c\u0131n\u0131n spesifik olarak ‘gncy’ olup olmad\u0131\u011f\u0131n\u0131 de\u011ferlendiren bir politika olu\u015fturuyoruz.<\/a>Evet… Art\u0131k iki adet politikam\u0131z haz\u0131r oldu\u011funa g\u00f6re izinleri tan\u0131mlamaya ge\u00e7ebiliriz.\n<\/li>\n Ad\u0131m 6<\/strong> (Permission Tan\u0131mlama)<\/em> \nPermission, \u00f6nceki ad\u0131mlarda olu\u015fturulan resource, scope ve policy \u00fc\u00e7l\u00fcs\u00fcn\u00fcn birle\u015ftirildi\u011fi noktad\u0131r. Yani; -hangi kaynak i\u00e7in, hangi i\u015flemde, hangi policy ge\u00e7erlidir?-<\/em> sorusunun cevab\u0131n\u0131 verece\u011fimiz nihai noktad\u0131r. Bunun i\u00e7in ‘Authorization’ \u2192 ‘Permissions’ sekmesine gelinmesi gerekmektedir.<\/a>Burada dikkat ederseniz kar\u015f\u0131m\u0131za Resource-Based Permission<\/em> ve Scope-Based Permission<\/em> kavramlar\u0131 \u00e7\u0131kmaktad\u0131r. \u015eimdi gelin bunlar nedir izah ederek devam edelim…<\/p>\n\nResource-Based Permission<\/strong>: Sadece resource’a bakan, scope’u \u00f6nemsemeyen permission t\u00fcr\u00fcd\u00fcr. Mant\u0131\u011f\u0131 salt olarak -bu kayna\u011fa eri\u015fim var m\u0131?-<\/em> \u015feklindedir… Aksiyon ayr\u0131m\u0131 g\u00f6zetilmemektedir. Basit yetkilendirme s\u00fcre\u00e7lerinde tercih edilir.<\/li>\nScope-Based Permission<\/strong>: Resource ile scope birlikte de\u011ferlendirilir. -Bu kayna\u011f\u0131n \u015fu i\u015flemini yapabilir mi?-<\/em> tarz\u0131nda detayl\u0131 yetkilendirme s\u00fcre\u00e7lerinde kullan\u0131l\u0131r. \u00d6rne\u011fin; bir resource’a read<\/em> yap\u0131labiliyor olsun ancak write<\/em> ve delete<\/em> yap\u0131lam\u0131yor olsun. \u0130\u015fte b\u00f6yle aksiyon bazl\u0131 kontrol gereken bir senaryoda scope-based permission’dan istifade edilebilir.<\/li>\n<\/ul>\nResource permission kap\u0131y\u0131 a\u00e7arken, scope permission ise i\u00e7eride ne yap\u0131laca\u011f\u0131n\u0131 belirler…<\/em><\/p><\/blockquote>\n\u015eimdi bizler UMA 2.0’a yak\u0131\u015f\u0131r seviyede scope-based permission olu\u015fturarak devam edelim…<\/a>Burada Document Resource<\/em> kayna\u011f\u0131 \u00fczerinde, read<\/em> aksiyonu (scope) i\u00e7in Has User Role<\/em> politikas\u0131n\u0131n uygulanaca\u011f\u0131 tan\u0131mlanmaktad\u0131r. Tabi bu tan\u0131mda bizler i\u00e7in \u00f6nem arz eden baz\u0131 noktalar mevcuttur; Apply to resource type<\/strong>, bu permission’\u0131n tek bir resource’a m\u0131 uygulanaca\u011f\u0131, yoksa o tipteki t\u00fcm resource’lara m\u0131 uygulanaca\u011f\u0131n\u0131 ifade eden bir yap\u0131land\u0131rmad\u0131r. Kapal\u0131 oldu\u011fu taktirde, olu\u015fturulacak permission sadece se\u00e7ilen resource i\u00e7in ge\u00e7erli olacak, a\u00e7\u0131ld\u0131\u011f\u0131nda ise resource type’a g\u00f6re uygulama sa\u011flanacakt\u0131r. \u00c7ok say\u0131da ayn\u0131 tipten resource’un s\u00f6z konusu oldu\u011fu ve hepsine ayn\u0131 kural\u0131n uygulanaca\u011f\u0131 durumlarda kullan\u0131labilir. Decision Strategy<\/strong> ise birden fazla policy’nin oldu\u011fu durumlarda karar\u0131n nas\u0131l verilece\u011fini yap\u0131land\u0131rmaktad\u0131r.\n<\/li>\n Ad\u0131m 7<\/strong> (Postman Client Olu\u015fturma)<\/em> \nKeycloak kanad\u0131nda \u00e7o\u011fu yap\u0131land\u0131rmalar\u0131m\u0131z\u0131 tamamlam\u0131\u015f bulunuyoruz. S\u0131rada bunlar\u0131 test edebilmek i\u00e7in kullan\u0131c\u0131n\u0131n kullanaca\u011f\u0131 bir client tasarlamam\u0131z gerekmektedir. Tabi bunun i\u00e7in bizler oturup client yazmayacak, bu noktada Postman’den istifade edece\u011fiz. Haliyle Keycloak’da \u015fu konfig\u00fcrasyonlara sahip bir client olu\u015fturmam\u0131z yeterli olacakt\u0131r:<\/p>\n\nClient ID: postman-client \nClient authentication: OFF \u2190 (public client, secret gerekmez) \nStandard flow: ON \nDirect access grants: ON \nValid redirect URIs: https:\/\/oauth.pstmn.io\/v1\/callback\n<\/div>\n<\/li>\n Ad\u0131m 8<\/strong> (Asp.NET Core API Yap\u0131land\u0131rma)<\/em> \nEvet… Art\u0131k Asp.NET Core API k\u0131sm\u0131n\u0131 yap\u0131land\u0131rmaya ge\u00e7ebiliriz. Burada yap\u0131lmas\u0131 gereken temel i\u015flem \u00f6ncelikle konfig\u00fcrasyonel de\u011ferlerin mimariye a\u015fa\u011f\u0131daki gibi ta\u015f\u0131nmas\u0131d\u0131r;<\/p>\n\n\r\n{\r\n .\r\n .\r\n .,\r\n "Keycloak": {\r\n "Authority": "http:\/\/localhost:8080\/realms\/master",\r\n "ClientId": "uma-resource-server-api",\r\n "ClientSecret": "b4NkeoNJk35a9zykXGkJDxMSovyaxuIw",\r\n "TokenEndpoint": "http:\/\/localhost:8080\/realms\/master\/protocol\/openid-connect\/token",\r\n "PermissionEndpoint": "http:\/\/localhost:8080\/realms\/master\/protocol\/openid-connect\/token"\r\n }\r\n}\r\n<\/pre>\n<\/div>\n<\/li>\nAd\u0131m 9<\/strong> (Permission Ticket Alma)<\/em> \nKeycloak’dan permission ticket alabilmek i\u00e7in UmaTokenService<\/code> isimli bir s\u0131n\u0131f olu\u015ftural\u0131m ve i\u00e7eri\u011fine a\u015fa\u011f\u0131daki \u00e7al\u0131\u015fmay\u0131 ekleyelim;<\/p>\n\n\r\n public class UmaTokenService(IHttpClientFactory httpClientFactory, IConfiguration configuration)\r\n {\r\n \/\/Keycloak'a -bu kaynak i\u00e7in izin bileti ver- diyen metottur.\r\n \/\/D\u00f6nen ticket, 401 response i\u00e7inde client'a g\u00f6nderilir.\r\n \/\/Client bu ticket'\u0131 al\u0131p Keycloak'a g\u00f6t\u00fcrerek RPT edinir.\r\n public async Task<string?> GetPermissionTicketAsync(string resourceId, string scope)\r\n {\r\n var httpClient = httpClientFactory.CreateClient();\r\n\r\n \/\/\u00d6nce resource server'\u0131n kendi access token'\u0131n\u0131 al\u0131yoruz.\r\n var resourceServerToken = await GetResourceServerAccessTokenAsync(httpClient);\r\n\r\n httpClient.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", resourceServerToken);\r\n\r\n \/\/UMA Permission Endpoint'ine istek atarak permission ticket al\u0131yoruz.\r\n var permissionEndpoint = $"{configuration["Keycloak:Authority"]}\/authz\/protection\/permission";\r\n var body = new[] {\r\n new {\r\n resource_id = resourceId,\r\n resource_scopes = new[] { scope }\r\n }\r\n };\r\n var response = await httpClient.PostAsJsonAsync(permissionEndpoint, body);\r\n if (!response.IsSuccessStatusCode) return null;\r\n\r\n var result = await response.Content.ReadFromJsonAsync<PermissionTicketResponse>();\r\n return result.Ticket;\r\n\r\n async Task<string?> GetResourceServerAccessTokenAsync(HttpClient httpClient)\r\n {\r\n var formData = new Dictionary<string, string>\r\n {\r\n ["grant_type"] = "client_credentials",\r\n ["client_id"] = configuration["Keycloak:ClientId"]!,\r\n ["client_secret"] = configuration["Keycloak:ClientSecret"]!\r\n };\r\n\r\n var response = await httpClient.PostAsync(configuration["Keycloak:TokenEndpoint"]!, new FormUrlEncodedContent(formData));\r\n var result = await response.Content.ReadFromJsonAsync<TokenResponse>();\r\n\r\n return result?.AccessToken ?? throw new Exception("Resource server token al\u0131namad\u0131!");\r\n }\r\n }\r\n }\r\n<\/pre>\n<\/div>\n<\/li>\nAd\u0131m 10<\/strong> (Permission Ticket’\u0131 RPT’ye D\u00f6n\u00fc\u015ft\u00fcrme)<\/em> \n\u015eimdi de client’\u0131n elde etti\u011fi permission ticket ile Keycloak’dan RPT edinilmesini sa\u011flayacak \u00e7al\u0131\u015fmay\u0131 ekleyelim;<\/p>\n\n\r\n public class UmaTokenService(IHttpClientFactory httpClientFactory, IConfiguration configuration)\r\n {\r\n .\r\n .\r\n .\r\n\r\n public async Task<string?> ExchangeForRptAsync(string userAccessToken, string permissionTicket)\r\n {\r\n var httpClient = httpClientFactory.CreateClient();\r\n var formData = new Dictionary<string, string>\r\n {\r\n ["grant_type"] = "urn:ietf:params:oauth:grant-type:uma-ticket",\r\n ["client_id"] = configuration["Keycloak:ClientId"]!,\r\n ["client_secret"] = configuration["Keycloak:ClientSecret"]!,\r\n ["ticket"] = permissionTicket\r\n };\r\n httpClient.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Bearer", userAccessToken);\r\n var response = await httpClient.PostAsync(configuration["Keycloak:TokenEndpoint"]!, new FormUrlEncodedContent(formData));\r\n\r\n if (!response.IsSuccessStatusCode) return null;\r\n\r\n var result = await response.Content.ReadFromJsonAsync<TokenResponse>();\r\n return result?.AccessToken;\r\n }\r\n }\r\n<\/pre>\n<\/div>\nBurada urn:ietf:params:oauth:grant-type:uma-ticket<\/code> de\u011feri, UMA 2.0 ak\u0131\u015f\u0131n\u0131 ba\u015flatan ve g\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere standart olanlardan farkl\u0131 olan \u00f6zel bir OAuth grant type’\u0131d\u0131r! Bu grant type ile Keycloak, normal bir token de\u011fil, de\u011ferlendirilmi\u015f bir token verece\u011fini anlamaktad\u0131r!<\/p>\n Ayr\u0131ca burada kullan\u0131lan access token’\u0131n kullan\u0131c\u0131 token’\u0131 oldu\u011funa dikkatinizi \u00e7ekerim!\n<\/li>\n Permission Ticket & RPT’yi \u0130ncelelim<\/em> \n\u015eimdi burada araya girerek Keycloak’dan edinece\u011fimiz permission ticket ve RPT’yi incelemekte fayda g\u00f6rmekteyim… Nesini inceleyece\u011fiz?<\/strong><\/em> diye sorarsan\u0131z e\u011fer bunlar\u0131n nas\u0131l yap\u0131ya sahip olduklar\u0131n\u0131 g\u00f6rmemiz yeterli olacakt\u0131r diye d\u00fc\u015f\u00fcn\u00fcyorum.<\/p>\nTabi, geli\u015ftirmemizin bu a\u015famas\u0131nda sizlerin permission ticket ile birlikte RPT’yi edinebilmeniz pek m\u00fcmk\u00fcn de\u011fil. Elbette ki sonraki ad\u0131mlar kapsam\u0131nda yap\u0131lmas\u0131 gereken baz\u0131 hamleler olacakt\u0131r. Lakin ben deniz, bu de\u011ferleri \u00f6ncelikli olarak elde edip yine de sizlere g\u00f6stermek istiyorum.<\/p>\n \u015eimdi bakarsan\u0131z a\u015fa\u011f\u0131da hem permission ticket hem de RPT token’lar\u0131n\u0131 g\u00f6receksiniz;<\/a>Bunlar yap\u0131sal olarak esas\u0131nda birer JWT’dirler. Evet, haliyle jwt.io<\/a>‘dan bunlar\u0131n i\u00e7eri\u011fine g\u00f6z atabiliriz…<\/p>\n\n\n\n\n\n\nPermission Ticket<\/th>\n RPT<\/th>\n<\/tr>\n<\/thead>\n \n\n{ \n “exp”: 1776953939, \n “iat”: 1776953879, \n “permissions”: [ \n { \n “scopes”: [ \n “read” \n ], \n “rsid”: “dbfb5c18-4166-4638-8e84-faff8f5f9126” \n } \n ], \n “jti”: “563a0953-1d31-395f-b88a-8985f8e86ab8-1776953879093”, \n “aud”: “http:\/\/localhost:8080\/realms\/master”, \n “sub”: “37577179-72d9-4fe4-90a6-84debfc17f39”, \n “azp”: “uma-resource-server-api” \n}\n<\/div>\n<\/td>\n \n\n{ \n “exp”: 1776953939, \n “iat”: 1776953879, \n “jti”: “ntrtna:9636c515-dd99-1d94-92ce-92349eec5f18”, \n “iss”: “http:\/\/localhost:8080\/realms\/master”, \n “aud”: “uma-resource-server-api”, \n “sub”: “3fe29fb3-8b9e-4714-996c-ca3c5c589935”, \n “typ”: “Bearer”, \n “azp”: “postman-client”, \n “sid”: “iA_VBjs0yeHZ7WgmFkcb3kES”, \n “acr”: “1”, \n “allowed-origins”: [ \n “” \n ], \n “realm_access”: { \n “roles”: [ \n “create-realm”, \n “default-roles-master”, \n “offline_access”, \n “admin”, \n “uma_authorization”, \n “user” \n ] \n }, \n “resource_access”: { \n “master-realm”: { \n “roles”: [ \n “view-identity-providers”, \n “view-realm”, \n “manage-identity-providers”, \n “impersonation”, \n “create-client”, \n “manage-users”, \n “query-realms”, \n “view-authorization”, \n “query-clients”, \n “query-users”, \n “manage-events”, \n “manage-realm”, \n “view-events”, \n “view-users”, \n “view-clients”, \n “manage-authorization”, \n “manage-clients”, \n “query-groups” \n ] \n }, \n “account”: { \n “roles”: [ \n “manage-account”, \n “manage-account-links”, \n “view-profile” \n ] \n } \n }, \n “authorization”: { \n “permissions”: [ \n { \n “scopes”: [ \n “read” \n ], \n “rsid”: “dbfb5c18-4166-4638-8e84-faff8f5f9126”, \n “rsname”: “Document Resource” \n } \n ] \n }, \n “scope”: “profile email”, \n “email_verified”: false, \n “preferred_username”: “admin” \n}\n<\/div>\n<\/td>\n<\/tr>\n rsid<\/em> kayna\u011f\u0131 i\u00e7in ‘read’ scope’una izin ticket’\u0131 istenmektedir.<\/td>\n E\u011fer politikalar do\u011frultusunda \u015fartlar ge\u00e7erliyse \u00f6zel yetkilendirilmi\u015f RPT olu\u015fturulmaktad\u0131r Dikkat ederseniz authorization.permissions<\/code> alan\u0131nda hangi resource’a hangi yetkinin verildi\u011fi belirtilmektedir.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/li>\nAd\u0131m 11<\/strong> (RPT Validator Olu\u015fturma)<\/em> \n\u00c7al\u0131\u015fmalara devam edersek e\u011fer RPT i\u00e7erisinde gelen authorization.permissions<\/code> alan\u0131n\u0131 okuyarak ger\u00e7ek izinleri kontrol etmemiz gerekmektedir. Bu i\u015flemi de a\u015fa\u011f\u0131daki gibi bir validator ile ger\u00e7ekle\u015ftirece\u011fiz;<\/p>\n\n\r\n public class RptValidator\r\n {\r\n \/\/\/ <summary>\r\n \/\/\/ RPT'nin payload'\u0131n\u0131 decode edip i\u00e7indeki izinlerin istenen kayna\u011fa ve scope'a sahip olup olmad\u0131\u011f\u0131n\u0131 kontrol ediyoruz.\r\n \/\/\/ \r\n \/\/\/ RPT payload \u00f6rne\u011fi : \r\n \/\/\/ \r\n \/\/\/ {\r\n \/\/\/ "authorization": {\r\n \/\/\/ "permissions": [\r\n \/\/\/ {\r\n \/\/\/ "scopes": [\r\n \/\/\/ "read"\r\n \/\/\/ ],\r\n \/\/\/ "rsid": "dbfb5c18-4166-4638-8e84-faff8f5f9126",\r\n \/\/\/ "rsname": "Document Resource"\r\n \/\/\/ }\r\n \/\/\/ ]\r\n \/\/\/ }\r\n \/\/\/ \r\n \/\/\/ \r\n \/\/\/ <\/summary>\r\n public bool HasPermission(string rptToken, string resourceName, string scope)\r\n {\r\n try\r\n {\r\n var jwtSecurityTokenHandler = new JwtSecurityTokenHandler();\r\n var jwt = jwtSecurityTokenHandler.ReadJwtToken(rptToken);\r\n\r\n var authorizationClaim = jwt.Claims.FirstOrDefault(c => c.Type == "authorization")?.Value;\r\n\r\n if (authorizationClaim is null) return false;\r\n\r\n var authData = JsonSerializer.Deserialize<AuthorizationClaim>(authorizationClaim);\r\n\r\n return authData?.Permissions?.Any(p => p.ResourceName == resourceName && (p.Scopes?.Contains(scope) ?? false)) ?? false;\r\n }\r\n catch (Exception)\r\n {\r\n return false;\r\n }\r\n }\r\n }\r\n\r\n\r\n public record AuthorizationClaim(\r\n [property: JsonPropertyName("permissions")] List<PermissionClaim>? Permissions\r\n );\r\n\r\n public record PermissionClaim(\r\n [property: JsonPropertyName("rsid")] string? ResourceId,\r\n [property: JsonPropertyName("rsname")] string? ResourceName,\r\n [property: JsonPropertyName("scopes")] List<string>? Scopes\r\n );\r\n<\/pre>\n<\/div>\n<\/li>\nAd\u0131m 12<\/strong> (UMA Middleware Geli\u015ftirme)<\/em> \n\u015eimdi de her iste\u011fi yakalay\u0131p baz\u0131 durumlar\u0131 kontrol edecek \u00e7al\u0131\u015fmalar ger\u00e7ekle\u015ftirmemiz gerekmektedir… \u015e\u00f6yle ki, gelen istekteki token; normal access token ise permission ticket \u00fcretecek ve 401 d\u00f6nd\u00fcrece\u011fiz, yok e\u011fer RPT ise i\u00e7indeki permission’lar\u0131 do\u011frulayacak ve duruma g\u00f6re eri\u015fime izin verece\u011fiz. \u0130\u015fte bunun i\u00e7in a\u015fa\u011f\u0131daki gibi bir middleware olu\u015fturmam\u0131z tam yerinde olacakt\u0131r;<\/p>\n\n\r\n public class UmaMiddleware(UmaTokenService umaTokenService, RptValidator rptValidator) : IMiddleware\r\n {\r\n public async Task InvokeAsync(HttpContext context, RequestDelegate next)\r\n {\r\n var path = context.Request.Path.Value ?? "";\r\n\r\n \/\/UMA korumas\u0131 alt\u0131ndaki path'leri belirliyoruz. \u00d6rne\u011fin \/documents\/{id} path'i i\u00e7in id'yi al\u0131p o kayna\u011fa eri\u015fim izni olup olmad\u0131\u011f\u0131n\u0131 kontrol edece\u011fiz.\r\n if (!path.StartsWith("\/api\/documents", StringComparison.OrdinalIgnoreCase))\r\n {\r\n await next(context);\r\n return;\r\n }\r\n\r\n var authorization = context.Request.Headers.Authorization.ToString();\r\n\r\n if (string.IsNullOrEmpty(authorization) || !authorization.StartsWith("Bearer "))\r\n {\r\n \/\/Token yok \u2192 UMA ak\u0131\u015f\u0131n\u0131 ba\u015flat\r\n await ReturnPermissionTicket(context, "Document Resource", "read");\r\n return;\r\n }\r\n\r\n var token = authorization["Bearer ".Length..];\r\n\r\n \/\/Token RPT mi kontrol ediyoruz... (authorization code i\u00e7eriyor mu kontrol ediyoruz)\r\n var jwtSecurityTokenHandler = new JwtSecurityTokenHandler();\r\n var jwt = jwtSecurityTokenHandler.ReadJwtToken(token);\r\n if (jwt.Claims.Any(c => c.Type == "authorization"))\r\n {\r\n var requiredScope = GetScopeForMethod(context.Request.Method);\r\n\r\n if (rptValidator.HasPermission(token, "Document Resource", requiredScope))\r\n await next(context);\r\n else\r\n {\r\n context.Response.StatusCode = (int)HttpStatusCode.Forbidden;\r\n await context.Response.WriteAsync("Bu kaynak i\u00e7in yetkiniz bulunmamaktad\u0131r!");\r\n }\r\n }\r\n else\r\n {\r\n \/\/Normal access token ise permission ticket \u00fcretiyor ve 401 d\u00f6n\u00fcyoruz. Client bu ticket'\u0131 al\u0131p Keycloak'tan RPT edinir ve tekrar istekte bulunur.\r\n await ReturnPermissionTicket(context, "Document Resource", GetScopeForMethod(context.Request.Method));\r\n }\r\n\r\n string GetScopeForMethod(string method) => method switch\r\n {\r\n "GET" => "read",\r\n "POST" => "write",\r\n "PUT" => "write",\r\n "DELETE" => "delete",\r\n _ => "read"\r\n };\r\n }\r\n\r\n async Task ReturnPermissionTicket(HttpContext context, string resourceId, string scope)\r\n {\r\n var ticket = await umaTokenService.GetPermissionTicketAsync(resourceId, scope);\r\n\r\n if (ticket is null)\r\n {\r\n context.Response.StatusCode = 500;\r\n return;\r\n }\r\n\r\n context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;\r\n\r\n \/\/WWW-Authenticate header'\u0131nda UMA realm, as_uri ve ticket bilgilerini client'a g\u00f6nderiyoruz. Client bu bilgileri kullanarak Keycloak'tan RPT alacak.\r\n \/\/Bu bir UMA standard\u0131d\u0131r ve client'lar\u0131n 401 response ald\u0131klar\u0131nda ne yapmalar\u0131 gerekti\u011fini anlamalar\u0131n\u0131 sa\u011flar.\r\n context.Response.Headers[HeaderNames.WWWAuthenticate] = $""" UMA realm="master", as_uri="http:\/\/localhost:8080\/realms\/master", ticket="{ticket}" """;\r\n\r\n await context.Response.WriteAsJsonAsync(new\r\n {\r\n error = "uma_redirect",\r\n message = "Permission ticket al\u0131nd\u0131. Bu ticket ile RPT edinin!",\r\n ticket = ticket,\r\n token_endpoint = "http:\/\/localhost:8080\/realms\/master\/protocol\/openid-connect\/token"\r\n });\r\n }\r\n }\r\n<\/pre>\n<\/div>\nBurada dikkat ederseniz gelen istekteki token 14. sat\u0131rda elde edildikten sonra gerekli kontroller sa\u011flanmaktad\u0131r. Sizlere ilgin\u00e7 gelebilecek olan 16 ile 21. sat\u0131r aral\u0131\u011f\u0131ndaki, token’\u0131n olmama durumuna istinaden ba\u015flat\u0131lan UMA ak\u0131\u015f\u0131d\u0131r. \u015eimdi burada la madem token yok neden iste\u011fi reddetmiyoruz!<\/em><\/strong> diye soruyor olabilirsiniz. Ancak hat\u0131rlaman\u0131z\u0131 istiyorum ki UMA’n\u0131n felsefesi iste\u011fi reddetmeden \u00f6nce kullan\u0131c\u0131ya nas\u0131l eri\u015febilece\u011fini s\u00f6ylemesinden ge\u00e7mektedir. Yani burada OAuth 2.0 tarz\u0131, token yoksa e\u011fer 401 status code’u ile istek reddedilsin \u015feklinde bir mant\u0131ktan ziyade; UMA tarz\u0131, token olmasa dahi 401 status code’unda permission ticket ile client’a d\u00f6n\u00fc\u015f yap\u0131ls\u0131n ve bu ticket ile Keycloak’tan RPT al\u0131nmas\u0131 sa\u011flans\u0131n mant\u0131\u011f\u0131nda bir \u00e7al\u0131\u015fma s\u00f6z konusudur. Ha tabi siz yine de token’\u0131n olmad\u0131\u011f\u0131 bir duruma kar\u015f\u0131n isterseniz direkt iste\u011fi reddedebilirsiniz…<\/p>\n 26 ile 39. sat\u0131r aral\u0131\u011f\u0131na g\u00f6z atarsan\u0131z e\u011fer i\u00e7erisinde ‘authorization’ claim’i sorgulanarak mevcut token’\u0131n RPT olup olmad\u0131\u011f\u0131 kontrol edilmektedir. E\u011fer RPT ise gelen iste\u011fin mahiyetine g\u00f6re (GET, POST vs.) uygun scope belirlenip (GetScopeForMethod<\/code>), \u00f6nceki sat\u0131rlarda olu\u015fturdu\u011fumuz Document Resource<\/em>‘a dair b\u00f6yle bir aksiyonun olup olmad\u0131\u011f\u0131 RptValidator<\/code> arac\u0131l\u0131\u011f\u0131yla de\u011ferlendirilmektedir. Yok e\u011fer ilgili token, normal bir access token ise 43. sat\u0131rda ReturnPermissionTicket<\/code> metodu arac\u0131l\u0131\u011f\u0131yla ilgili resource’a uygun scope i\u00e7in permission ticket talep edilmektedir.<\/p>\n T\u00fcm bunlar\u0131n d\u0131\u015f\u0131nda 56 ile 79. sat\u0131r aral\u0131\u011f\u0131nda permission ticket olu\u015fturulmas\u0131n\u0131 sa\u011flayan ReturnPermissionTicket<\/code> metodunun i\u00e7indeki 70. sat\u0131rda bulunan kar\u0131\u015f\u0131k ifadeyi de izah etmemiz gerekirse e\u011fer bu, HTTP standard\u0131ndaki WWW-Authenticate<\/code> header’\u0131n\u0131n UMA versiyonudur. Bu header ile client’a, -bu kayna\u011fa eri\u015febilmek i\u00e7in \u015fu \u015fekilde authenticate olmal\u0131s\u0131n-<\/em> denilmektedir. Yani bir ba\u015fka deyi\u015fle client’a, -git Keycloak’tan UMA ile yetki al-<\/em> demenin resmi HTTP cevab\u0131 bu \u015fekildedir diyebiliriz…<\/p>\n<\/li>\n Ad\u0131m 13<\/strong> (\/api\/documents\/{id}<\/code> Endpoint’ini Geli\u015ftirme)<\/em> \n\u00d6nceki ad\u0131mlarda olu\u015fturdu\u011fumuz resource’un URIs’inde belirtilen path’e kar\u015f\u0131l\u0131k bir endpoint olu\u015ftural\u0131m;<\/p>\n\n\r\napp.MapGet("\/api\/documents\/{id}", (string id) =>\r\n{\r\n \/\/Buraya gelindiyse middleware RPT'yi do\u011frulam\u0131\u015f demektir...\r\n return Results.Ok(new\r\n {\r\n id,\r\n title = "Document",\r\n content = "Bu i\u00e7erik UMA 2.0 ile korunmaktad\u0131r.",\r\n accessedAt = DateTime.UtcNow\r\n });\r\n});\r\n<\/pre>\n<\/div>\n<\/li>\nAd\u0131m 14<\/strong> (Authenticate’i Yap\u0131land\u0131rma ve Temel Ayarlar)<\/em> \n\u015eimdi de temel JWT authentication yap\u0131lanmas\u0131yla birlikte geri kalan gerekli IoC container konfig\u00fcrasyonlar\u0131n\u0131 Program.cs<\/em> dosyas\u0131nda tamamlayal\u0131m;<\/p>\n\n\r\nvar builder = WebApplication.CreateBuilder(args);\r\nbuilder.Services.AddHttpClient();\r\nbuilder.Services.AddSingleton<UmaTokenService>();\r\nbuilder.Services.AddSingleton<RptValidator>();\r\nbuilder.Services.AddSingleton<UmaMiddleware>();\r\n\r\nbuilder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)\r\n .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme, options =>\r\n {\r\n options.Authority = builder.Configuration["Keycloak:Authority"];\r\n options.Audience = builder.Configuration["Keycloak:ClientId"];\r\n options.RequireHttpsMetadata = false;\r\n options.TokenValidationParameters = new()\r\n {\r\n ValidateIssuer = true,\r\n ValidateAudience = false, \/\/UMA'da audience kontrol\u00fc middleware'da yap\u0131lmaktad\u0131r. Burada sadece token'\u0131n Keycloak taraf\u0131ndan imzalan\u0131p imzalanmad\u0131\u011f\u0131 kontrol edilmektedir.\r\n ValidateLifetime = true\r\n };\r\n });\r\n\r\nvar app = builder.Build();\r\napp.UseAuthentication();\r\n\r\napp.UseMiddleware<UmaMiddleware>();\r\n\r\n.\r\n.\r\n.\r\n\r\napp.Run();\r\n<\/pre>\n<\/div>\n<\/li>\nAd\u0131m 15<\/strong> (Test)<\/em> \nEvet… Her \u015fey haz\u0131r… Art\u0131k testimize ge\u00e7ebiliriz. Bunun i\u00e7in Postman \u00fczerinden kullan\u0131c\u0131 ad\u0131na a\u015fa\u011f\u0131daki istek arac\u0131l\u0131\u011f\u0131yla access token talebinde bulunal\u0131m:<\/p>\n\n \ud83d\udd17 POST http:\/\/localhost:8080\/realms\/master\/protocol\/openid-connect\/token \n<\/strong>\n<\/div>\ngrant_type: password \nclient_id: postman-client \nusername: gncy \npassword: 123 \nscope: openid\n<\/div>\nArd\u0131ndan bu access token ile Asp.NET Core API uygulamam\u0131z\u0131n, resource’a uygun \u015fekilde tasarlad\u0131\u011f\u0131m\u0131z endpoint’ine istekte bulunal\u0131m:<\/p>\n \nAuthorization: Bearer ACCESS_TOKEN\n<\/div>\n\n \ud83d\udd17 GET https:\/\/localhost:7086\/api\/documents\/123 \n<\/strong>\n<\/div>\nBu istek s\u00fcrecinde middleware devreye girecek ve ilgili access token’\u0131n RPT olmad\u0131\u011f\u0131n\u0131 anlayarak, Keycloak’tan ilgili kaynak i\u00e7in bir permission ticket isteyecektir. Keycloak, ticket \u00fcretecek ve Asp.NET Core’da bu ticket’\u0131 401 status code’u e\u015fli\u011finde client’a a\u015fa\u011f\u0131daki gibi geri d\u00f6nd\u00fcrm\u00fc\u015f olacakt\u0131r.<\/a>\u015eimdi bu ticket’\u0131 al\u0131p, yine Postman arac\u0131l\u0131\u011f\u0131yla (\u00e7\u00fcnk\u00fc hala client’\u0131m\u0131z o) a\u015fa\u011f\u0131daki adrese yeni bir access token talebinde bulunal\u0131m:<\/p>\n \nAuthorization: Bearer ACCESS_TOKEN\n<\/div>\n\n \ud83d\udd17 POST http:\/\/localhost:8080\/realms\/master\/protocol\/openid-connect\/token \n<\/strong>\n<\/div>\ngrant_type: urn:ietf:params:oauth:grant-type:uma-ticket \nticket: PERMISSION_TICKET\n<\/div>\nE\u011fer ki bu istek neticesinde a\u015fa\u011f\u0131daki access_denied<\/code> hatas\u0131n\u0131 al\u0131yorsan\u0131z, bilin ki politikaya uymayan bir durum s\u00f6z konusudur.<\/a>Ne olabilir?<\/strong> sorusuna kar\u015f\u0131n ilk kontrol edece\u011finiz yer ilgili resource’un politikalar\u0131 olmal\u0131d\u0131r. Hat\u0131rlarsan\u0131z e\u011fer bizler ‘Document Read Permission’<\/em> ad\u0131n\u0131 verdi\u011fimiz permission’da ‘Has User Role’<\/em> politikas\u0131n\u0131 uygulam\u0131\u015ft\u0131k. Haliyle bu politika gere\u011fi ilgili kullan\u0131c\u0131n\u0131n ‘user’ rol\u00fcne sahip olmas\u0131 gerekmektedir. E\u011fer bu hatay\u0131 al\u0131yorsan\u0131z muhtemelen test i\u015fleminde kulland\u0131\u011f\u0131n\u0131z user’da ilgili rol\u00fcn atanmad\u0131\u011f\u0131n\u0131 s\u00f6yleyebiliriz.<\/p>\n E\u011fer her \u015fey yolundaysa, permission ticket ile talep edilen \u00f6zel yetkilendirilmi\u015f access token (RPT) a\u015fa\u011f\u0131daki gibi elde edilecektir:<\/a>Bu a\u015famadan sonra tek yap\u0131lmas\u0131 gereken RPT access token’\u0131 arac\u0131l\u0131\u011f\u0131yla tekrar Asp.NET Core uygulamas\u0131ndaki endpoint’e istekte bulunmakt\u0131r!<\/a>\u0130\u015fte bu kadar… \ud83d\ude42\n<\/li>\n<\/ul>\n <\/span>UMA’y\u0131 Custom Authorization Requirement + Handler Yoluyla Uygulama (En Do\u011fru Yol)<\/span><\/h5>\nYukar\u0131daki \u00e7al\u0131\u015fmada UMA’y\u0131 uygularken permission’daki scope kontrol\u00fcn\u00fc de manuel bir \u015fekilde sa\u011flamaktay\u0131z. Halbuki ideal olan bunu Asp.NET Core’un native yetkilendirme pipeline’\u0131na yans\u0131tabilmek ve orada bir policy mant\u0131\u011f\u0131nda ger\u00e7ekle\u015ftirebilmektir.<\/p>\n Bunun i\u00e7in a\u015fa\u011f\u0131daki gibi custom bir authorization requirement olu\u015fturarak s\u00fcreci daha efektif hale getirebiliriz:<\/p>\n\n\r\n public record UmaPermissionRequirement(string ResourceName, string Scope) : IAuthorizationRequirement;\r\n<\/pre>\n<\/div>\nDevam\u0131nda ise bu requirement’\u0131 a\u015fa\u011f\u0131daki handler ile do\u011frulayabilir ve RPT kontrol\u00fcn\u00fc sa\u011flayabiliriz:<\/p>\n\n\r\n public class UmaPermissionHandler(RptValidator rptValidator) : AuthorizationHandler<UmaPermissionRequirement>\r\n {\r\n protected override Task HandleRequirementAsync(AuthorizationHandlerContext context, UmaPermissionRequirement requirement)\r\n {\r\n if (context.Resource is not HttpContext httpContext)\r\n {\r\n context.Fail();\r\n return Task.CompletedTask;\r\n }\r\n\r\n var authorizationHeader = httpContext.Request.Headers.Authorization.ToString();\r\n\r\n \/\/Hi\u00e7 token yoksa ba\u015far\u0131s\u0131z authorization'\u0131n detaylar\u0131yla birlikte Fail'liyoruz\r\n if (string.IsNullOrEmpty(authorizationHeader) || !authorizationHeader.StartsWith("Bearer "))\r\n {\r\n context.Fail(new AuthorizationFailureReason(this, "no_token"));\r\n return Task.CompletedTask;\r\n }\r\n\r\n var token = httpContext.Request.Headers.Authorization.ToString().Replace("Bearer ", "");\r\n\r\n \/\/E\u011fer token varsa RPT'mi de\u011fil mi kontrol ediyoruz\r\n var jwtSecurityTokenHandler = new JwtSecurityTokenHandler();\r\n var jwt = jwtSecurityTokenHandler.ReadJwtToken(token);\r\n if (!jwt.Claims.Any(c => c.Type == "authorization"))\r\n {\r\n context.Fail(new AuthorizationFailureReason(this, "not_rpt"));\r\n return Task.CompletedTask;\r\n }\r\n\r\n \/\/RPT ise permission'lar\u0131 kontrol ediyoruz.\r\n if (rptValidator.HasPermission(token, requirement.ResourceName, requirement.Scope))\r\n context.Succeed(requirement);\r\n else\r\n context.Fail();\r\n\r\n return Task.CompletedTask;\r\n }\r\n }\r\n<\/pre>\n<\/div>\nDevam\u0131nda ise authorization’\u0131n yaln\u0131zca ba\u015far\u0131s\u0131z oldu\u011fu durumlarda i\u015flem yapacak olan a\u015fa\u011f\u0131daki gibi bir middleware ile de gerekli kontrolleri sa\u011flayabilir ve fail sebebi no_token<\/code> yahut not_rpt<\/code> ise permission ticket alabilir yahut permission_denied<\/code> ise de 403 d\u00f6nd\u00fcrebiliriz:<\/p>\n\n\r\n public class UmaAuthorizationMiddlewareResultHandler(UmaTokenService umaTokenService) : IAuthorizationMiddlewareResultHandler\r\n {\r\n private readonly AuthorizationMiddlewareResultHandler _default = new();\r\n public async Task HandleAsync(RequestDelegate next, HttpContext context, AuthorizationPolicy policy, PolicyAuthorizationResult authorizeResult)\r\n {\r\n \/\/Authorization ba\u015far\u0131l\u0131ysa direkt ge\u00e7iriyoruz\r\n if (authorizeResult.Succeeded)\r\n {\r\n await next(context);\r\n return;\r\n }\r\n\r\n \/\/Hatal\u0131ysa nedenine bak\u0131yoruz\r\n var reason = authorizeResult.AuthorizationFailure?.FailureReasons.FirstOrDefault()?.Message;\r\n\r\n \/\/RPT varsa ama yetersiz permission'sa \u2192 403\r\n if (reason == "permission_denied")\r\n {\r\n context.Response.StatusCode = (int)HttpStatusCode.Forbidden;\r\n await context.Response.WriteAsJsonAsync(new\r\n {\r\n error = "forbidden",\r\n message = "Bu resource i\u00e7in yetkiniz bulunmamaktad\u0131r."\r\n });\r\n return;\r\n }\r\n\r\n \/\/Token yoksa ya da RPT de\u011filse \u2192 401\r\n if (reason is "no_token" or "not_rpt")\r\n {\r\n \/\/Hangi endpoint i\u00e7in ticket isteniyorsa bunu requirement'tan almak i\u00e7in policy'e bak\u0131yoruz\r\n var requirement = policy.Requirements.OfType<UmaPermissionRequirement>().FirstOrDefault();\r\n\r\n if (requirement == null)\r\n {\r\n context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;\r\n return;\r\n }\r\n\r\n var ticket = await umaTokenService.GetPermissionTicketAsync(requirement.ResourceName, requirement.Scope);\r\n\r\n if (ticket == null)\r\n {\r\n context.Response.StatusCode = (int)HttpStatusCode.InternalServerError;\r\n return;\r\n }\r\n\r\n context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;\r\n context.Response.Headers[HeaderNames.WWWAuthenticate] = $""" UMA realm="master", as_uri="http:\/\/localhost:8080\/realms\/master", ticket="{ticket}" """;\r\n\r\n await context.Response.WriteAsJsonAsync(new\r\n {\r\n error = "uma_redirect",\r\n message = "Permission ticket al\u0131nd\u0131. Bu ticket ile RPT edinin!",\r\n ticket = ticket,\r\n token_endpoint = "http:\/\/localhost:8080\/realms\/master\/protocol\/openid-connect\/token"\r\n });\r\n }\r\n\r\n \/\/Token s\u00fcresi dolmas\u0131 vs. gibi di\u011fer durumlar i\u00e7in default davran\u0131\u015f\u0131 devreye al\u0131yoruz\r\n await _default.HandleAsync(next, context, policy, authorizeResult);\r\n }\r\n }\r\n<\/pre>\n<\/div>\nT\u00fcm bu i\u015flemlerden sonra tek yap\u0131lmas\u0131 gereken a\u015fa\u011f\u0131daki gibi pipeline’a uygun bir \u015fekilde scope’lar \u00fczerinden politikalar\u0131n olu\u015fturulmas\u0131 ve endpoint’te kullan\u0131lmas\u0131d\u0131r…<\/p>\n\n\r\nbuilder.Services.AddAuthorization(options =>\r\n{\r\n options.AddPolicy("document:read", policy =>\r\n policy.Requirements.Add(new UmaPermissionRequirement("Document Resource", "read")));\r\n\r\n options.AddPolicy("document:write", policy =>\r\n policy.Requirements.Add(new UmaPermissionRequirement("Document Resource", "write")));\r\n});\r\n<\/pre>\n<\/div>\n\n\r\napp.MapGet("\/api\/documents\/{id}", (string id) =>\r\n{\r\n \/\/Buraya gelindiyse middleware RPT'yi do\u011frulam\u0131\u015f demektir...\r\n return Results.Ok(new\r\n {\r\n id,\r\n title = "Document",\r\n content = "Bu i\u00e7erik UMA 2.0 ile korunmaktad\u0131r.",\r\n accessedAt = DateTime.UtcNow\r\n });\r\n}).RequireAuthorization(policyNames: "document:read");\r\n<\/pre>\n<\/div>\n\u0130\u015fte bu kadar basit… <\/a>UMA 2.0 ak\u0131\u015f\u0131n\u0131n ve RPT’nin davran\u0131\u015fsal olarak g\u00f6rsel \u00f6zeti…<\/p><\/div>Tabi burada, uygulama zemininde dikkat etmenizde fayda g\u00f6rece\u011fim baz\u0131 tecr\u00fcbevi noktalar mevcuttur. Bunlar\u0131 sizler ya\u015fad\u0131k\u00e7a anlayacak ve sindirecek olsan\u0131z da yine hafiften \u00f6nden vurgulamakta fayda g\u00f6r\u00fcyorum…<\/p>\n UMA 2.0 senaryolar\u0131nda, RPT al\u0131m s\u00fcrecinde access_denied<\/code> hatas\u0131 y\u00fcksek olas\u0131d\u0131r. Burada ilk bakaca\u011f\u0131n\u0131z nokta her daim permission’\u0131n policy’lerinin do\u011frulan\u0131p do\u011frulanmad\u0131\u011f\u0131 olmal\u0131d\u0131r. Ayr\u0131ca 401 d\u00f6ng\u00fcs\u00fc de bazen ka\u00e7\u0131n\u0131lmaz olabilmektedir. Burada da kontrol edilen access token i\u00e7erisinde ‘authorization’ claim’i var m\u0131 yok mu taraf\u0131n\u0131zca manuel kontrol edilmelidir. Ha ayr\u0131ca client’\u0131n authorization ayarlar\u0131nda ‘Remote resource management’ yap\u0131land\u0131rmas\u0131n\u0131 aktifle\u015ftirme de unutulmamal\u0131d\u0131r. Bunlara dikkat edildi\u011fi s\u00fcrece di\u011fer ya\u015fanacak hatalar art\u0131k y\u00fcksek ihtimal UMA’n\u0131n d\u0131\u015f\u0131nda ba\u015fka nedenlere dayanmaktad\u0131r \ud83d\ude42<\/p>\n Evet, g\u00f6r\u00fcld\u00fc\u011f\u00fc \u00fczere UMA 2.0 gibi kompleks ve hassas yap\u0131land\u0131rma gerektiren bir ak\u0131\u015f\u0131 a’dan z’ye tam teferruatl\u0131 teorik bir inceleme e\u015fli\u011finde, pratikte de ele alm\u0131\u015f ve siz de\u011ferli okuyucular\u0131m\u0131zla birlikte deneyimlemi\u015f bulunuyoruz.<\/p>\n Nihai olarak; \n\u0130\u00e7erik boyunca, klasik rol bazl\u0131 yetkilendirmenin \u00f6tesine ge\u00e7erek UMA 2.0 standard\u0131n\u0131 temel alan Keycloak Advanced Authorization Services’i teorik ve pratik boyutlar\u0131yla ele alm\u0131\u015f bulunuyoruz. Resource, scope, policy ve permission kavramlar\u0131n\u0131n bir araya geldi\u011fi ve dinamik izin ak\u0131\u015flar\u0131 ile birlikte hassas eri\u015fim kontrolleri gerektiren senaryolarda sundu\u011fu esneklikle \u00f6ne \u00e7\u0131kan bu ak\u0131\u015f\u0131, Asp.NET Core entegrasyonu \u00fczerinden ad\u0131m ad\u0131m, permission ticket ve RPT mekanizmalar\u0131n\u0131n pratikte nas\u0131l i\u015fledi\u011fini deneyimleyerek g\u00f6zler \u00f6n\u00fcne sermi\u015f bulunuyoruz.<\/p>\n Unutulmamal\u0131d\u0131r ki, UMA 2.0 her senaryo i\u00e7in uygun de\u011fildir! Basit yetkilendirme ihtiya\u00e7lar\u0131nda gereksiz karma\u015f\u0131kl\u0131\u011fa yol a\u00e7abilece\u011fi gibi, do\u011fru kullan\u0131ld\u0131\u011f\u0131nda ise merkezi ve dinamik bir yetki y\u00f6netimi imkan\u0131 sunmaktad\u0131r.<\/p>\n \u0130lgilenenlerin faydalanmas\u0131 dile\u011fiyle… \nSonraki yaz\u0131lar\u0131mda g\u00f6r\u00fc\u015fmek \u00fczere… \n\u0130yi \u00e7al\u0131\u015fmalar…<\/p>\n\n\n \n\u00d6rnek \u00e7al\u0131\u015fmaya a\u015fa\u011f\u0131daki GitHub reposundan eri\u015febilirsiniz.<\/div>\nhttps:\/\/github.com\/gncyyldz\/Keycloak.Examples<\/div>\n<\/p><\/div>\n<\/p><\/div>\n\n Bu repository, ilgili konuya dair \u00f6rnek \u00e7al\u0131\u015fman\u0131n kaynak kodlar\u0131n\u0131 ve mimari yap\u0131s\u0131n\u0131 i\u00e7ermektedir. Detaylar i\u00e7in GitHub \u00fczerinden incelemede bulunabilirsiniz.\n <\/div>\n \n GitHub\u2019da G\u00f6r\u00fcnt\u00fcle \u2192 \n <\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":" Merhaba, Bu i\u00e7eri\u011fimizde, UMA 2.0 standard\u0131n\u0131 temel alan; klasik rol bazl\u0131 yetkilendirme mant\u0131\u011f\u0131ndan \u00e7ok daha g\u00fc\u00e7l\u00fc bir yap\u0131 sunan policy (kural) tabanl\u0131 eri\u015fim kontrol sistemi olan Advanced Authorization Services sistemini teorik olarak ele alacak...<\/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":[5701,5699,3145,3055,5710,5706,5705,3054,5707,5711,5709,5703,3835,3146,5708,5715,5713,5702,5714,5700,5712,5704],"class_list":["post-28592","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-net","category-keycloak","tag-advanced-authorization","tag-advanced-authorization-services","tag-authorization-server","tag-iauthorizationrequirement","tag-pat","tag-permission-explosion","tag-permission-ticket","tag-policy-based-authorization","tag-policy-tabanli-yetkilendirme","tag-protection-api-token","tag-rba","tag-requesting-party-token","tag-resource-owner","tag-resource-server","tag-resource-based-authorization","tag-resource-based-permission","tag-role-based-policy","tag-rpt","tag-scope-based-permission","tag-uma-2-0","tag-user-based-policy","tag-user-managed-access-2-0"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28592","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=28592"}],"version-history":[{"count":33,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28592\/revisions"}],"predecessor-version":[{"id":28650,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/posts\/28592\/revisions\/28650"}],"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=28592"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/categories?post=28592"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.gencayyildiz.com\/blog\/wp-json\/wp\/v2\/tags?post=28592"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}