- Qual versão do SAML é compatível com a API de SSO?
- O SSO via SAML funciona com POP3 ou IMAP?
- O SSO via SAML funciona com o feed Atom do Gmail?
- O SSO via SAML funciona com o AuthSub?
- Podemos usar o RSA em vez do DSA para a implementação do SSO?
- Como posso gerar o certificado de verificação necessário para o SSO?
- Se nosso domínio implementar o SSO, ainda assim poderemos fazer login diretamente no Google?
- Como o cookie de sessão não persistente que identifica um usuário durante uma sessão do navegador pode ser excluído (por exemplo, ao sair)?
- Por que o URL para alteração de senha não está funcionando?
- Por que o formulário HTML SAMLResponse funciona no Firefox, mas não no Internet Explorer?
- Como posso permitir que os usuários vejam a página inicial do parceiro sem autenticação?
- Qual é o atributo Recipient necessário na resposta SAML?
- Como posso garantir que meu provedor de identidade de terceiros especifica o atributo "Destinatário" correto?
Qual versão do SAML é compatível com a API de SSO?
No momento, a versão compatível é SAML v2.0. Acesse http://www.oasis-open.org/specs/index.php#samlv2.0 para encontrar detalhes sobre o padrão SAML v2.0.
O SSO via SAML funciona com POP3 ou IMAP?
Não, o SAML só funciona com os aplicativos da Web do Google Workspace.
O SSO via SAML funciona com o feed Atom do Gmail?
Não, o feed Atom do Gmail usa a autenticação HTTP básica.
O Logon único via SAML funciona com o AuthSub?
Sim, o SAML funciona com o AuthSub.
Podemos usar o RSA em vez do DSA para a implementação do Logon único?
Sim, você pode optar por usar o algoritmo de criptografia RSA ou DSA. Aceitamos ambos.
Como posso gerar o certificado de verificação necessário para o SSO?
É possível gerar certificados X509 usando o comando openssl. Para mais detalhes, consulte
Gerar chaves e certificados para
SSO.
Se nosso domínio implementar o SSO, ainda assim poderemos fazer login diretamente no Google?
Com o SSO implementado, os usuários finais do domínio não poderão fazer login diretamente no Google. Os superadministradores ainda podem fazer login no painel de controle do Google (por exemplo, http://www.google.com/a/example.com).
Como excluo o cookie da sessão não persistente que identifica um usuário durante a sessão do navegador (por exemplo, ao sair)?
Após a autenticação bem-sucedida via SAML, o Google define um cookie de sessão para identificar a sessão de um usuário. Quando o usuário faz logout explicitamente (por exemplo, clicando no botão de logout), esse cookie precisa ser destruído. Se a sua implementação envolver gerenciamento de sessão persistente (funcionalidade "Lembrar-me neste computador"), talvez seja necessário controlar como e quando esse cookie é destruído. Na saída, o Google redirecionará a sessão para seu servlet de saída. No servlet de logout, você pode apresentar ao usuário algumas opções que determinam se o cookie de sessão deve ser excluído ou não.
Por que o URL para alteração de senha não está funcionando?
As mudanças no URL de alteração de senha nas configurações de SSO levam cerca de uma hora para entrar em vigor.
Por que o formulário HTML SAMLResponse funciona no Firefox mas não no Internet Explorer?
Isso acontece quando o Internet Explorer interpreta o RelayState de forma incorreta. O Internet Explorer interpreta "<mpl" como "<mpl". Para evitar esse erro, é preciso remover os caracteres XML especiais do RelayState. Mude { &, <, >, ', " } para { &, <, >, ', " }.
Como posso permitir que os usuários vejam a página inicial do parceiro sem fazer a autenticação?
Consulte este tópico no grupo de discussão para ver um SAMLResponse de exemplo.
Qual é o atributo Recipient necessário na resposta SAML?
De acordo com a seção 4.1.4.2 da especificação de perfis SAML 2.0, é preciso que o atributo Recipient seja igual ao URL do serviço de declaração de consumidor (ACS, na sigla em inglês) localizado aqui:
<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>
Veja as perguntas abaixo para saber como adicionar o atributo Recipient à resposta SAML.
Como posso garantir que meu provedor de identidade de terceiros especificará o atributo Recipient correto?
Se seu provedor de identidade comercial ou de código aberto for compatível com o SAML 2.0, ele já terá especificado o atributo Recipient correto já estará especificado por ele. Se você está recebendo uma das mensagens de erro acima, isso significa que o atributo Recipient está incorreto. Se esse for o caso, entre em contato com o fornecedor ou o mantenedor do software e envie o link para essa página.
Meus usuários podem fazer a própria autenticação usando o URL de login do painel de controle do administrador com Logon único?
Sim. O logon único (SSO) baseado em SAML permite transferir a autoridade de login do Google Workspace para seu próprio software de provedor de identidade, por exemplo, um portal de login atual. Seu software controla e gerencia a autenticação das contas de usuário, e o Google Workspace redireciona uma tentativa de login para o portal de SSO. No entanto, é importante lembrar que os administradores ainda poderão gerenciar esses serviços usando o URL de login do administrador do Google Admin Console (https://www.google.com/a/example.com). Isso oferece flexibilidade caso seu portal de SSO tenha um problema ou precise de atualização.
O que significa a mensagem de erro "Não foi possível acessar este serviço porque sua solicitação de login não continha informações de destinatário"?
Significa que a resposta SAML não tem o atributo Recipient necessário.
O que significa a mensagem de erro a seguir: "Não foi possível acessar esse serviço porque sua solicitação de login continha informações de destinatário inválidas"?
Significa que o atributo Recipient na resposta SAML não corresponde ao URL do serviço de declaração do consumidor (ACS).
O que significa a mensagem de erro "Não foi possível acessar esta conta porque não conseguimos confirmar as credenciais de login"?
Isso geralmente significa que a chave privada usada para assinar o SAMLResponse não corresponde ao certificado de chave pública que o Google Workspace tem em arquivo. Faça upload do certificado em "Configurações de SSO" no painel de controle e tente novamente.