Kimlik sağlayıcılarını yönetme
Kuruluşunuzun kullanıcılarının mevcut kurumsal kimlik bilgileriyle kimlik doğrulaması yapabilmesi için SAML veya OIDC çoklu oturum açma amacıyla özel kimlik sağlayıcıları (IdP) yapılandırın.
Kimlik sağlayıcısı yönetimi yalnızca Enterprise plan yöneticileri tarafından kullanılabilir.
Kuruluşunuz için çoklu oturum açmayı (SSO) etkinleştirmek üzere özel bir kimlik sağlayıcısı (IdP) yapılandırın. Bir IdP yapılandırdığınızda, Bob sizi IDE, Bob Shell ve Bob Web'de IBM Bob'a giriş yaparken kimlik doğrulaması için bu sağlayıcıya yönlendirir.
Bob ile SAML ve OpenID Connect (OIDC) kimlik sağlayıcılarını yapılandırabilirsiniz. Kuruluşunuzun kimlik platformuyla eşleşen protokolü kullanın.
SSO protokol uyumluluğu
IBM Bob aşağıdaki SSO protokolleriyle uyumludur:
- SAML (Security Assertion Markup Language)
- OIDC (OpenID Connect)
Doğrulanmış OIDC sağlayıcıları
Yapılandırma ve token gereksinimlerini karşılayan diğer OIDC sağlayıcılarını kullanabilseniz de, aşağıdaki platformlar doğrulanmıştır:
- Auth0
- Keycloak
- Okta
- PingOne
Kimlik sağlayıcısı ekleme
IdP eklemek iki adımlı bir süreçtir. Önce IdP'yi yapılandırıp kaydedersiniz. Ardından onu kullanan e-posta etki alanlarını eklersiniz.
1. Adım: Kimlik sağlayıcısını yapılandırma
IBM Bob Yönetimi sayfasına gidin.
Authentication sekmesini seçin.
Add IdP'ye tıklayın. IdP için bir ad girin. IdP türünü seçin: SAML veya OIDC. Service provider (SP) kimlik bilgilerinizi oluşturun.
Bob, SAML kimlik doğrulama isteklerini imzalamak için bir SP private key ve SP sertifikası gerektirir. Bunları openssl komut satırı aracını kullanarak kendiniz oluşturmalısınız.
Zaten bir SP anahtar çifti ve sertifikanız varsa, bir sonraki adıma geçin.
SP private key'i oluşturmak için aşağıdaki komutu çalıştırın:
openssl genrsa -out sp_private_key.pem 2048Ardından private key'den SP sertifikasını oluşturmak için bu komutu çalıştırın. /CN, /O ve /C değerlerini açıklayıcı bir sertifika adı, kuruluş adınız ve iki harfli ülke kodunuzla değiştirin:
openssl req -new -x509 -key sp_private_key.pem -out sp_certificate.pem -days 365 -subj "/CN=Bob SAML SP/O=IBM/C=US"sp_certificate.pem dosyası, Bob'dan gelen isteklerdeki imzaları doğrulayabilmesi için IdP'nize de yüklenmelidir.
IdP için yapılandırma ayrıntılarını girin. Aşağıdaki bölümlerde protokole özgü gereksinimleri gözden geçirin. Save'e tıklayın.
IdP oluşturulur ve Authentication sekmesindeki tabloda görünür.
SAML yapılandırması
SAML için aşağıdaki yapılandırma ayrıntıları gereklidir:
Identity provider alanları — bunları IdP'nizden alın:
idp_entity_id— IdP için benzersiz tanımlayıcı (örneğin,https://idp.example.com)idp_sso_url— Bob'un kimlik doğrulama isteklerini gönderdiği SSO URL'siidp_certificate— IdP'den gelen SAML yanıtlarını doğrulamak için kullanılan PEM kodlu X.509 sertifikası
Service provider alanları — önceki adımda oluşturulan dosyaları kullanın:
sp_private_key—sp_private_key.pemiçeriğisp_certificate—sp_certificate.pemiçeriği
İsteğe bağlı alanlar:
idp_slo_url— IdP'nin Single Logout URL'si. Single Logout henüz Bob'da tam olarak uygulanmamıştır.
Attribute mapping bölümünde, IdP'nin kullanıcı özelliklerini IBM Bob'un kullanıcı alanlarıyla eşleştirin. Eşleme biçimi Bob özellik adı → IdP özellik adı veya URI'dir. Doğru özellik adları için IdP yapılandırmanızı kontrol edin.
email(gerekli) — kullanıcının e-posta adresiname(isteğe bağlı) — kullanıcının tam görünen adıgiven_name(isteğe bağlı) — kullanıcının adıfamily_name(isteğe bağlı) — kullanıcının soyadıgroups(isteğe bağlı) — kullanıcının grupları
IdP yöneticisi: yeni bir OIDC istemcisi kaydetme
Bir Bob örneği yöneticisi Bob'da bir OIDC IdP kaydı yapılandırmadan önce, bir IdP yöneticisinin kimlik sağlayıcısında bir OIDC uygulaması (istemci) oluşturması gerekir. Bu adımda üretilen değerler, Bob örneği yöneticisinin Bob'a IdP eklerken gireceği değerlerdir.
Uygulama türü ve yetki türü
Kimlik sağlayıcınızda bir Web uygulaması (sunucu taraflı / gizli istemci) oluşturun ve Authorization Code yetki türünü etkinleştirin. Bob yalnızca Authorization Code akışını kullanır — Implicit, Device Code veya Client Credentials seçmeyin.
Yönlendirme URI'si
Aşağıdaki callback URL'sini OIDC uygulamasına kaydedin. Çoğu sağlayıcı dizeyi tam olarak eşleştirdiğinden, olduğu gibi kopyalayın:
https://api.us-east.bob.ibm.com/authn/v1/auth/callbackİstemcide etkinleştirilecek kapsamlar
| Kapsam | Amaç | Gerekli |
|---|---|---|
openid | OIDC modunu etkinleştirir ve id_token döndürür | Evet |
email | Kullanıcının e-posta adresini id_token'da veya userinfo endpoint'i aracılığıyla gösterir | Evet |
offline_access | Access token ile birlikte refresh_token verir | Çoğu sağlayıcı için evet |
Bob, her yetkilendirme kodu değişim yanıtında bir refresh_token bulunmasını gerektirir. Sağlayıcınız yenileme token'larını farklı bir mekanizmayla (örneğin sağlayıcıya özgü bir kapsam veya her kod değişiminde koşulsuz olarak) yayınlıyorsa buna göre yapılandırın — ancak istemcinin yenileme token'ı almasına izin verildiğinden emin olun. refresh_token döndürülmezse oturum açma işlemi iptal edilir.
Token endpoint'inde kimlik doğrulama yöntemi
OIDC uygulamasındaki token endpoint kimlik doğrulama yöntemini client_secret_post olarak yapılandırın. Bob her token isteğinde client_id ve client_secret'ı form gövdesi parametreleri olarak gönderir. client_secret_basic, private_key_jwt ve none kabul edilmez.
Token ayarları
| Ayar | Gerekli değer |
|---|---|
| Access token biçimi | Herhangi biri (JWT veya opak — Bob, IdP access token'ını doğrudan çözümlemez) |
| ID token | Her yetkilendirme kodu değişiminde ve her token yenilemesinde yayınlanmalıdır |
| ID token imzalama algoritması | RS256, ES256 veya PS256 |
| Refresh token rotasyonu | Refresh token rotasyonunu kullanabilirsiniz. Bob her yenilemede yeni token'ı saklar. Sağlayıcınız refresh token'ları döndürüyorsa, sağlayıcının önceki token'ı yalnızca Bob yedek token'ı aldıktan sonra geçersizleştirdiğinden emin olun (standart rotasyon davranışı, tolerans penceresi olmayan tek kullanımlık değil). |
Bob örneği yöneticisine iletilecek değerler
İstemci uygulaması oluşturulduktan sonra aşağıdaki değerleri Bob örneği yöneticisine iletin:
| Değer | Nerede bulunur | Bob yapılandırma alanı |
|---|---|---|
| İstemci Kimliği | Uygulama kimlik bilgileri sayfası | client_id |
| İstemci Sırrı | Uygulama kimlik bilgileri sayfası | client_secret |
| Authorization endpoint URL'si | Sağlayıcının OIDC endpoint'leri sayfası veya .well-known/openid-configuration | authorization_endpoint |
| Token endpoint URL'si | Sağlayıcının OIDC endpoint'leri sayfası veya .well-known/openid-configuration | token_endpoint |
| JWKS URI | Sağlayıcının OIDC endpoint'leri sayfası veya .well-known/openid-configuration | jwks_uri |
| Issuer URL'si | Sağlayıcının OIDC endpoint'leri sayfası veya .well-known/openid-configuration | issuer |
| Userinfo endpoint URL'si (isteğe bağlı) | Sağlayıcının OIDC endpoint'leri sayfası veya .well-known/openid-configuration | userinfo_endpoint |
Çoğu sağlayıcı tüm endpoint URL'lerini https://<sağlayıcı-etki-alanınız>/.well-known/openid-configuration adresinde yayınlar.
OIDC yapılandırması
OIDC sağlayıcı keşfini kullanabilirsiniz. Sağlayıcınızın .well-known/openid-configuration belgesinden endpoint alanlarını otomatik olarak doldurmak için Retrieve configuration düğmesine tıklayabilir veya her endpoint URL'sini manuel olarak girebilirsiniz.
OIDC için aşağıdaki yapılandırma ayrıntıları gereklidir:
| Alan | Gerekli | Açıklama |
|---|---|---|
client_id | Evet | Kimlik sağlayıcınıza kayıtlı istemci tanımlayıcısı. |
client_secret | Evet | Kayıtlı uygulama için istemci sırrı. Bob bunu güvenli bir şekilde saklar ve API yanıtlarında asla döndürmez. |
scopes | Evet | Yetkilendirme akışı sırasında istenen kapsamlar. Bu liste openid içermelidir. Genellikle email ve offline_access gibi yenileme token'ı vermek için kullanılan sağlayıcıya özgü kapsamı da içerir. |
authorization_endpoint | Evet | Bob'un kullanıcıları oturum açmak için yönlendirdiği HTTPS yetkilendirme URL'si. |
token_endpoint | Evet | Yetkilendirme kodunu token'larla değiştirmek için kullanılan HTTPS token URL'si. |
jwks_uri | Evet | id_token yanıtlarının imzasını doğrulamak için kullanılan JSON Web Key Set (JWKS) HTTPS URL'si. |
issuer | Hayır | Kimlik sağlayıcısı için HTTPS veren tanımlayıcısı. |
prompt | Hayır | Yetkilendirme isteğine iletilen OIDC prompt değeri. |
OIDC Attribute mapping kullanmaz. Bob, kullanıcının e-postasını doğrudan id_token içindeki email talebinden okur.
OIDC yapılandırma örneği
{
"authorization_endpoint": "https://corp.okta.com/oauth2/default/v1/authorize",
"token_endpoint": "https://corp.okta.com/oauth2/default/v1/token",
"issuer": "https://corp.okta.com/oauth2/default",
"client_id": "0oa1b2c3d4e5f6g7h8i9",
"client_secret": "super-secret-value",
"scopes": ["openid", "email", "offline_access"]
}OIDC gereksinimleri ve sınırlamaları
- Bob, yetkilendirme kodu değişim yanıtında bir
refresh_tokengerektirir. Sağlayıcınız bunu döndürmezse oturum açma başarısız olur. - Çoğu sağlayıcı için
scopes'aoffline_accesseklemek yenileme token'ı vermeyi tetikler. Bazı sağlayıcılar farklı davranış kullanır, bu nedenle sağlayıcınızın belgelerini kontrol edin. - OIDC arka kanal oturumu kapatma mevcut değildir.
- Sağlayıcınız endpoint URL'lerini değiştirirse Bob'daki IdP yapılandırmasını güncelleyin.
2. Adım: Etki alanı filtreleri ekleme
IdP kaydedildikten sonra, kimlik doğrulama için onu kullanması gereken e-posta etki alanlarını ekleyin.
Authentication sekmesinde, az önce oluşturduğunuz IdP'yi bulun ve ayarlarını açın. Domain filters bölümünde, bu IdP'yi kullanması gereken e-posta etki alanlarını ekleyin. E-posta adresleri yapılandırılmış bir etki alanıyla eşleşen kullanıcılar, oturum açarken bu IdP'ye yönlendirilir. Değişikliklerinizi kaydedin.
Her e-posta etki alanı yalnızca bir IdP ile ilişkilendirilebilir. Bir etki alanı zaten başka bir IdP tarafından kullanılıyorsa, çakışma çözülene kadar yapılandırma kaydedilemez. SSO uygulanmadan önce her etki alanının doğrulanması da gerekir. Bkz. Etki alanı sahipliğini doğrulama.
Etki alanı sahipliğini doğrulama
IBM Bob, SSO uygulanmadan önce kuruluşunuzun her etki alanına sahip olduğunu doğrulamanızı gerektirir. Doğrulama, etki alanınıza bir DNS TXT kaydı eklenerek yapılır.
IBM Bob Yönetimi sayfasına gidin. Authentication sekmesini seçin. Doğrulamak istediğiniz etki alanını içeren IdP'yi seçin. Domain filters bölümünde etki alanını bulun ve gösterilen doğrulama kodunu kopyalayın. DNS sağlayıcınızda, etki alanına aşağıdaki biçimde bir TXT kaydı ekleyin:
bob-verify=<verification-code>verification-code yerine Domain filters bölümünden kopyaladığınız kodu yazın. Authentication sekmesine geri dönün ve etki alanı için Check verification'a tıklayın.
IBM Bob TXT kaydını başarıyla algıladığında etki alanı doğrulama durumu Verified olarak güncellenir. DNS değişikliklerinin yayılması zaman alabilir.
Kimlik sağlayıcısını kaldırma
IBM Bob Yönetimi sayfasına gidin. Authentication sekmesini seçin. Kaldırmak istediğiniz IdP'yi bulun ve Delete'e tıklayın. Onay iletişim kutusunda Confirm'e tıklayın.
Bir IdP'yi silmek, ilişkili tüm etki alanları için SSO yapılandırmasını kaldırır. Kimlik doğrulama için bu IdP'ye bağımlı olan kullanıcıların başka bir yöntemle oturum açmaları gerekecektir. IdP'nin doğrulanmış etki alanları varsa bir uyarı gösterilir.
Ekip oluşturma ve yapılandırma
IBM Bob Enterprise kuruluşunuzdaki farklı gruplar için kullanıcıları organize etmek ve harcamaları kontrol etmek için ekipler kurun.
Etkinlik günlüğünü inceleme
IBM Bob Enterprise organizasyonunun denetim günlüğü dosyalarını indirip inceleyerek kimlik doğrulama olaylarını ve yönetim etkinliğini izleyin.