Güvenlik · troubleshooting
Principal propagation — LLM çağrısında kullanıcı kimliği
Joule, CAP ve Hub çağrısı kullanıcı JWT'sini S/4 OData'ya kadar taşımazsa teknik kullanıcı herkesin belgesini çeker. Bu sayfa IAS trust, XSUAA ve OAuth2SAMLBearer destination kırıklarını ayırmanızı sağlar. Propagation, prompt kalitesi değildir.
Zincir: IAS, XSUAA, dest, S/4
Kullanıcı IAS'ta doğrulanır, Work Zone/approuter XSUAA token üretir, CAP aynı token veya exchange ile S/4 dest'e SAML Bearer gönderir. Kopuk halka: IAS trust yok, NameID eşlemesi yanlış, dest auth Basic, S/4 communication user tek başına. İstanbul HAR: IdP 302, XSUAA 401, dest 401, S/4 403. sap-ai-btp-destination alanları, bu sayfa kimlik eşlemesini kapatır. Joule skill CAP'i client credential ile çağırırsa zincir baştan kopuktur. sap-joule-fiori 403'ü OData yetkisi sanır; aslında SY-UNAME teknik kullanıcıdır. Kanıt: backend SY-UNAME iş kullanıcısı mı. Log'ta 'COMM_USER' görünmesi kırmızı. Teknik kullanıcı tüm şirket kodlarını görür; Joule bu identity ile konuşursa SoD delinir, SAML Bearer şarttır.
- Zincir diyagramı: IAS → XSUAA → SAML dest → S/4
- Kanıt: S/4 SY-UNAME = iş kullanıcısı, COMM_USER değil
- Joule→CAP: client credential yasağı (iş verisi)
NameID, attribute, sap-user
SAML NameID e-posta, S/4 kullanıcı adı farklıdır. Eşleme IAS veya dest additional properties ile yapılır; tahmin edilmez. sap-user, sap-client eksikse yanlış mandant. Çok IdP (şirket birleşmesi) Joule'da 'bazen 403' üretir. İstanbul eşleme tablosu: IAS subject, S/4 user, e-posta, örnek üç hesap. sap-work-zone-joule shell login'i, bu madde backend user'ı ayırır. Sertifika expiry trust'u düşürür; Joule 'model timeout' der. Çözüm AI Core restart değildir. ABAP Cloud / BTP ABAP aynı prensip, farklı dest. Test: kullanıcı A B'nin siparişini OData'da görmemeli, Joule'da da görmemeli. IAS token XSUAA’ya, oradan S/4’e zincirlenir; kopuk trust 200 boş veya 403 üretir, model kalitesi değildir.
- Eşleme tablosu: IAS subject ↔ S/4 user (üç örnek)
- sap-client / sap-user additional properties
- Negatif test: çapraz kullanıcı sipariş sızıntısı yok
Hub log ve teknik kullanıcı istisnası
Inference Hub'da teknik binding ile durabilir; iş verisi S/4'te kullanıcı ile durmalıdır. İstisna: asenkron CPI job gece çalışır, iletişim kullanıcısı dar yetkili ve idempotent. Bu istisna Joule sohbetine kopyalanmaz. İstanbul kayıt: hangi çağrı teknik, hangisi principal, neden. sap-cpi-ai job istisnasını, sap-ai-kvkk log'daki kimliği ister. Hub execution log'u kullanıcı ID'si taşımıyorsa denetim kördür — orchestration'a user attribute eklenir veya CAP log'u asıl kayıttır. Ajan yazma tool'u technical user ile asla. Keşif 20 dakikası SY-UNAME kanıtıdır, model adı değil. Destination tipi karışınca CAP client credentials ile iş verisi çeker; P2 kaydı destination authentication alanından kapanır.
- Çağrı tipi tablosu: principal vs teknik + gerekçe
- Joule sohbet: teknik user yok
- Hub/CAP log'ta kullanıcı ID veya eşdeğer
Sık sorulanlar
AI Core service key principal propagation midir?
Değildir. Service key runtime'a bağlanır. Kullanıcı→S/4 zinciri IAS/XSUAA/SAML dest'tir. Key'i 'kullanıcı kimliği' sanmak sızıntıdır.
Basic auth dest ile geçici açsak?
İş verisi için hayır. Herkes dest şifresini paylaşmış olur. Geçici PoC prod'a kalır. SAML Bearer veya doğru OAuth şarttır.
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.