OIDC ile Giriş (SSO)

Kullanıcı SSO düğmesiyle sağlayıcının giriş ekranına gider. Parola YEKE’ye gönderilmez. Kimlik doğrulandıktan sonra YEKE oturumu açılır. Akış Authorization Code + PKCE kullanır.

Yerel kullanıcı adı + parola formu kaybolmaz. Bu bir eksiklik değil, acil erişim yoludur: kurulum sahibi (owner) her koşulda yereldir, dolayısıyla sağlayıcı erişilemez ya da yanlış yapılandırılmış olduğunda yerel yönetici girişi açık kalır.

SSO düğmesi giriş ekranında yalnız iki koşul birlikte sağlandığında çizilir: etkin bir sağlayıcı tanımlı olmalı ve lisans Enterprise sso kalemini taşımalı. Bu kalem Active Directory / LDAP girişiyle paylaşılır — yeni bir lisans bayrağı yok ve ikisi aynı anda etkin olabilir.

label             :  Kurumsal hesap
issuer            :  https://kimlik.ornek.com/realms/kurum
client id         :  yeke
client secret     :  (yalnız yazılır)
username claim    :  preferred_username
groups claim      :  groups
admin group       :  yeke-admins

Kaydetmeden önce "Bağlantıyı test et" düğmesi sağlayıcının discovery belgesini gerçekten çeker, uçları çözer ve kayda yazar. Test başarısız olursa sebep ekranda görünür; kayıt yine de saklanır ama etkinleştirilmez.

Aynı anda tek etkin sağlayıcı olabilir.

Sağlayıcıdan dönüş adresi YEKE_PUBLIC_URL değerinin sonuna /api/auth/oidc/callback eklenerek kurulur. Bu adres sağlayıcı tarafında tam olarak böyle kayıtlı olmalıdır.

YEKE_PUBLIC_URL     :  https://yeke.ornek.com
yönlendirme adresi  :  https://yeke.ornek.com/api/auth/oidc/callback

Rol dizinden türeyebilir

Sağlayıcı kaydında isteğe bağlı bir yönetici grubu (adminGroup) tanımlayabilirsiniz. Tanımlıysa kullanıcının rolü her girişte token’daki grup claim'inden yeniden türer ve o kullanıcının rolünü arayüzden yazmak reddedilir — aksi hâlde yazdığınız değişikliği bir sonraki giriş sessizce ezerdi. Tanımlı değilse rol her zamanki gibi YEKE'nin kullanıcı ekranından yönetilir.

Kubernetes kimliği: dizinle aynı liste

Yetkilendirme ve RBAC sayfasındaki cluster kuralı + kişisel bağlama modeli aynen geçerlidir. Jetondaki grup claim'i, cluster kimlik kuralındaki aynı eşleme listesine yazılır: LDAP için ayrı, OIDC için ayrı bir liste yoktur. Tek liste hem LDAP grup DN'lerini hem OIDC'nin düz grup adlarını taşır.

kaynak grup                                      Kubernetes grubu
CN=YEKE-Operators,OU=Gruplar,DC=ornek,DC=com  →  yeke:cluster-admins    (LDAP)
yeke-operators                                →  yeke:cluster-admins    (OIDC)
3f2b9c14-8a71-4d0e-9c53-6b7a1e5d20f4          →  odeme-nobet            (OIDC)

Keycloak: grup eşleyicide "full path" kapalı olmalı

Keycloak'ın grup eşleyicisi grubun tam yolunu (/ust-grup/alt-grup) basabilir. Eşleme listesine düz grup adı yazacaksanız bu seçenek kapalı olmalı — claim'e düz adın basması buna bağlı.

Entra ID grup claim'inde GUID basar

Entra ID grup claim'ine grubun adını değil GUID'ini koyar; eşleme satırının sol tarafına yazacağınız değer o GUID'dir. Satıra opsiyonel bir etiket yazılabilir — yalnız GUID'lerden oluşan bir liste okunamaz hâle geliyor.

Entra ID'de uygulama kaydı

Microsoft Entra ID'yi sağlayıcı olarak bağlamadan önce Entra tarafında bir uygulama kaydı açmanız gerekir: uygulama kaydı, istemci sırrı, yönetici grubu ve token'daki grup ayarının tamamı adım adım Entra ID ile SSO Kurulumu sayfasında.

• Otomatik oluşturma (JIT). Sağlayıcıda doğrulanan ama YEKE'de henüz kaydı olmayan kullanıcı, ilk başarılı girişte otomatik olarak oluşturulur.
• Koltuk tüketir. Otomatik oluşan kullanıcı, elle oluşturulmuş biri gibi bir lisans koltuğu tüketir. Koltuk tavanı doluysa giriş açık bir kodla reddedilir.
• Kullanıcı adı claim'den gelir. YEKE'nin sakladığı ad, usernameClaim ile seçtiğiniz claim'in değeridir; kullanıcı listesinde ve denetim izinde görünen ad budur.
• Aynı ada sahip bir hesap varsa giriş reddedilir. Gelen kullanıcı adı var olan bir yerel ya da LDAP hesabıyla çakışıyorsa giriş gürültülü bir hatayla durur; OIDC kullanıcısı sessizce o hesaba bağlanmaz. Sessiz bağlama hesap devralma sınıfına giren bir davranıştır.

• OIDC kullanıcısı YEKE'nin kendi TOTP'sini kaydedemez. İkinci faktörü kimin isteyeceğine sağlayıcı karar verir; YEKE aynı kullanıcı için ikinci bir faktör kaydı açmaz.
• Yerel hesaplarda değişen bir şey yok. YEKE'nin kendi ikinci faktörü yerel kullanıcılar için aynen durur.

• SAML ve SCIM yok. Bu sayfadaki her şey OIDC içindir; SAML ile SCIM talebe göre planlanan kuyrukta.
• Entra ID ile uçtan uca giriş gerçek bir kiracıya karşı denendi. Grup nesne kimliği (GUID) → rol ve Kubernetes grup eşlemesi de aynı testin parçasıydı; bu, 0.46.1 ile geldi — önceki sürümler Entra ID'yi sağlayıcı olarak kaydedemiyordu. Hâlâ doğrulanmayanlar: çok sayıda gruba üye bir kullanıcıda Entra'nın "groups overage" davranışı ve bir uygulama kaydı yeniden oluşturulduğunda kullanıcı kimliğinin (sub) değişip değişmediği.
• Entra "groups overage" durumunda giriş reddedilir. Kullanıcı çok fazla grupta olduğunda Entra ID grup claim'ini hiç basmaz. YEKE bu durumda girişi reddeder; boş bir grup kümesiyle sessizce devam etmez, çünkü o yol kullanıcıyı hiçbir hata vermeden yetkisiz bırakırdı.
• Aynı anda tek etkin sağlayıcı. Birden fazla OIDC sağlayıcısını aynı anda etkin tutma yoktur.
• IdP oturumu kapandığında YEKE oturumu kendiliğinden kapanmaz. Back-channel logout yoktur: YEKE kendi oturumunu tutar, sağlayıcının token'ı yalnız giriş anında kullanılır ve saklanmaz.
• Lisanssız kurulumda bu sayfadaki hiçbir şey çalışmaz. Sağlayıcı yapılandırması ve OIDC girişi, Enterprise sso kalemi olmadan açık bir hatayla reddedilir; yerel giriş bundan hiç etkilenmez.