SAML 2.0 Kurulumu
SAML protokolünü destekleyen kimlik sağlayıcılar için SAML 2.0 ile Tek Oturum Açma'yı yapılandırın. Bu kılavuz, herhangi bir uyumlu IdP için geçerli olan genel SAML kurulumunu kapsar.
Ön Koşullar
- SAML 2.0 uyumlu bir kimlik sağlayıcı (Okta, Azure AD, OneLogin, PingFederate vb.)
- Uygulama oluşturmak ve yapılandırmak için kimlik sağlayıcınıza Yönetici erişimi
- Bir SecureCodingHub Kurum Yöneticisi hesabı
Servis Sağlayıcı Ayrıntıları
SecureCodingHub'ı kimlik sağlayıcınızda yapılandırırken bu değerlere ihtiyacınız olacak:
| Ayar | Değer |
|---|---|
| SP Entity ID | https://api.limeplate.com |
| ACS URL (Assertion Consumer Service) | https://api.limeplate.com/api/sch/auth/sso/callback/saml |
| SP Metadata URL | https://api.limeplate.com/api/sch/auth/sso/metadata |
| Name ID Format | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
| Binding | HTTP-POST |
Adım 1 — Kimlik Sağlayıcınızı Yapılandırın
Adım 2 — SecureCodingHub'da SAML Yapılandır
Adım 3 — Test
Özellik Eşlemesi
SecureCodingHub, SAML iddiasından aşağıdaki özellikleri okur:
| SAML Özelliği | SecureCodingHub Alanı | Zorunlu |
|---|---|---|
NameID (e-posta formatı) | E-posta | Evet |
givenName (…/claims/givenname) | Ad (ilk parça — soyadla tek bir görünen ada birleştirilir) | Hayır |
surname (…/claims/surname) | Ad (ikinci parça — sağlama anında givenName ile birleştirilir) | Hayır |
Vahşi doğada SAML yanıtı okumak
SAML başarısız olduğunda teşhise giden en hızlı yol, tarayıcıdaki belirti yerine gerçek SAML yanıtını incelemektir. Bir SAML tracer tarayıcı eklentisi kurun, başarısız girişi tekrar üretin ve IdP'nin ACS URL'sine gönderdiği POST'a bakın. Üç alan size neredeyse her şeyi söyler. Issuer öğesi, IdP metadata'nızda yayımlanan entityID ile eşleşmelidir. Conditions içinde yer alan Audience öğesi, SecureCodingHub'da yapılandırılan SP Entity ID ile eşleşmelidir. Subject NameID, belirttiğiniz formatta kullanıcının e-posta adresi olmalıdır.
Bu alanların ötesinde, IdP'niz destekliyorsa InResponseTo tanımlayıcısını kontrol edin, yanıtın imzalandığını doğrulayın (ds:Signature öğesi mevcut), ve NotBefore ile NotOnOrAfter zaman damgalarının mevcut saatle tutarlı olduğunu doğrulayın. IdP ile SP arasındaki ciddi saat sapmaları, geçerli iddiaların sessiz reddedilmesine neden olur. Yanıt iyi biçimlendirilmiş ama iddia hâlâ reddediliyorsa tracer'dan base64 kodlu SAMLResponse değerini kopyalayın ve çevrimdışı çözün. Ham XML'i SAML 2.0 spesifikasyonuna karşı okumak, eksik bir özelliği ya da yanlış yapılandırılmış bir ifadeyi bulmanın en güvenilir yoludur.
Yardım için IdP ekibine mi yoksa SP ekibine mi sorulur
Çoğu SAML destek bileti, hatanın federasyonun hangi tarafında yaşadığını biliyorsanız bir dakikadan kısa sürede triajlanabilir. Genel bir kural olarak audience ve issuer uyumsuzlukları SP tarafı sorunlarıdır: SecureCodingHub yapılandırması IdP'nin üretmediği değerleri bekliyordur ya da IdP'nin imzaladığından farklı bir SP entity ID karşısında yapılandırılmıştır. Bunlar SecureCodingHub SSO ayarlarını ya da IdP uygulama yapılandırmasındaki SP Entity ID ve ACS URL'yi düzenleyerek çözülür. Önce SecureCodingHub tarafına ulaşın.
Talep ve özellik eşlemesi sorunları genellikle IdP tarafıdır. Kullanıcılar SecureCodingHub'a eksik ad, yanlış e-posta adresi ya da beklenmeyen rol atamasıyla iniyorsa IdP, SP'nin tüketemeyeceği özellikler yayıyordur. IdP yöneticisinin uygulama yapılandırmasında talepleri eklemesi ya da yeniden adlandırması gerekir. Sertifika ve imza hataları ikiye ayrılır: IdP sertifikası süresi dolduysa ya da rotasyona girdiyse, bu IdP tarafı bir düzeltmedir. SecureCodingHub daha önce geçerli bir imzaya güvenmeyi durdurduysa SP tarafında saklanan metadata ya da sertifika eskimiştir ve yenilenmesi gerekir. Kararsız kaldığınızda SAML tracer çıktısını yakalayıp her iki ekiple paylaşın; yanıtın kendisi sıradaki hamleye hangi tarafın sahip olduğunu gösterir. Protokol seçim rehberi için SSO genel bakış.
SAML 2.0: sıkça sorulanlar
"Federated SAML" gerçekte ne demek?
Federated SAML, bir kullanıcının IdP'de bir kez kimlik doğrulayıp bu iddianın SP tarafından kabul edilebilmesi için bir kimlik sağlayıcı (IdP) ile servis sağlayıcı (SP) arasında kurulan güven ilişkisini ifade eder. Federasyon, imzalı XML sözleşmesidir: her taraf diğerinin metadata'sına ve imzalama sertifikasına güvenir. SecureCodingHub, IdP metadata'sını yüklediğinizde ve IdP SP entity ID'yi öğrendiğinde federasyonunuzun parçası olur.
Girişleri bozmadan bir SAML sertifikasını nasıl rotasyona alırım?
Bir SAML sertifika rotasyonu en iyi kısa bir örtüşme penceresiyle yürütülür. IdP'niz metadata'da birden fazla imzalama sertifikası yayımlamayı destekliyorsa, eski sertifikayı emekliye ayırmadan önce yeni sertifikayı ekleyin ve SecureCodingHub'ın IdP metadata'sını yeniden çekmesini sağlayın; böylece geçiş sırasında her iki sertifikaya da güvenilir. IdP yeni anahtarla imzalamaya başladıktan sonra girişleri bir gün izleyin, sonra eski sertifikayı metadata'dan kaldırın. En yaygın üretim kesintisi, örtüşme olmadan ve Cuma günü rotasyon yapmaktır.
SAML, OAuth ve OpenID Connect — hangisini seçeyim?
Ekipler SAML, OAuth ve OpenID Connect'i karşılaştırırken pratik yanıt operasyonel uyumu izlemektir. SAML 2.0, ADFS ve PingFederate gibi kurumsal IdP'lerde baskın olan olgun, XML tabanlı federasyon standardıdır. OAuth 2.0 tek başına bir yetkilendirme çerçevesidir, kimlik doğrulama değildir. OpenID Connect, OAuth 2.0'ın üstüne kimlik katmanı ekler ve Azure AD ile Okta için modern varsayılandır. SAML ya da OIDC, SecureCodingHub ile size eşdeğer SSO güvenliği verir.
Bir başarısızlığı gidermek için bir SAML yanıtını nasıl çözerim?
Bir SAML yanıtını çözmek için IdP'nin ACS URL'sine gönderdiği base64 kodlu SAMLResponse parametresini yakalayın — bir SAML tracer tarayıcı eklentisi onu yakalamanın en kolay yoludur. Değeri base64 ile ham XML'e çözün ve Issuer, Audience, NameID ve zaman damgalarını inceleyin. Çoğu başarısızlık, o dört alanı SecureCodingHub SSO ayarlarınızda ve IdP'nizin uygulama yapılandırmasında yapılandırılan değerlerle karşılaştırdığınızda çözülür.