Okta (OIDC) Kurulumu
OpenID Connect kullanarak Okta ile Tek Oturum Açma'yı yapılandırmak için adım adım kılavuz.
Ön Koşullar
- Okta yönetici hesabı
- SecureCodingHub kurum yöneticisi hesabı
Adım 1 — Okta Uygulaması Oluştur
Okta Admin Console → Applications → Create App Integration sayfasına gidin
Giriş yöntemi: OIDC
Uygulama türü: Web Application
Uygulama adı: SecureCodingHub
Sign-in redirect URI: https://api.limeplate.com/api/sch/auth/sso/callback/oidc
Atamalar: Kullanıcılarınıza/gruplarınıza atayın
Adım 2 — Kimlik Bilgilerini Kopyala
Okta uygulamanızdan aşağıdaki değerleri toplayın:
| Ayar | Nerede Bulunur |
|---|---|
| Client ID | General → Client Credentials |
| Client Secret | General → Client Credentials |
| Okta Domain | Okta URL'niz (ör. dev-12345.okta.com) |
| Discovery URL | https://{okta-domain}/.well-known/openid-configuration |
Adım 3 — SecureCodingHub'da SSO Yapılandır
Kurum Yöneticisi olarak giriş yapın → SSO Ayarları
Protokol: OIDC
Entity ID / Client ID: Okta Client ID'nizi yapıştırın
Discovery / Metadata URL: Okta OpenID yapılandırma URL'nizi yapıştırın
Client Secret: secret'ı yapıştırın
SSO'yu etkinleştirin
Kaydet'e tıklayın
Adım 4 — Test
Bir gizli/özel tarayıcı penceresi açın
SecureCodingHub girişine gidin
Kuruluşunuzun domain'i ile bir e-posta adresi girin
Okta girişine yönlendirilmelisiniz
Kimlik doğrulamasından sonra SecureCodingHub'a giriş yapmış olmalısınız
Yaygın Okta SAML tuzakları
Bu kılavuz OIDC'ye odaklansa da birçok Okta kiracısı SecureCodingHub'ı SAML üzerinden çalıştırır ve aynı Okta'ya özgü sorunlar tekrar eder. Birincisi audience URI uyumsuzluğudur. Okta bu alana SAML General Settings'te Audience URI (SP Entity ID) adını verir ve değerin SecureCodingHub'ın entity ID olarak yayımladığı şeyle birebir eşleşmesi gerekir. Yaygın bir hata, API entity ID yerine SecureCodingHub web sitesi URL'sini girmektir. Okta uygulamasını kaydetmeden önce değeri SecureCodingHub SSO Ayarları sayfasındaki SP Entity ID alanına karşı doğrulayın.
İkinci tuzak Okta uygulama sign-on policy'sidir. Okta, ek faktörler isteyebilen, ağ bölgesine göre kısıtlayabilen ya da grup üyeliğine göre erişimi tamamen reddedebilen uygulama düzeyinde bir politika uygular. Bir son kullanıcı SSO'nun onları Okta'ya yönlendirdiğini ve ardından access-denied hatasıyla geri sektiğini bildirirse, nedeni neredeyse her zaman kullanıcıyla eşleşmeyen bir uygulama sign-on policy kuralıdır. Uygulama altındaki Sign On Policy'yi kontrol edin ve test kullanıcısına uygulanan kuralı doğrulayın. Üçüncü yaygın tuzak uyumsuz Name ID formatıdır. Okta varsayılan olarak Unspecified kullanır, ama SecureCodingHub emailAddress formatını bekler. Uygulama ayarlarında Name ID format'ını EmailAddress yapın ve kaynak özelliğin user.email veya user.login olduğunu doğrulayın.
SSO'nun uçtan uca çalıştığını doğrulama
Doğrulama, önceki girişlerden kalan çerezlerden kaçınmak için bir gizli tarayıcı oturumunda başlar. SecureCodingHub giriş sayfasına gidin, doğrulanmış domain'iniz ile kurumsal bir e-posta adresi girin ve tarayıcının Okta kiracınıza yönlendirdiğini doğrulayın. Okta'da kimlik doğruladıktan sonra, yönlendirme sizi doğru kuruluş için panelde SecureCodingHub'a indirmelidir. Genel bir açılış sayfasına ya da 404'e iniyorsanız en olası neden kullanıcının henüz SecureCodingHub'da var olmaması ve JIT sağlamanın devre dışı olması ya da oluşturma olayını reddetmiş olmasıdır.
İkincisi, rol ve koltuk atamasını doğrulayın. JIT ile sağlanan kullanıcılar her zaman learner rolüyle iner — SecureCodingHub bugün Okta grup taleplerinden rol bilgisi okumaz, dolayısıyla org_admin'a yükseltme kullanıcı oluştuktan sonra SecureCodingHub yönetici UI'sinden yapılmalıdır. Üçüncüsü, çıkış yapın, sonra tekrar giriş yapın. İkinci giriş Okta oturum çerezi sayesinde neredeyse sessiz olmalıdır. İkinci giriş tam bir yeniden kimlik doğrulama gerektiriyorsa Okta oturum süresi normal kullanım için çok kısa ayarlanmıştır; küresel oturum politikasını ya da uygulama sign-on policy'sini buna göre ayarlayın. Protokol düzeyindeki ayrıntılar için SAML kurulum kılavuzu.