Neler değişti

Her içerik güncellemesi sürümlenir. Bir sürümü seçerek öncekiyle karşılaştırın.

Sürüm 12 → 13

Güncelleme

SSO'yu canlıda işletmeye yönelik yeni modül: audience, uygulamaya özel imzalama sertifikaları, token ömürleri ve profil claim'leri, oturum süresi, oturumu kapatma ve iptal, Kerberos ile oturum açma, sözleşmeler ve uygulama kataloğu. Federasyon dersi artık yönlendirme çakışmalarını da ele alıyor.

4 ders güncellendi

İçerik güncellemesi. Kayıtlı öğrenciler bilgilendirildi.

SAML 2.0 uygulamaları

Giden SAML'de **Monosign kimlik sağlayıcıdır (IdP)**, uygulama ise **servis sağlayıcıdır (SP)**. Yapılandırma `SAML` türünde bir uygulama anahtarındadır: Applications → uygulama → `Keys` → anahtar kartında `Configure` → `SAML Settings` sekmesi. Anahtar kartı, SP'ye vereceğiniz oturum açma URL'sini, metaveriyi ve sertifikayı da sunar. ::diagram saml-sp-initiated Temel ayarlar: - **`Metadata Import`**: XML veya URL girin, `Preview changes` ile gözden geçirin ve `Apply to Configuration` ile uygulayın. Entity ID, ACS uç noktaları, NameID biçimi, çıkış URL'si ve SP sertifikalarını doldurur. Kaydedilmiş bir anahtar gerektirir; Monosign uygulama metaverisini arka planda yeniden denetlemez. - **ACS URL'leri**: `Additional Assertion Consumer Urls` izin verilen uç noktaların listesidir. `ACS Validation Mode`, `Off (Legacy)`, `Warn Only` veya `Enforce` olur. Konsolda oluşturulan anahtar `Enforce` ile başlar, ancak v2026.07'den önce kaydedilmiş bir anahtar `Warn Only` gibi davranır ve istenen herhangi bir URL'ye gönderir. Yalnızca `Enforce` reddeder. Eşleşme tam olmalıdır; sondaki eğik çizgi farklı bir URL demektir. - **`Name Id` ve `NameId Format`**: `Name Id` hangi değerin gönderileceğini belirler (varsayılan `UserName`, ya da bir profil özelliği veya belirteç). `NameId Format`, SP'nin beklediği biçim etiketidir. Değer bir kullanıcı için boşsa oturum açma `DATA_MISSING` denetim kaydıyla durur. - **Bağlamalar**: HTTP-POST ve HTTP-Redirect üzerinden SP başlatmalı oturum açma ve varsayılan ACS'yi kullanan IdP başlatmalı oturum açma. Yük dengeleyici arkasında HTTP-Artifact'tan kaçının: artifact çözümü düğüm başına tutulur ve başka düğümde `Unknown artifact` ile başarısız olur. - **`Signing Algorithm`**: `System Default (SHA 256)` veya SHA-1. SHA-1'i yalnızca SP daha iyisini desteklemiyorsa kullanın. - **`Signing Certificates`**: `Organization-Based` (ortak, System → `Configurations` altında ayarlanır) veya `Application-Based`. ::shot sso-saml-settings ### Müşteriye söylenecek sınırlar - Monosign, assertion veya yanıtları **şifrelemez**. `Don't Encrypt Entire Message` ve `Don't Encrypt Assertion` yanıltıcı etiketlerdir: bir **imzayı** kaldırırlar, bu yüzden SP zorunlu kılmadıkça kapalı bırakın. - Bir uygulamadan çıkış yapmak, kullanıcının diğer uygulamalarına SAML `LogoutRequest` göndermez. > İpucu: Kullanıcının ömrü boyunca değişmeyen bir `Name Id` değeri seçin. E-posta adresleri değişir; biçim etiketi tek başına sizi korumaz.

Claim eşleme ve gelen kimlik sağlayıcılar

### Claim eşleme Her uygulama yalnızca ihtiyaç duyduğu öznitelikleri almalıdır. Sekmeler uygulama anahtarındadır: - SAML: `Attribute Mapping`, `Group Mapping`, `Role Mapping`, `Permission Mapping`. - OIDC: `Claim Mapping`, `Profile Claim` ile grup, rol, izin ve kaynak eşleme sekmeleri. Grup, rol ve izin sekmeleri varsayılan olarak kapalıdır. Her birinde bir öznitelik adı (varsayılan `Groups`), filtre ve biçim (varsayılan `{{Name}}`) bulunur. Uygulamanın tüm üyelik listesini değil kendi gruplarını alması için filtreyi kullanın. OIDC'de, Monosign'ın kendi ürettiği bir claim'in adını taşıyan `Claim Mapping` satırı (`email` veya `sub` gibi) o claim'in **yerine geçer**. ::diagram sso-claim-mapping ::shot sso-providers-list ### Gelen federasyon Identity → `Providers` altında Monosign harici IdP'lere de *güvenebilir*. `Add New`, Microsoft Entra ID, Okta, Google, Apple ve GitHub gibi sağlayıcılar için şablonlar ya da boş bir `SAML 2.0`, `OpenID Connect` veya `WS-Federation` sağlayıcısı sunar. - **Yönlendirme**: `Matches any user`, `Matches regex` veya `Matches email domain` kullanıcıyı sağlayıcıya gönderir. `Matches user attribute` kullanmayın: hiçbir zaman yönlendirmez. Arkasında oturum açma isteği olmayan, oturum açma sayfasına doğrudan ziyaret de yönlendirilmez. İki etkin sağlayıcı aynı alan adıyla eşleştiğinde listede `Routing Conflicts Detected` görünür ve yalnızca ilk eşleşme kullanılır: her alan adına tek sağlayıcı verin ve sonucu `Routing Overview` altında `Test Routing` ile doğrulayın. - **`Access rules`**: herhangi bir hesap aramasından önce değerlendirilir. İlk eşleşme kazanır, varsayılan `Allow`'dur. - **`Account link policy`**: varsayılan `Auto (match by email)`. `Manual (link only by source key)` e-posta eşleşmelerini reddeder ve böylece e-posta claim'i üzerinden hesap ele geçirmeyi önler, ancak hesapların önceden bağlanmış olması gerekir. - **Just-in-time sağlama**: varsayılan olarak kapalıdır. `Enable Just-in-Time provisioning`, ilk oturum açmada kullanıcıyı eşlenen alanlar ve `Default groups` ile oluşturur. - **Profil yenileme**: IdP'den gelen gruplar her oturumda eklenir ama asla kaldırılmaz; erişim iptali için buna güvenmeyin. - **Sertifika yenileme**: `Secondary certificate (rotation)` ikinci bir güvenilir sertifika tutar. `Keep in sync from this metadata URL` ile Monosign metaveriyi saatlik yeniler ve yayımlanan ikinci sertifikayı oraya yerleştirir. WS-Federation metaverisi otomatik yenilenmez. ::diagram sso-inbound-federation > Bilinen sınırlama, en son v2026.09'da doğrulandı: gelen sağlayıcı formu `Require PKCE`, `Max clock skew (seconds)`, `Response verification`, `Sign authentication requests` ve `Use persistent NameID format` ayarlarını gösterir, ancak bunların etkisi yoktur. Müşteriye söz vermeyin.

Federasyon sorunlarını giderme

Federasyon hatalarının çoğu birkaç kalıba girer. Sırayla ilerleyin. ::diagram sso-federation-checks ### Giden SAML ve OIDC 1. **Kullanıcı Monosign'a ulaştı mı?** Reports → `Audit` (denetim kayıtları) ve uygulamanın `Audits` sekmesi oturum açma olaylarını gösterir. OIDC uç noktaları kendi denetim kaydını yazmaz; bu yüzden OIDC istemcisinde Account günlüklerini de okuyun. 2. **ACS uyuşmazlığı**: günlükte `SAML ACS validation failed` yazar. `RequestedUrl` ile kayıtlı `Location` değerini, sondaki eğik çizgiler dahil, karakter karakter karşılaştırın. 3. **Assertion beklenmeyen URL'ye gidiyor**: anahtar `Warn Only` veya `Off (Legacy)` durumundadır. `SAML ACS validation warning` satırına bakın, sonra anahtarı `Enforce` yapın. 4. **OIDC'de yönlendirme veya kapsam hataları**: `Allowed Redirect URIs` ve `Scope` alanlarını, ayrıca URL önekinin anahtar türüyle uyumunu kontrol edin. 5. **SP kullanıcıyı tanımıyor**: `Name Id` ve öznitelik eşlemesini kontrol edin. `DATA_MISSING` denetim kaydıyla birlikte `Your Email seems empty…`, özelliğin o kullanıcı için boş olduğu anlamına gelir. 6. **SP imzayı reddediyor**: `/saml/{idpId}/Metadata` içindeki sertifikayı SP'deki kopyayla karşılaştırın ve iki `Don't Encrypt` anahtarını okuyun. Yenilemeden sonra yalnızca bir uygulama başarısızsa `Signing Certificates` türü büyük olasılıkla `Application-Based`'dir. 7. **Issuer uyuşmazlığı**: `does not match the configured Entity Id` yalnızca uyarıdır. Görürseniz gerçek hatayı aynı istekte aramaya devam edin. SAML anahtarındaki `Enable Debug Mode`, her istek ve yanıtı tam olarak günlüğe yazar. Kısa süreli kullanın ve yeniden kapatın. ### Gelen sağlayıcılar - **Kullanıcılar IdP'ye gönderilmiyor**: adresle `Routing Overview` → `Test Routing` çalıştırın. Etkin olmayan sağlayıcı veya `Routing Conflicts Detected` olup olmadığına bakın. - **`No matching user found for the federated identity`**: politika `Manual` ve bağlantı yok ya da e-posta claim'i eşlenmemiş. `Interactive test`, kimseyi oturum açtırmadan claim'leri ve `Mapped profile preview` görünümünü gösterir. Sağlayıcı düzenleme yetkisi olan herkes çalıştırabilir ve ham claim'leri yazdırır. - **IdP sertifikasını yeniledikten sonra SAML başarısız**: `Certificate` sütununu ve `Test connection` içindeki `Signing certificate` satırını kontrol edin. - **Süre dolumu için kimse uyarılmadı**: Monosign `IDENTITY_PROVIDER_CERTIFICATE_EXPIRING` yazar, ancak uyarı kişilere yalnızca buna bir webhook veya tetik bağlarsanız ulaşır. ::shot sso-provider-attribute-mapping

Audience, imzalama sertifikaları ve token ömürleri

Bir uygulama oturum açmaya başladıktan sonra gelen soruların çoğu birkaç anahtar ayarıyla ilgilidir. Hepsi uygulama anahtarındadır: Applications → uygulama → `Keys` → `Configure`. ::shot sso-application-keys ### SAML: assertion kimin için Her assertion, hedeflenen alıcısını belirtir. Monosign bu değeri anahtardaki `Audience` alanından alır. Alan boşsa `Entity Id` değerini, o da boşsa gelen isteğin issuer değerini kullanır. Bir hizmet sağlayıcı audience hatasıyla yanıt veriyorsa assertion başka bir alıcı için düzenlenmiştir: anahtardaki `Audience` ve `Entity Id` alanlarını SP'nin beklediği entity ID ile karşılaştırın. NameID ve imzalama sertifikasının bu hatayla ilgisi yoktur. ::diagram sso-saml-audience-source ### SAML: herkes için tek sertifika mı, uygulama başına sertifika mı `Organization-Based` olarak bırakılan bir anahtar, ortak kurum sertifikasıyla imzalar. Bu sertifika yenilendiğinde ona bağlı her uygulama aynı anda değişir; yani hepsinin hizmet sağlayıcıları birlikte güncellenmelidir. Kendi takvimine göre yenileme yapması gereken bir hizmet sağlayıcı için `Signing Certificates` sekmesini açın, `Generate New Certificate` (veya `Create to Application-Based Signing Certificate`) düğmesini kullanın, anahtarı kaydedin ve SP'ye yeni metadata'yı verin. Bundan sonra kurum sertifikasının yenilenmesi o uygulamayı etkilemez ve uygulamanın kendi sertifikası ayrıca yenilenebilir. Bir SP'nin metadata içe aktarımıyla gelen sertifikalar yalnızca bilgi olarak saklanır. Monosign bunlarla imzalamaz. ### OIDC: audience erişim token'ına aittir Bir OIDC anahtarındaki `Audience` ve `Resource` yalnızca **access token**'a yazılır ve her yenilemede yeniden uygulanır. ID token'ın `aud` değeri, OpenID Connect'in beklediği gibi `client_id` olarak kalır. Kendi audience değerine ihtiyaç duyan bir API bu nedenle ID token'ları değil access token'ları doğrulamalıdır. ### OIDC: ömürler ve devre dışı bırakılan kullanıcının hâlâ yapabildikleri - Üç ömür alanı **dakika** cinsindendir. v2026.07-hf02 sürümüne kadar client credentials kullanan bir istemci bu değerleri saniye olarak okuyordu. Böyle bir sürümde ayarlanmış bir anahtar, örneğin bir saat için `3600`, v2026.09 veya sonrasına yükseltildikten sonra 60 saat yaşayan token'lar üretir. Yükseltme sırasında bu anahtarları gözden geçirin ve değeri dakika olarak, burada `60`, yeniden girin. - Ömür, token üretilirken uygulanır. Daha önce üretilmiş token'lar kendi bitiş zamanını korur. - Bir kullanıcıyı devre dışı bırakmak access token'ı geri çağırmaz. Token, `exp` zamanına kadar geçerli kalır; bir sonraki yenileme ise *The refresh token is no longer valid.* mesajıyla reddedilir. Bu aralığın önemli olduğu API'ler için `Access Token Lifetime` değerini kısa tutun. ### OIDC: yalnızca istemcinin ihtiyaç duyduğu profil verisini gönderin `Profile Access Type` profil claim'lerine izin veriyorsa, siz daraltmadığınız sürece profil claim'i **bütün** profil özelliklerini taşır. `Profile Claim` sekmesindeki `Included Properties` alanında yalnızca istemcinin okuduğu özellikleri seçin. Böylece kişisel veriler token'a girmez ve token'lar, başlık sınırı olan proxy'lerden geçecek kadar küçük kalır. `Included Properties` yalnızca token'ı sınırlar. Userinfo uç noktası kullanıcı modelinin tamamını döndürmeye devam eder; bu uç noktayı hangi istemcilerin çağırdığını da gözden geçirin. > İpucu: Bu değişikliklerden herhangi birinden sonra, değişiklikten **sonra** üretilmiş bir token'ı veya assertion'ı çözümleyin. Eskisi size bir şey söylemez.