Utilize essa página para especificar os recursos que um servidor suporta para um cliente que esteja acessando seus recursos.
Para visualizar essa página do console administrativo, clique em Segurança > Protocolo de Autenticação > Autenticação de Entrada CSI.
Utilize definições da autenticação de entrada CSI para configurar o tipo de informações de autenticação contidas em um pedido ou transporte de entrada.
Os recursos de autenticação incluem três camadas de autenticação que podem ser utilizadas simultaneamente:
Guia Configuração
Na camada de mensagem, ocorre a autenticação básica (ID do usuário e senha). Esse tipo de autenticação normalmente envolve o envio de um ID do usuário e uma senha do cliente para o servidor para autenticação. Essa autenticação também envolve a delegação de um token de credencial de uma credencial já autenticada, desde que o tipo de credencial seja encaminhado (por exemplo, ao LTPA (Lightweight Third Party Authentication)). Se você selecionar Autenticação Básica para o servidor, especifique a autenticação do ID do usuário e da senha, assim como a autenticação baseada no token.
Ao selecionar Autenticação Básica, decida se ela é Requerida ou Suportada. Selecionar Requerida indica que somente clientes configurados para autenticar nesse servidor através da camada de mensagem pode chamar pedidos no servidor. Selecionar Suportada indica que esse servidor aceita autenticação básica. No entanto, outros métodos de autenticação podem ocorrer, se configurados, e pedidos anônimos serão aceitos. Selecione Nunca para indicar que o servidor não está configurado para aceitar a autenticação da camada de mensagem de nenhum cliente.
| Tipo de dados: | String |
Na camada de transporte, ocorre a autenticação de certificado do cliente SSL (Secure Sockets Layer). Na camada de mensagem, é executada a autenticação básica (ID do usuário e senha). A autenticação de certificado de cliente geralmente executa melhor do que a autenticação de camada de mensagem, mas requer algumas etapas de configuração adicionais. Essas etapas adicionais envolvem a verificação de que o servidor possui o certificado do assinante de cada cliente ao qual está conectado. Se o cliente utilizar uma CA (Autoridade de Certificação) para criar seu certificado pessoal, você precisará somente do certificado raiz da CA na seção de assinante do servidor do arquivo de confiança do SSL.
Quando o certificado é autenticado para um registro de usuário LDAP (Lightweight Directory Access Protocol), o DN (Nome Distinto) é mapeado com base no filtro especificado ao configurar o LDAP. Quando o certificado é autenticado para um registro de usuário LocalOS, o primeiro atributo do DN no certificado (geralmente o nome comum) é mapeado para o ID do usuário no registro. A identidade dos certificados de cliente é utilizada somente se nenhuma outra camada de autenticação for apresentada para o servidor.
Ao selecionar a Autenticação de Certificado de Cliente, decida se ela é Requerida ou Suportada. Ao selecionar Requerida, somente os clientes configurados para autenticação nesse servidor através de certificados de cliente SSL poderão chamar pedidos no servidor. Ao selecionar Suportada, esse servidor aceita a autenticação de certificado de cliente SSL, no entanto, outros métodos de autenticação podem ocorrer (se configurados) e pedidos anônimos serão aceitos. Ao selecionar Nunca, o servidor não será configurado para aceitar autenticação de certificado de cliente de nenhum cliente.
| Tipo de Dados | String |
A asserção de identidade é executada na camada de atributo e é aplicável somente nos servidores. O proprietário determinado no servidor é baseado nas regras de precedência. Se a asserção de identidade for executada, a identidade sempre será derivada do atributo. Se a autenticação básica for executada sem asserção de identidade, a identidade sempre será derivada da camada de mensagem. Por fim, se a autenticação de certificado de cliente SSL for executada sem autenticação básica ou asserção de identidade, a identidade será derivada da camada de transporte.
A identidade assegurada é a credencial de chamada determinada pelo modo Executar Como para o bean corporativo. Se o modo Executar Como for Cliente, a identidade será a identidade do cliente. Se o modo Executar Como for Sistema, a identidade será a identidade do servidor. Se o modo Executar Como for Especificado, a identidade será a especificada. O servidor de recepção recebe a identidade em um token de identidade e também recebe a identidade do servidor de envio em um token de autenticação do cliente. O servidor de recepção valida a identidade do servidor de envio como uma identidade confiável através da caixa de entrada IDs de Servidor Confiáveis. .
Ao autenticar para um registro de usuário do S.O. Local, todos os tipos de token de identidade são mapeados para o campo ID do usuário do registro de usuário ativo. Para um token de identidade ITTPrincipal, esse token é mapeado um-a-um com campos de ID do usuário. Para um token de identidade ITTDistinguishedName, o valor do primeiro sinal de igual é mapeado para o campo ID do usuário. Para um token de identidade ITTCertChain, o valor do primeiro sinal de igual do nome distinto é mapeado para o campo de ID do usuário,
Ao autenticar para um registro de usuário LDAP, os filtros LDAP determinam como uma identidade do tipo ITTCertChain e ITTDistinguishedName é mapeada para o registro. Se o tipo do token for ITTPrincipal, o proprietário é mapeado para o campo UID no registro LDAP.
| Tipo de dados: | String |
Utilize essa lista para decidir rapidamente se o servidor é confiável. Mesmo se o servidor estiver na lista, o servidor de envio ainda precisa ser autenticado com o servidor de recepção para aceitar o token de identidade do servidor de envio.
| Tipo de Dados | String |
O primeiro contato entre um cliente e um servidor deve fazer a autenticação completa. No entanto, todos os contatos subseqüentes com sessões válidas reutilizam as informações sobre segurança. O cliente transmite um ID de contexto para o servidor e o ID é utilizado para consultar a sessão. É feito o escopo do ID de contexto para a conexão, o que garante exclusividade. Sempre que a sessão de segurança for inválida e a nova tentativa de autenticação estiver ativada (está por padrão), o interceptor de segurança do lado do cliente invalida a sessão do lado do cliente e envia novamente o pedido sem o conhecimento do usuário. Essa situação pode ocorrer se a sessão não existir no servidor (o servidor falhou e retomou a operação). Quando esse valor for desativado, cada chamada de método precisará ser autenticada novamente.
| Tipo de Dados | String |