DynamicPermissionPolicyProvider
[Authorize(Policy = "...")] için her permission’a tek tek named policy tanımlamak yerine,
policy adı bir konvansiyonla çözülür (SeedWork/Authorization/DynamicPermissionPolicyProvider.cs):
Permission:{code}→PermissionAuthorizationRequirement(code)Scope:{name}→ScopeAuthorizationRequirement(name)
Provider her policy’yi (named, fallback ve
Permission:/Scope: dinamik policy’leri)
ActiveAccountRequirement ile augment eder. Böylece [Authorize] taşıyan hiçbir endpoint’e
Pending/Banned/Suspended hesap erişemez. Augment idempotenttir (zaten varsa tekrar eklemez).[RequirePermission("...")]
RequirePermissionAttribute aslında bir AuthorizeAttribute’tur; policy adını
Permission: + kod olarak üretir:
Handler’lar
Program.cs → RBAC bölümünde üç handler kayıtlıdır:
PermissionAuthorizationHandler
permissions claim’lerini kontrol eder. *:* wildcard her izni geçirir (SuperAdmin):
ScopeAuthorizationHandler
scope claim’ini kontrol eder; "shared" scope her iki uygulama için geçerlidir, *:* yine
geçer:
ActiveAccountAuthorizationHandler
account_status claim’inin Active olmasını gerektirir; endpoint [AllowPendingAccount]
taşıyorsa atlanır:
account_status her istekte UserContextClaimsTransformation / CitizenContextClaimsTransformation
tarafından DB’den güncel olarak yazılır. Olası değerler: Active, Pending, Banned,
Suspended, Draft, Unknown.
AuthPolicies — named scheme policy’leri
Bazı endpoint’ler için “sadece doğru realm’den authenticated olsun yeter” gerekir.Program.cs üç named policy tanımlar (SeedWork/Authorization/AuthPolicies.cs):
Pipeline-level defense-in-depth (MediatR)
HTTP authorization ilk savunma hattıdır. İkinci hat, MediatRAuthorizationPipelineBehavior’dır
(Application/SeedWork/PipelineBehaviors/AuthorizationPipelineBehavior.cs). Command/query
şu marker’ları implement ederse handler çalışmadan önce kontrol edilir:
IRequirePermissions→RequiredPermissionsdizisindeki tüm izinler olmalı (AND).IRequireTenantAccess→ token tenant’ı ile command’dakiTenantIdörtüşmeli.
ForbiddenException → ExceptionPipelineBehavior bunu
HTTP 403’e çevirir. Bu sayede bir endpoint controller attribute’unu unutsa bile use-case
seviyesinde korunur.
Roller ve RolePermission seed
Sabit dört sistem rolü vardır (Domain/AggregatesModel/RoleAggregate/Role.cs, Enumeration):
| Id | Rol | Açıklama |
|---|---|---|
| 1 | SuperAdmin | Sistem genelinde tam yetki |
| 2 | Admin | Kurum/tenant yöneticisi |
| 3 | Staff | Standart personel — okuma + sınırlı işlem |
| 4 | ReadOnly | Salt okunur (raporlama, denetim) |
role_permission tablosunda seed edilir
(RolePermissionEntityTypeConfiguration). Varsayılan matrisin bir kesiti:
| İzin | SuperAdmin | Admin | Staff | ReadOnly |
|---|---|---|---|---|
users:read | ✓ | ✓ | — | ✓ |
users:write | ✓ | ✓ | — | — |
users:delete | ✓ | — | — | — |
roles:manage | ✓ | — | — | — |
tenants:switch | ✓ | ✓ | ✓ | — |
reports:read | ✓ | ✓ | ✓ | ✓ |
faqs:write | ✓ | ✓ | ✓ | — |
bagisBasvuru:onayla | ✓ | ✓ | — | — |
a{roleId}-...-{permissionId}), böylece migration tekrarlarında
duplicate oluşmaz. Aktif (role_id, permission_id) çifti partial unique index ile korunur
(deleted_at IS NULL), soft-delete sonrası yeniden atama mümkündür.
İlgili
Authentication
Token doğrulama ve claim üretimi.
Multi-Tenancy
IRequireTenantAccess ve tenant izolasyonu.Realm Yapısı
Rollerin Keycloak’taki karşılığı, permissions mapper.
Application Authorization
MediatR pipeline ve marker arayüzleri.