- SSO API hangi SAML sürümünü destekler?
- SAML TOA, POP3 veya IMAP ile çalışır mı?
- SAML TOA, Gmail Atom feed'iyle çalışır mı?
- SAML TOA, AuthSub ile çalışır mı?
- Tek oturum açma uygulaması için DSA yerine RSA kullanabilir miyiz?
- TOA için gereken doğrulama sertifikasını nasıl oluşturabilirim?
- Alanımızda TOA uygulanırsa yine de Google'a doğrudan giriş yapabilir miyiz?
- Bir tarayıcı oturumu sırasında kullanıcıyı tanımlayan kalıcı olmayan oturum çerezi nasıl silinebilir (ör. oturum kapatıldığında)?
- "Şifre URL'sini değiştir" ayarı neden çalışmıyor?
- SAMLResponse HTML formu neden Firefox'ta çalışırken Internet Explorer'da çalışmıyor?
- Kullanıcıların kimlik doğrulama yapmadan iş ortağı başlangıç sayfasını görüntülemesine nasıl izin verebilirim?
- SAML Response'ta belirtilmesi gereken Recipient (Alıcı) özelliği nedir?
- Üçüncü taraf kimlik sağlayıcımın doğru Alıcı özelliğini belirtmesini nasıl sağlayabilirim?
SSO API hangi SAML sürümünü destekler?
Şu anda SAML v2.0 desteklenmektedir. SAML v2.0 standardıyla ilgili ayrıntıları öğrenmek için http://www.oasis-open.org/specs/index.php#samlv2.0 adresini ziyaret edin.
SAML TOA, POP3 veya IMAP ile çalışır mı?
Hayır, SAML yalnızca Google Workspace web uygulamalarıyla çalışır.
SAML TOA, Gmail Atom feed'iyle çalışır mı?
Hayır. Gmail Atom feed'i, HTTP temel kimlik doğrulamasını kullanır.
SAML TOA, AuthSub ile çalışır mı?
Evet. SAML, AuthSub ile çalışır.
Tek oturum açma uygulaması için DSA yerine RSA kullanabilir miyiz?
Evet. RSA veya DSA şifreleme algoritması kullanmayı seçebilirsiniz. Her ikisi de kabul edilir.
TOA için gereken doğrulama sertifikasını nasıl oluşturabilirim?
openssl komutunu kullanarak X509 sertifikaları oluşturabilirsiniz. Ayrıntılar için TOA için Anahtar ve Sertifika Oluşturma başlıklı makaleyi inceleyin.
Alanımızda TOA uygulanırsa yine de Google'a doğrudan giriş yapabilir miyiz?
Hayır, TOA uygulandığında alan son kullanıcıları doğrudan Google'a giriş yapamaz. Süper yöneticiler, Google kontrol paneline (ör.http://www.google.com/a/example.com) giriş yapmaya devam edebilir.
Tarayıcı oturumu sırasında bir kullanıcıyı tanımlayan kalıcı olmayan oturum çerezi nasıl silinebilir (ör. oturumdan çıkış yapıldıktan sonra)?
Google, SAML aracılığıyla kimlik doğrulama başarılı olduktan sonra kullanıcının oturumunu tanımlamak için bir oturum çerezi ayarlar. Kullanıcı açıkça oturumu kapattığında (ör. oturumu kapatma düğmesini tıklayarak) bu çerez yok edilmelidir. Uygulamanızda kalıcı oturum yönetimi ("Bu bilgisayarda beni hatırla" işlevi) kullanılıyorsa bu çerezin nasıl ve ne zaman silineceğini kontrol etmeniz gerekebilir. Çıkış yaptığında, Google kullanıcıyı çıkış yapma servlet'inize yönlendirir. Oturumu kapatma servlet'inizde, kullanıcıya oturum çerezinin silinip silinmeyeceğini belirleyebilecek bazı seçenekler sunabilirsiniz.
"Şifre URL'sini değiştir" ayarı neden çalışmıyor?
TOA ayarlarındaki Şifre URL'sini değiştirme bölümünde yapılan değişikliklerin geçerli olması yaklaşık bir saat sürer.
SAMLResponse HTML formu neden Firefox'ta çalışıyor da Internet Explorer'da çalışmıyor?
Bunun nedeni, Internet Explorer'ın RelayState değerini yanlış yorumlaması olabilir. Internet Explorer, "<mpl"yi "<mpl" olarak yorumlar. Bunun olmasını önlemek için XML özel karakterleri, RelayState'te kaçış karakterlerinin arasına alınmalıdır. { &, <, >, ', " } karakterlerini { &, <, >, ', " } olarak değiştirin.
Kullanıcıların kimlik doğrulaması olmaksızın iş ortağı başlangıç sayfasını görüntülemesini nasıl sağlayabilirim?
Örnek SAMLResponse için tartışma grubundaki bu konuyu inceleyin.
SAML Response'ta belirtilmesi gereken Recipient (Alıcı) özelliği nedir?
SAML 2.0 profilleri spesifikasyonu bölüm 4.1.4.2'ye göre, Recipient özelliği Onaylama Tüketici Hizmeti (ACS) URL'sine eşit olmalıdır. Şurada bulunur:
<samlp:Response ...>
<saml:Assertion ...>
<saml:Subject>
<saml:NameID ...>user@domain.com</saml:NameID>
<saml:SubjectConfirmation ...>
<saml:SubjectConfirmationData Recipient="https://www.google.com/a/domain.com/acs" .../>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:Assertion>
</samlp:Response>
Recipient özelliğini SAML Response'a nasıl ekleyebileceğinizi öğrenmek için aşağıdaki soruları inceleyin.
Üçüncü taraf kimlik sağlayıcımın doğru Recipient (Alıcı) özelliğini belirttiğinden nasıl emin olabilirim?
Ticari veya açık kaynak kimlik sağlayıcınız SAML 2.0'ı destekliyorsa, zaten doğru Recipient özelliğini belirtir. Yukarıdaki hata iletilerinden birini alıyorsanız bu, Recipient özelliğinin yanlış olduğu anlamına gelir. Bu durumda, yazılımın satıcısı veya geliştiricisiyle iletişime geçerek bu sayfanın bağlantısını gönderin.
TOA ile, kullanıcılarım yönetici denetim masası giriş URL'sini kullanarak kendi kendilerine kimlik doğrulaması yapabilir mi?
Evet. SAML tabanlı tek oturum açma (TOA), Google Workspace oturum açma yetkisini kendi kimlik sağlayıcı yazılımınıza (ör. mevcut bir oturum açma portalı) aktarmanıza olanak tanır. Yazılımınız, kullanıcı hesaplarınızın kimlik doğrulamasını kontrol eder ve yönetir. Google Workspace, oturum açma girişimini TOA portalınıza yönlendirir. Ancak, yöneticilerinizin bu hizmetleri yine Google Yönetici konsolunun yönetici giriş URL'sini (https://www.google.com/a/example.com) kullanarak yönetebileceğini unutmayın. Bu, TOA portalınızda sorun olursa veya güncellenmesi gerekirse size esneklik sağlar.
"Giriş isteğiniz alıcı bilgisi içermediği için bu hizmete erişilemiyor" hata mesajı ne anlama geliyor?
SAML Response'ta olması gereken bir Recipient özelliğinin bulunmadığı anlamına gelir.
"Giriş isteğiniz geçersiz alıcı bilgileri içerdiği için bu hizmete erişilemiyor" hata mesajı ne anlama geliyor?
SAML Response'taki Recipient özelliğinin, Onaylama Tüketici Hizmeti (ACS) URL'siyle eşleşmediği anlamına gelir.
"Oturum açma kimlik bilgileri doğrulanamadığı için bu hesaba erişilemiyor" hata mesajı ne anlama geliyor?
Bu durum genellikle SAMLResponse'u imzalamak için kullanılan özel anahtarın, Google Workspace'in dosyasında bulunan ortak anahtar sertifikasıyla eşleşmediği anlamına gelir. Lütfen denetim masasındaki TOA Ayarları'nda sertifikayı yükleyin ve işlemi yeniden deneyin.