Single Sign On (SSO) em Windows

 4D Server oferece uma nova funcionalidade que lhe permite implementar funcionalidades SSO (Single Sign On) em soluções cliente-servidor em Windows.

A implementação de SSO em suas soluções 4D permitirá aos usuários acessar a aplicação 4D em Windows sem ter que voltar a introduzir sua senha quando já estiverem registrados no dominio Windows de sua empresa (utilizando Active Directory). Atrás, a aplicação 4D Server pode ter acesso a autenticação de início de sessão de Windows, que pode ser utilizada para iniciar a sessão do usuário 4D no banco de dados  utilizando o método de início de sessão normal.

Nota: Para aprender outras propriedades de segurança, veja 4D Security guide.

A propriedade SSO está disponível:

• com aplicações 4D Server em Windows (aplicações 4D monousuário não são compatíveis com SSO)
• com a capa de rede ServerNet ativada. Para saber mais, veja o parágrafo Nova capa de rede ServerNet (compatibilidade).

Normalmente, a funcionalidade SSO não está habilitada em 4D Server. Para se beneficiar destas funcionalidades, é necessário estabelecer a nova opção Autenticação de usuário com servidor de dominio na página cliente-servidor do quadro de diálogo Propriedades do banco de dados de 4D Server:

Quando selecionar esta opção, 4D se conecta de forma transparente ao diretório Active do servidor dominio de Windows e obtém os tokens de autenticação disponíveis.

Esta opção oferece autenticação padrão através do protocolo NTLM. 4D suporta os protocolos NTLM e Kerberos. O protocolo utilizado é selecionado automaticamente por 4D em função da configuração atual (ver Exigências para SSO). Se desejar utilizar o protocolo Kerberos, é necessário preencher o campo SPN adicional (ver mais adiante).

Se desejar utilizar Kerberos como protocolo de autenticação, também é necessário preencher a opção Nome principal do serviço na página cliente-servidor/Opções do quadro de diálogo Propriedades do banco de dados:

Esta opção declara o SPN tal como se estabelece na configuração Active Directory. Um nome principal de serviço é um identificador único de uma instância de serviço. Os SPNs são utilizados pela autenticação Kerberos para associar uma instância de serviço com uma conta de serviço de início de sessão. Isto permite que uma aplicação cliente solicite que o serviço autentique uma conta mesmo se o cliente não tiver o nome da conta. Para mais informação, por favor consulte a página SPN no site web de msdn.O

O identificador SPN deve respeitar este padrão:

• "ServiceName/FQDN_user" se o SPN for um atributo do computador
• "ServiceName/FQDN_computer" se o SPN for um atributo de usuário

onde:

• ServiceName é o nome de serviço ao que o cliente deseja se autenticar.
• O Fully Qualified Domain Name (FQDN) é um nome de dominio que especifica sua localização exata na hierarquía de árvore do Active Directory para  equipamentos e  usuários.

Nos bancos de dados 4D, o SPN pode ser configurardo:

• na configuração da estrutura do banco de dados, para um uso com 4D Server.
• ou na configuração do usuário (settings. arquivo 4DSettings armazenado na pasta Preferências do banco de dados) para as necessidades de implementação.

Quando as funcionalidades SSO estão ativas (ver acima), pode confiar na autenticação de usuário baseada nas credenciais de sessão de Windows para abrir uma sessão de usuário em 4D Server.

Lembre que a funcionalidade SSO só oferece um início de sessão autenticado, deve passar esta informação de acesso a seu método de início de sessão 4D padrão. Quando uma aplicação remota 4D tenta se conectar ao servidor, deve chamar ao novo comando 4D [#cmd id="1355"/, que devolverá o inicio de sessão do usuário, tal como se define no Active Directory. Depois, pode passar esta informação de acesso a seu proprio sistema de identificação (utilizando o usuário e grupos integrados, os comandos LDAP, ou qualquer mecanismo personalizado) para abrir a sessão apropriada para o usuário remoto em seu aplicativo 4D. 

Este principio se desceve no seguinte gráfico:

O comando [#cmd id="1355"/ deve ser chamado no método base On Server Open Connection Database Method, que se chama cada vez que um 4D remoto abre uma nova conexão ao banco 4D Server. Se a autenticação falhar pode devolver um valor não nulo em $0 para recusar a conexão.

Para chamar o comando Current client authentication , (autenticação de cliente atual) use a sintaxe abaixo:

onde:

• login é a  ID usada pelo cliente para fazer login no  Active Directory (valor texto). É necessário usar este valor para identificar o suuário dentro do seu banco de dados.
  Se o usuário não estiver corretamente autenticado, uma string vazia é retornada mas nenhum erro é retornado.
• dominio e protocolo são parâmetros de texto opcionais. Eles são preenchidos pelo comando e permitem que aceite ou rejetite conexões dependendo destes valores:
  
  • dominio é o nome de domínio do Active Directory
  • protocolo é o nome do protocolo usado por Windows para autenticar o usuário.

Para saber mais sobre este comando, veja a descrição do comando  Current client authentication .

4D Server maneja diversas configurações SSO, dependendo da arquitetura atual e configurações. O protocolo usado apra autenticação (NTLM ou Kerberos) assim como a informação retornada pelo comando Current client authentication dependem da configuração atual, se todas as exigências forem respeitadas (abaixo). O protocolo atualmente usado para autenticação é retornado no parâmetro protocolo do comandoCurrent client authentication.

A tabela abaixo oferece as exigências da autenticaçao NTLM ou Kerberos:

(*) Esta configuração específica é suportada: o usuário 4D remoto é uma conta local em uma máquina que pertence ao mesmo AD que 4D Server. Neste caso, o parâmetro dominio é preenchido com o nome da máquina 4D Server. Note que o  suporte depende das configurações atuais do usuário: se não estiver disponível, strings vazias são retornadas.

(**) se todas as exigências  Kerberos forem respeitadas mas o comando  Current client authentication retornar "NTLM" em protocolo, signfica que enfrenta uma das situaçoes abaixo:

• a sintaxe SPN não é válida, ou seja, não respeita  limites impostos por Microsoft.
• ou, o SPN tem duplicatas em  AD. Este problema necessida ser resolvido pelo administrador AD.

Nota: uma sintaxe válida não significa que a declaração  SPN seja coreta, em particular, se o SPN não existir em AD, Current client authentication   retorna uma string vazia.