Suporte do Mecanismo de Autenticação Kerberos (KRB5) para Segurança
O mecanismo de autenticação Kerberos permite interoperabilidade com outros aplicativos (como .NET, DB2 e outros) que suportam autenticação Kerberos. Ele fornece soluções de conexão única (SSO) interoperáveis de ponta a ponta e preserva a identidade do solicitante original.
- O que é Kerberos?
- Os benefícios de ter o Kerberos como mecanismo de autenticação
- Autenticação Kerberos em um ambiente de região única do Kerberos
- Autenticação Kerberos em um ambiente de região cruzada ou confiável do Kerberos
- Coisas a Considerar Antes de Configurar o Kerberos como o Mecanismo de Autenticação para WebSphere Application Server
- Informações de Suporte para Autenticação do Kerberos
- Configurando o Kerberos como Mecanismo de Autenticação do WebSphere Application Server
- Configurando o Kerberos como Mecanismo de Autenticação do Cliente Java Puro
O que é Kerberos?
O Kerberos tem resistindo ao teste do tempo e já está na versão 5.0. O Kerberos conta com amplo suporte de diversas plataformas (por exemplo, em Windows, Linux, Solaris, AIX e z/OS) em parte porque o código-fonte do Kerberos é disponibilizado para download gratuitamente pelo MIT (Massachusetts Institute of Technology) onde ele foi originalmente criado.
O Kerberos é composto por três partes: um cliente, um servidor e um terceiro confiável conhecido como Kerberos KDC (Key Distribution Center). O KDC fornece serviços de autenticação e concessão de registro.
O KDC mantém um banco de dados ou repositório de contas de usuário para todos os proprietários de segurança em sua região. Muitas distribuições Kerberos utilizam repositórios baseados em arquivo para o proprietário Kerberos e o DB de política, enquanto outros utilizam o LDAP (Lightweight Directory Access Protocol) como repositório.
O Kerberos não suporta qualquer noção de grupos (isto é, grupos de iKeys ou grupos de usuários ou proprietários). O KDC mantém uma chave de longo prazo para cada proprietário em seu banco de dados de contas. Essa chave de longo prazo deriva-se da senha do proprietário. Somente o KDC e o usuário que o proprietário representa deverão saber qual é a chave de longo prazo ou a senha.
Os benefícios de ter o Kerberos como mecanismo de autenticação
Os benefícios de ter o Kerberos como o mecanismo de autenticação no WebSphere Application Server incluem o seguinte:
- O protocolo Kerberos é um padrão. Isso permite interoperabilidade com outros aplicativos (como .NET, DB2 e outros) que suportam autenticação Kerberos. Ele fornece soluções de conexão única (SSO) interoperáveis de ponta a ponta e preserva a identidade do solicitante original.
- Ao utilizar a autenticação Kerberos, a senha em texto simples do usuário nunca sai da máquina do usuário. O usuário autentica e obtém um TGT (Ticket Granting Ticket) Kerberos de um KDC utilizando um valor hash unidirecional da senha do usuário. O usuário obtém também um registro de serviço Kerberos do KDC utilizando o TGT. O ticket de serviço do Kerberos que representa a identidade do cliente é enviado para WebSphere Application Server para autenticação.
- Um cliente Java pode participar no Kerberos SSO usando o cache de credenciais do Kerberos para autenticar-se no WebSphere Application Server.
- J2EE, serviço da Web, .NET e clientes do navegador da Web que usam o protocolo
HTTP podem usar o token do Simple and Protected GSS-API Negotiation
Mechanism (SPNEGO) para autenticar-se no WebSphere Application Server e participar em SSO usando a autenticação da Web do SPNEGO. Suporte para SPNEGO como o serviço de autenticação da Web
é novo para esse release do WebSphere Application Server.
Leia sobre Conexão Única para Solicitações de HTTP Usado a Autenticação da Web SPNEGO para obter informações adicionais.
- O WebSphere Application Server pode suportar mecanismos de autenticação do Kerberos e do Lightweight Third-Party Authentication (LTPA) ao mesmo tempo.
- A comunicação entre servidores utilizando autenticação Kerberos é fornecida.
Autenticação Kerberos em um ambiente de região única do Kerberos
O WebSphere Application Server suporta autenticação do Kerberos em um ambiente de região única do Kerberos, conforme mostrado na figura a seguir:

Quando o WebSphere Application Server recebe um token do Kerberos ou do SPNEGO para autenticação, ele usa o serviço do Kerberos principal (SPN) para estabelecer um contexto de segurança com um solicitante. Se um contexto de segurança for estabelecido, o módulo de login do Kerberos do WebSphere extrairá uma credencial de delegação de GSS do cliente, criará um token de autenticação do Kerberos com base na credencial do Kerberos e os colocará no objeto cliente com outros tokens.
Se o servidor precisar usar um servidor de recebimento de dados ou recursos backend, ele utilizará a credencial de delegação de GSS. Se um servidor de recebimento de dados não suportar autenticação Kerberos, o servidor utilizará o token LTPA em vez do token Kerberos. Se um cliente não incluir uma credencial de delegação de GSS no pedido, o servidor utilizará o token LTPA para o servidor de recebimento de dados. O token de autenticação e o proprietário Kerberos são propagados ao servidor de recebimento de dados como parte do recurso de propagação de atributos de segurança.
Se o WebSphere Application Server e o KDC não usarem o mesmo registro do usuário, então um módulo de login customizado JAAS poderá ser necessário para mapear o nome do Kerberos principal para o nome do usuário do WebSphere.
Autenticação Kerberos em um ambiente de região cruzada ou confiável do Kerberos
O WebSphere Application Server suporta também autenticação do Kerberos em um ambiente de região cruzada ou confiável do Kerberos, conforme mostrado na figura a seguir:

Quando o WebSphere Application Server recebe um token do Kerberos ou do SPNEGO para autenticação, ele usa o serviço do Kerberos principal (SPN) para estabelecer um contexto de segurança com um solicitante. Se um contexto de segurança for estabelecido, o módulo de login do Kerberos do WebSphere sempre extrairá uma credencial de delegação de GSS do cliente e um registro Kerberos e os colocará no objeto cliente com outros tokens.
Se o servidor precisar utilizar um servidor de recebimento de dados ou recursos backend, ele utilizará a credencial de delegação de GSS do cliente. Se um servidor de recebimento de dados não suportar autenticação Kerberos, o servidor utilizará o token LTPA em vez do token Kerberos. Se um cliente não incluir uma credencial de delegação de GSS no pedido, o servidor utilizará o token LTPA para o servidor de recebimento de dados. O token de autenticação e o proprietário Kerberos são propagados ao servidor de recebimento de dados como parte do recurso de propagação de atributos de segurança.
Se o WebSphere Application Server e o KDC não usarem o mesmo registro do usuário, então um módulo de login customizado JAAS poderá ser necessário para mapear o nome do Kerberos principal para o nome do usuário do WebSphere.
Neste release do WebSphere Application Server, os diversos domínios novos de segurança suportam Kerberos apenas no nível de célula. Todos os WebSphere Application Server devem ser usados pela mesma região do Kerberos. Entretanto, os clientes ou os recursos backend (como DB2, servidor .NET e outros) que suportam autenticação Kerberos podem ter sua própria região do Kerberos. Somente autenticação ponto a ponto e transitiva entre regiões confiáveis são suportadas. As etapas a seguir devem ser executadas para regiões confiáveis do Kerberos:
- A configuração de região confiável do Kerberos deve ser executada em cada KDC do Kerberos. Consulte o Kerberos Administrator and User's guide para obter informações adicionais sobre como configurar uma região confiável do Kerberos.
- O arquivo de configuração do Kerberos poderá precisar listar a região confiável.
- Inclua as regiões confiáveis do Kerberos no console administrativo clicando em .
A figura a seguir mostra um cliente administrativo e Java que usa um cache de credenciais do Kerberos para autenticar-se no WebSphere Application Server com um token do Kerberos em uma região confiável do Kerberos:

- O cliente utilizará o cache de credenciais do Kerberos se ele existir.
- O cliente solicita um registro entre regiões (TGS_REQ) para a Região A no KDC da Região B utilizando o cache de credenciais do Kerberos.
- O cliente utiliza um registro entre regiões para solicitar o registro de serviço do Kerberos para server1 (TGS_REQ) no KDC da Região A.
- O token Kerberos retornado pelo KDC (TGS_REP ) é incluído no token de autenticação de mensagem do CSIv2 e enviado ao server1 para autenticação.
- O servidor chama Krb5LoginModuleWrapper para estabelecer o contexto de segurança com o cliente utilizando o SPN (Service Principal Name) do Kerberos do servidor e as chaves do arquivo krb5.keytab. Se o servidor estabelecer com êxito um contexto de segurança com o cliente, ele sempre extrairá os registros e a credencial de delegação de GSS do cliente e os colocará no objeto cliente.
- Opcionalmente, um Módulo de Login JAAS customizado poderá ser necessário se o KDC e o WebSphere Application Server não usarem o mesmo registro do usuário.
- O usuário é validado com o registro do usuário para WebSphere Application Server.
- Os resultados (êxito ou falha) são retornados ao cliente.
A figura a seguir mostra um cliente administrativo e Java que usa um nome e uma senha do Kerberos principal para autenticar-se no WebSphere Application Server com um token do Kerberos:

- O cliente obtém o registro de concessão (TGT) do Kerberos do KDC.
- O cliente obtém um registro de serviço do Kerberos para server1 (TGS_REQ) utilizando o TGT.
- O token Kerberos retornado pelo KDC (TGS_REP ) é incluído no token de autenticação de mensagem do CSIv2 e enviado ao server1 para autenticação.
- O servidor chama Krb5LoginModuleWrapper para estabelecer o contexto de segurança com o cliente utilizando o SPN (Service Principal Name) do Kerberos do servidor e as chaves do arquivo krb5.keytab. Se o servidor estabelecer com êxito um contexto de segurança com o cliente, ele sempre extrairá os registros e a credencial de delegação de GSS do cliente e os colocará no objeto cliente.
- Opcionalmente, um Módulo de Login JAAS customizado poderá ser necessário se o KDC e o WebSphere Application Server não usarem o mesmo registro do usuário.
- O usuário é validado com o registro do usuário para WebSphere Application Server.
- Os resultados são retornados ao cliente.
A figura a seguir mostra comunicações entre servidores:

Quando um WebSphere Application Server é iniciado, ele usa o ID do servidor e a senha para efetuar login no KDC e, em seguida, obtém o TGT. Em seguida, utiliza o TGT para solicitar um registro de serviço para comunicar-se com outro servidor. Se um WebSphere Application Server usa o ID do servidor interno em vez do ID do servidor e a senha, a comunicação servidor-para-servidor será feita usando um token do LTPA. Na figura anterior, os seguintes eventos ocorrem:
- WebSphere Application Server 1 chama um método, foo(), em um Enterprise JavaBeans (EJB) em execução no WebSphere Application Server 2.
- Server1 obtém um registro de serviço do Kerberos para Server2 (TGS_REQ) utilizando o TGT do Server1.
- Igual à etapa 2.
- O token Kerberos retornado por um KDC (TGS_REP) é incluído no token de autenticação de mensagem do CSIv2 e enviado ao Server2 para autenticação.
- Server2 chama o método acceptSecContext() para estabelecer contexto de segurança com server1 utilizando o SPN (Service Principal Name) do Kerberos do server2 e as chaves do arquivo krb5.keytab. Se o server2 estabelecer com êxito um contexto de segurança com o server1, ele sempre extrairá os registros e a credencial de delegação de GSS do server1 e os colocará no objeto.
- O ID do servidor é validado no registro do usuário do WebSphere.

Coisas a Considerar Antes de Configurar o Kerberos como o Mecanismo de Autenticação para WebSphere Application Server
O WebSphere Application Server suporta agora tokens do SPNEGO no cabeçalho de HTTP, tokens do Kerberos, tokens do LTPA e BasicAuth (GSSUP) para autenticação.
- A opção de credenciais Delegação ativada de Kerberos deve ser selecionada. Leia sobre Configurando Kerberos como o Mecanismo de Autenticação Utilizando o Console Administrativo para obter mais informações sobre essa opção.
- Um cliente deve obter um TGT (ticket-granting ticket) com sinalizadores que possam ser encaminhados, sinalizadores renovados e sinalizadores sem endereço para que um servidor de destino possa extrair uma credencial Kerberos de delegação do cliente e usá-lo para acessar o servidor de recebimento de dados.
- Um TGT de cliente que tem um endereço não pode ser usado para um servidor de recebimento de dados, cache Data replication service (DRS) e ambientes em cluster.
- Consulte as suas plataformas KDC de Kerberos para se certificar de que ele permite Kerberos de delegação de cliente.
- Para um aplicativo de longa execução, um cliente deve pedir um TGT com um sinalizador renovável para que um servidor de destino possa renovar o Kerberos de delegação.
- Para um aplicativo de longa execução, assegure-se de que o ticket Kerberos seja válido durante um período de tempo que seja no mínimo, igual ao período de execução do aplicativo. Por exemplo, se o aplicativo processar uma transação que dure 5 minutos, o ticket do Kerberos deverá ser válido por pelo menos 5 minutos.
- A autenticação do Kerberos e a autenticação da Web do SPNEGO são ambas suportadas para confianças de domínio cruzado do Active Directory dentro da mesma floresta.
- Para que um agente administrativo use o mecanismo de autenticação do Kerberos, ele deve trocar uma chave LTPA por um perfil do subsistema administrativo.
A seguinte propriedade customizada de segurança deve ser definida para true: com.ibm.websphere.security.krb.longLivedTicket.
- Se você planeja usar a credencial do Kerberos de delegação de cliente para autenticação de recebimento de dados, certifique-se de que o cliente possa solicitar um ticket de serviço que dure mais de 10 minutos. Se o tempo de vida da credencial do Kerberos de delegação de cliente for menor que 10 minutos, o servidor tentará renová-lo.
- O suporte do Kerberos de ponta a ponta completo com o Tivoli Access Manager está disponível usando os seguintes KDCs:
- z/OS
- Microsoft (região única ou múltipla)
- AIX,
- Linux
- Agora, é possível configurar e ativar as regiões cruzadas do Kerberos para WebSphere Application Server e o thin client.
- A função administrativa do WebSphere Application Server com
Kerberos é limitada ao seguinte:
- O mecanismo de autenticação preferencial para atividades de gerenciamento flexíveis é o mecanismo de autenticação Rivest Shamir Adleman (RSA) (por padrão).
- O Gerenciador de Tarefas configurado com o Kerberos como a autenticação administrativa não suporta regiões cruzadas de Kerberos. Elas devem estar na mesma região do Kerberos como nós registrados, ou ter a autenticação administrativa definida para RSA
- Enquanto a autenticação do Kerberos é suportada para clientes administrativos (wsadmin ou clientes Java) você deve usar a mesma região KDC como o WebSphere Application Server que ele administra. Caso contrário, um ID e senha do usuário são recomendados.
- A configuração de Kerberos e LTPA de célula mista não é suportada quando alguns dos nós forem nós do WebSphere Application Server Release 6.x ou anterior.
Informações de Suporte para Autenticação do Kerberos
- Regiões confiáveis externas de domínio que não estão nas mesmas florestas
- Região confiável de domínio na mesma floresta
- Região confiável de região do Kerberos
- Região confiável entre florestas
- Confianças externas da floresta
Configurando o Kerberos como Mecanismo de Autenticação do WebSphere Application Server
Configurando o Kerberos como Mecanismo de Autenticação do Cliente Java Puro
Usuários finais podem, opcionalmente, configurar o mecanismo de autenticação do Kerberos para o Cliente Java Puro. Leia sobre Configurando um Cliente Java para Autenticação do Kerberos para obter informações adicionais.