CAP · informational
XSUAA ile CAP Fiori yetkisi nasıl kurulur
XSUAA, BTP’de CAP servisine JWT basan yetki katmanıdır. Scope’lar xs-security dosyasında, rol koleksiyonları subaccount’ta, kullanıcı IAS veya kurumsal IdP’den gelir. Fiori Teknoloji “approuter açık herkes görür” yayınını teslimat saymaz.
xs-security.json ve scope tasarımı
xs-security.json scope, role-template ve role-collection iskeletini tanımlar. CAP @restrict veya handler authority bu scope’ları okur. Fiori Teknoloji scope’u ekran kadar ince doğramaz; iş rolü (görüntüle, düzenle, onayla) yeter. Her butona scope şişmesi rol yönetimini kırar. xsappname MTA ile kilitlenir; kopya proje aynı adla çakışır. Tenant-mode ve oauth2-configuration IAS ile trust sonrası çalışır. Yerelde mock auth geliştiriciyi hızlandırır, üretim rolünü öğretmez. Fiori Elements action, CAP action yetkisine map edilmezse düğme görünür tıklanınca 403 olur. Tasarım: gizle veya disable, sessiz 403 değil. Role collection subaccount’ta kullanıcı veya gruba bağlanır. Gruplar IAS/IdP’den gelir, tek tek e-posta tıklamak ölmez.
- Scope iş rolüne göre, her butona değil
- xsappname çakışması JWT’yi yanlış uygulamaya basar
- Action 403 yerine UI’de yetkisiz düğme gizlenir
Approuter, IAS ve JWT zinciri
Approuter tarayıcı oturumunu XSUAA’ya yönlendirir, token’ı CAP’e iletir. IAS, kurumsal IdP (ör. Microsoft Entra ID) önündedir. Trust kurulmadan XSUAA “kullanıcı yok” der. Fiori Teknoloji principal propagation’ı XSUAA ile karıştırmaz: S/4’e giden kullanıcı destination ve Cloud Connector zincirindedir. CAP scope’u S/4 DCL’inin yerine geçmez. İki sistemde iki yetki modeli vardır; keşifte ikisi de yazılır. Token ömrü ve refresh approuter ayarındadır. CORS ve xs-app.json route sırası yanlışsa Fiori metadata 401 döner. HTML5 repo ile standalone approuter farkı MTA’da görünür. Work Zone karosu kendi kabuğunu kullanır; yönlendirme yine XSUAA trust ister. Bağımsız ekip olarak IdP lisans satmayız; trust müşteri tenant’ında kurulur.
- IAS/IdP trust olmadan XSUAA kullanıcı çözmez
- CAP scope S/4 DCL yerine geçmez; zincir iki yetki modelidir
- xs-app.json route sırası 401’in sık nedenidir
Sık yetki arızaları
Kullanıcı giriş yapar, karo açılır, OData 403: rol koleksiyonu eksik veya scope adı değişmiş. Giriş döngüsü: redirect URI, IAS koşulu veya cookie. Fiori Teknoloji jwt’yi (gerekli alanlar) log’da maskeleyerek okur; token’ı sohbete yapıştırmayız. Admin role collection’ını herkese vermek denemeyi çözer, üretimi zehirler. Test kullanıcısı üç hal: yok, okur, yazar. Destination client credentials S/4’e teknik kullanıcıyla gider; insan yetkisini taklit etmez. İnsan senaryosunda principal propagation tasarlanır. XSUAA ile API Management politikası üst üste binmesin diye hangi katmanın kestiği runbook’ta yazılır. Trial hesapta IdP seçenekleri sınırlıdır; kurumsal tasarımı trial’da doğrulamayız. Yetki runbook’u go-live paketinin parçasıdır, sonradan yazılmaz.
- 403: rol koleksiyonu ve scope adı ilk bakılan yerdir
- Client credentials insan yetkisini taklit etmez
- Trial IdP, kurumsal IAS tasarımının kanıtı değildir
Sık sorulanlar
XSUAA ile IAS aynı şey midir?
Değildir. IAS kimliği doğrular (ve IdP federasyonu). XSUAA BTP uygulamasına scope’lu JWT basar. Trust ile bağlanırlar. CAP yetkisi XSUAA scope’larından okunur.
Yerel mock yetki üretimde kullanılır mı?
Hayır. cds mock veya temel auth yalnızca geliştirme içindir. Üretimde XSUAA, IAS ve rol koleksiyonu zorunludur. Mock ile geçen test go-live kapısı değildir.
Bu konuyu ortamınızda netleştirmek için 48 saatlik ön değerlendirme.
Lisans satmıyoruz. Destination, yetki ve model kararını yazılı notlarız.