Definições de Entrada de Configuração de Login do Sistema para o Java Authentication and Authorization Service

Utilize essa página para especificar uma lista de configurações de login do sistema JAAS (Java Authentication and Authorization Service).

Para visualizar essa página do console administrativo, complete as etapas a seguir:

Clique em Segurança > Segurança Global.
Em Autenticação, clique em Java Authentication and Authorization Service > Logins do sistema.

Leia a documentação do Java Authentication and Authorization Service antes de começar a definir módulos de login adicionais para autenticação no tempo de execução de segurança do servidor de aplicativos. Não remova os seguintes módulos de login do sistema:

RMI_INBOUND
WEB_INBOUND
DEFAULT
RMI_OUTBOUND
SWAM
SWAM
wssecurity.IDAssertion
wssecurity.signature
wssecurity.PKCS7
wssecurity.PkiPath
wssecurity.UsernameToken
wssecurity.X509BST
LTPA
LTPA_WEB
Nota: O LTPA_WEB e o WEB_INBOUND executam funções semelhantes. É recomendado que use WEB_INBOUND pois ele é o mais novo dos módulos de login do sistema.
DESERIALIZE_ASYNCH_CONTEXT

ICSF

Processa pedidos de login quando o ICSF (Integrated Cryptographic Services Facility) é utilizado como o mecanismo de autenticação.

RMI_INBOUND, WEB_INBOUND, DEFAULT

Processa pedidos de login de entrada para Chamada de Método Remoto (RMI), aplicativos da Web e a maioria dos outros protocolos de login.

RMI_INBOUND: Esta configuração de login manipula logins para pedidos RMI de entrada. Geralmente, esses logins são pedidos para acesso autenticado aos arquivos EJB (Enterprise JavaBeans). Ao utilizar o conector RMI, esses logins podem ser pedidos para JMX (Java Management Extensions).
WEB_INBOUND: Esta configuração de login trata os logins para pedidos do aplicativo da Web, incluindo servlets e arquivos JavaServer Pages (JSP). Esta configuração de login pode interagir com a saída gerada a partir de um TAI (Trust Association Interceptor), se configurado. O Subject que é transmitido na configuração de login WEB_INBOUND pode conter objetos que são gerados pelo TAI.
DEFAULT: Esta configuração de login manipula os logins para pedidos de entrada que são feitos pela maioria dos outros protocolos e autenticações internas.

Essas três configurações de login transmitirão as seguintes informações de retorno de chamada, que são manipuladas pelos módulos de login dentro dessas configurações. Esses retornos de chamada não são transmitidos ao mesmo tempo. No entanto, a combinação desses retornos de chamada determina como o servidor de aplicativos autentica o usuário.

Retorno de Chamada

callbacks[0] = new javax.security.auth.callback.
NameCallback("Username:");

Responsabilidade

Coleta o nome do usuário fornecido durante um login. Estas informações podem ser o nome do usuário dos seguintes tipos de logins:

Login de nome de usuário e senha, que é conhecido como autenticação básica.
Nome de usuário somente para asserção de identidade sem uma senha.

Retorno de Chamada: callbacks[1] = new javax.security.auth.callback.
PasswordCallback("Password:", false);
Responsabilidade: Coleta a senha fornecida durante um login. Uma senha de null é permitida, e é usada para suportar asserção de identidade.

Retorno de Chamada: callbacks[2] = new com.ibm.websphere.security.auth.callback.
WSCredTokenCallbackImpl("Credential Token:");
Responsabilidade: Coleta o token LTPA (Lightweight Third Party Authentication) ou outro tipo de token durante um login. Tipicamente, estas informações estão presentes quando um nome do usuário e uma senha estão ausentes.

Retorno de Chamada

callbacks[3] = new com.ibm.wsspi.security.auth.callback.
WSTokenHolderCallback("Authz Token List:");

Responsabilidade

Coleta a lista ArrayList dos objetos TokenHolder que são retornados da chamada para o WSOpaqueTokenHelper. O retorno de chamada utiliza o método createTokenHolderListFromOpaqueToken com o token de autorização CSIv2 (Common Secure Interoperability version 2) como entrada.

Restrição: Este retorno de chamada está presente apenas quando a opção Propagação de Atributo de Segurança está ativada e este login é um login de propagação. Em um login de propagação, os atributos de segurança suficientes são propagados com o pedido para impedir o acesso ao registro do usuário para atributos adicionais. Você deve ativar a propagação do atributo de segurança para a autenticação de entrada e de saída.

É possível ativar a opção Propagação do Atributo de Segurança para autenticação de saída CSIv2, executando as seguintes etapas:

Clique em Segurança > Segurança Global.
Em Autenticação, expanda Segurança RMI/IIOP e clique em Autenticação de Saída CSIv2.
Ative a opção Propagação do Atributo de Segurança.

É possível ativar a opção Propagação do Atributo de Segurança para autenticação de entrada CSIv2, executando as seguintes etapas:

Clique em Segurança > Segurança Global.
Em Autenticação, expanda Segurança RMI/IIOP e clique em Autenticação de Entrada CSIv2.
Ative a opção Propagação do Atributo de Segurança.

Nas configurações de login do sistema, o servidor de aplicativos autentica o usuário com base nas informações que são coletadas pelos retornos de chamada. No entanto, um módulo de login personalizado não precisa agir em nenhum desses retornos de chamada. A lista a seguir explica as combinações típicas desses retornos de chamadas:

Apenas o retorno de chamada callbacks[0] = new javax.security.auth.callback.NameCallback("Username:");
Esse retorno ocorre para a asserção de identidade CSIv2, logins de certificado X509 da Web e CSIv2, logins do Trust Association Interceptor estilo antigo e assim por diante. Nos logins de certificado X509 da Web e CSIv2, o servidor de aplicativos mapeia o certificado para um nome de usuário. Este retorno de chamada é utilizado por qualquer tipo de login que estabelece confiança apenas com o nome do usuário.
Ambos os retornos de chamadas callbacks[0] = new javax.security.auth.callback.NameCallback("Username:"); e callbacks[1] = new javax.security.auth.callback.PasswordCallback("Password:", false);.
Esta combinação de retornos de chamada é típica de logins de autenticação básica. A maioria das autenticações de usuário ocorre utilizando-se esses dois retornos de chamada.
Apenas o callbacks[2] = new com.ibm.websphere.security.auth.callback.WSCredTokenCallbackImpl("Credential Token:");
Este retorno de chamada é utilizado para validar um token LTPA (Lightweight Third Party Authentication). Essa validação normalmente ocorre durante uma SSO (Conexão Única) ou login de recebimento de dados. Sempre que um pedido é originado a partir de um servidor de aplicativos, em vez de um cliente puro, o token LTPA flui para o servidor de destino. Para SSO (Conexão Única), o token LTPA é recebido no cookie e o token é utilizado para efetuar login. Se um módulo de login customizado precisar do nome do usuário de um token LTPA, o módulo poderá utilizar o seguinte método para recuperar o ID exclusivo do token:
com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
validateLTPAToken(byte[])
Depois de recuperar o ID exclusivo, utilize o seguinte método para obter o nome do usuário:
com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
getUserFromUniqueID(uniqueID)

Importante: A qualquer momento, um módulo de login customizado é conectado antes dos módulos de login do servidor de aplicativos e altera a identidade utilizando um serviço de mapeamento de credenciais; é importante que esse módulo de login valide o token LTPA, se estiver presente. A chamada do método a seguir é suficiente para validar a confiança no token LTPA:
com.ibm.wsspi.security.token.WSSecurityPropagationHelper.
validateLTPAToken(byte[])
O servidor de recebimento deve ter as mesmas chaves LTPA que o servidor de envio para que esta validação seja bem-sucedida. Uma exposição de segurança é possível se você não validar este token LTPA, quando presente.
Uma combinação de quaisquer dos retornos de chamadas mencionados anteriormente mais o retorno de chamada callbacks[3] = new com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback("Authz Token List:");.
Este retorno de chamada indica que alguns atributos propagados chegaram no servidor. Os atributos propagados ainda requerem um dos seguintes métodos de autenticação:
- callbacks[0] = new javax.security.auth.callback.
  NameCallback("Username:");
- callbacks[1] = new javax.security.auth.callback.
  PasswordCallback("Password:", false);
- callbacks[2] = new com.ibm.websphere.security.auth.callback.
  WSCredTokenCallbackImpl("Credential Token:");
Se os atributos forem incluídos no Subject de um simples cliente, os retornos de chamada NameCallback e PasswordCallback autenticarão as informações e os objetos serializados no portador do token serão incluídos no Subject autenticado.
Se a asserção e a propagação de identidade do CSIv2 estiverem ativadas, o servidor de aplicativos utilizará o retorno de chamada NameCallback e o portador do token, que contém todos os atributos propagados, para desserializar a maioria dos objetos. O servidor de aplicativos utiliza o retorno de chamada NameCallback porque a confiança é estabelecida com os servidores que você indica na lista de servidores confiáveis do CSIv2. Para especificar servidores confiáveis, conclua as seguintes etapas:
1. Clique em Segurança > Segurança Global.
2. Em Autenticação, clique em Autenticação de Entrada CSIv2.
Um módulo de login customizado precisa manipular a serialização customizada. Para obter informações adicionais, consulte "Propagação do Atributo de Segurança" no centro de informações.

Além dos retornos de chamada que estão previamente definidos, a configuração de login WEB_INBOUND pode conter apenas os seguintes retornos de chamada adicionais:

Retorno de Chamada: callbacks[4] = new com.ibm.websphere.security.auth.callback.
WSServletRequestCallback("HttpServletRequest:");
Responsabilidade: Coleta o objeto do pedido do servlet HTTP, se for apresentado. Este retorno de chamada permite que os módulos de login recuperem informações do pedido do HTTP para serem utilizadas durante o login.

Retorno de Chamada: callbacks[5] = new com.ibm.websphere.security.auth.callback.
WSServletResponseCallback("HttpServletResponse:");
Responsabilidade: Coleta o objeto de resposta do servlet HTTP, se for apresentado. Este retorno de chamada permite que os módulos de login incluam informações na resposta do HTTP como resultado do login. Por exemplo, os módulos de login podem incluir o cookie SingleSignonCookie na resposta.

Retorno de Chamada: callbacks[6] = new com.ibm.websphere.security.auth.callback.
WSAppContextCallback("ApplicationContextCallback:");
Responsabilidade: Coleta o contexto do aplicativo da Web usado durante o login. Esse retorno consiste em um hashtable, que se estiver presente conterá o nome do aplicativo e o endereço da Web redirecionado.
Retorno de Chamada: callbacks[7] = new WSRealmNameCallbackImpl("Realm Name:", <default_realm>);
Responsabilidade: Coleta o nome da região para as informações de login. As informações da região podem nem sempre ser fornecidas e devem ser consideradas como a região atual se não for fornecida.
Retorno de Chamada: callbacks[8] = new WSX509CertificateChainCallback("X509Certificate[]:");
Responsabilidade: Se a origem de login for um X509Certificate de autenticação de cliente SSL, esse retorno de chamada contém o certificado que foi validado por SSL. O ltpaLoginModule chama as mesmas funções de mapeamento que em releases anteriores. Depois de transmitido para o login, ele fornece um módulo de login customizado com a oportunidade de mapear o certificado de maneira customizada. Em seguida, desempenha login em uma tabela hash (consulte o link relacionado, Módulo de login customizado para mapeamento de entrada, para obter um exemplo de um login de tabela hash.).

Se desejar usar a propagação do atributo de segurança com a configuração de login WEB_INBOUND, será possível ativar a opção Propagação do atributo de segurança de entrada da Web no painel de conexão Única.

Clique em Segurança > Segurança Global.
Sob Autenticação, expanda Segurança da Web e clique em SSO (Conexão Única).
Selecione a opção Propagação do Atributo de Segurança de Entrada da Web.

Os seguintes módulos de login são predefinidos para as configurações de login de sistema RMI_INBOUND, WEB_INBOUND e DEFAULT. É possível incluir módulos de login personalizados antes, entre ou após qualquer um destes módulos de login, mas não pode remover estes módulos de login predefinidos:

com.ibm.ws.security.server.lm.ltpaLoginModule
Executa o login primário quando a propagação de atributo está ativada ou desativada. Um login primário utiliza informações de autenticação normais como um ID do usuário e uma senha, um token LTPA ou um TAI (Trust Association Interceptor) e um DN (Nome Distinto) de certificado. Se algum dos seguintes cenários for verdadeiro, este módulo de login não será utilizado e o módulo com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule executará o login principal:
- O objeto java.util.Hashtable com os atributos do usuário requeridos está contido no Subject.
- O objeto java.util.Hashtable com os atributos do usuário requeridos está presente no Mapa Hash sharedState do LoginContext.
- O retorno de chamada WSTokenHolderCallback está presente sem uma senha especificada. Se um nome do usuário e uma senha estiverem presentes com um retorno de chamada WSTokenHolderCallback, que indica informações propagadas, é provável que o pedido seja originado de um cliente puro ou de um servidor a partir de uma região diferente que mapeou a identidade existente para um ID do usuário e senha.
com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule
Este módulo de login executa o login principal utilizando as informações de autenticação normais se alguma das seguintes condições for verdadeira:
- Um objeto java.util.Hashtable com atributos do usuário requeridos está contido no Subject.
- Um objeto java.util.Hashtable com atributos do usuário requeridos está presente no sharedState HashMap do contexto LoginContext.
- O retorno de chamada WSTokenHolderCallback está presente sem um retorno de chamada PasswordCallback.
Quando o objeto java.util.Hashtable estiver presente, o módulo de login mapeará os atributos do objeto em um Subject válido. Quando o retorno de chamada WSTokenHolderCallback está presente, o módulo de login desserializa o objetos do token de byte e gera novamente o conteúdo serializado do Subject. A tabela hash java.util.Hashtable tem precedência sobre todos os outros formatos de login. Tome cuidado para evitar a suplicação ou substituição do que o servidor de aplicativos pode ter propagado anteriormente.

Ao especificar uma tabela hash java.util.Hashtable para ter precedência sobre outras informações sobre autenticação, o módulo de login customizado já deve ter verificado o token LTPA, se presente, para estabelecer confiança suficiente. O módulo de login customizado pode utilizar o método com.ibm.wsspi.security.token.WSSecurityPropagationHelper.validationLTPAToken(byte[]) para validar o token LTPA presente no retorno de chamada WSCredTokenCallback. A não-validação do token LTPA apresenta um risco à segurança.

Para obter informações adicionais sobre como incluir uma hashtable que contém os atributos bem conhecidos e bem formados usados pelo servidor de aplicativos, como informações de login suficientes, consulte "Configurando Mapeamento de Identidade de Entrada" no centro de informações.

RMI_OUTBOUND

Processa pedidos RMI (Remote Method Invocation) que são enviados para outro servidor quando as propriedades com.ibm.CSI.rmiOutboundLoginEnabled ou com.ibm.CSIOutboundPropagationEnabled são verdadeiras.

Essas propriedades são enviadas no painel de autenticação do CSIv2. Para acessar o painel, conclua as seguintes etapas:

Clique em Segurança > Segurança Global.
Em Autenticação, expanda Segurança RMI/IIOP e clique em Autenticação de Saída CSIv2.

Para definir a propriedade com.ibm.CSI.rmiOutboundLoginEnabled, selecione Mapeamento de Saída Customizado. Para definir a propriedade com.ibm.CSIOutboundPropagationEnabled, selecione a opção Propagação de Atributo de Segurança.

Esta configuração de login determina os recursos de segurança do servidor de destino e seu domínio de segurança. Quando o servidor de aplicativos envia informações sobre autenticação e autorização através do recebimento de dados, o servidor de aplicativos remove a necessidade de acessar o registro do usuário novamente e consultar os atributos de segurança do usuário para propósitos de autorização. Além disso, quaisquer objetos personalizados que são incluídos no servidor de envio estão presentes no Subject no servidor de recebimento de dados.

O seguinte retorno de chamada está disponível na configuração de login RMI_OUTBOUND. É possível utilizar o objeto com.ibm.wsspi.security.csiv2.CSIv2PerformPolicy que é retornado por esse retorno de chamada para consultar a política de segurança para esse pedido de saída específico. Essa consulta pode ajudar a determinar se a região de destino é diferente da região atual e se o servidor de aplicativos deve mapear a região. Para obter informações adicionais, consulte "Configurando o Mapeamento de Saída para uma Região de Destino Diferente" no centro de informações.

Retorno de Chamada

callbacks[0] = new WSProtocolPolicyCallback("Protocol Policy Callback: ");

Responsabilidade

Fornece informações sobre a política específica do protocolo para os módulos de login nesta chamada de saída. Essas informações são utilizadas para determinar o nível de segurança, incluindo a região de destino, os requisitos de segurança de destino e os requisitos de segurança unidos.

O método a seguir obtém a política CSIv2PerformPolicy deste módulo de login específico:

csiv2PerformPolicy = (CSIv2PerformPolicy)
((WSProtocolPolicyCallback)callbacks[0]).getProtocolPolicy();

Um protocolo diferente do RMI pode possuir um tipo diferente de objeto de política.

O módulo de login a seguir está predefinido na configuração de login RMI_OUTBOUND. É possível incluir módulos de login personalizados antes, entre ou depois de qualquer um desses módulos de login, porém você não pode remover esses módulos de login predefinidos.

com.ibm.ws.security.lm.wsMapCSIv2OutboundLoginModule

Recupera os seguintes tokens e objetos antes de criar um byte opaco que é enviado a outro servidor utilizando a camada de token de autorização CSIv2 (Common Secure Interoperability Version 2):

Implementações com.ibm.wsspi.security.token.Token redirecionáveis a partir do Subject
Objetos customizados serializáveis a partir do Subject
Tokens de propagação a partir do encadeamento

É possível utilizar um módulo de login personalizado anterior a esse módulo de login para executar o mapeamento de credenciais. No entanto, recomenda-se que o módulo de login altere o conteúdo do Subject transmitido durante a fase de login. Se esta recomendação for seguida, os módulos de login serão processados após este módulo de login atuar no conteúdo do novo Subject.

Para obter informações adicionais, consulte "Configurando o Mapeamento de Saída para uma Região de Destino Diferente" no centro de informações.

SWAM

Processa pedidos de login em um ambiente de servidor único quando o SWAM (Simple WebSphere Authentication Mechanism) é utilizado como o método de autenticação.

O SWAM não suporta credenciais que podem ser redirecionadas. Quando o SWAM for o método de autenticação, o servidor de aplicativos não poderá enviar pedidos de servidor para servidor. Nesse caso, você deve utilizar o LTPA.

Nota: A configuração de login do SWAM está obsoleta e será removida em um release futuro.

Nota: SWAM está obsoleto no servidor de aplicativos Versão 8.5 e será removido em um release futuro.

SWAM

Essa configuração de login permite mapear um ID em um registro do usuário do LDAP (Lightweight Directory Access Protocol) para um ID do usuário do SAF (System Authorization Facility))

Nota: SWAM está obsoleto no servidor de aplicativos Versão 8.5 e será removido em um release futuro.

wssecurity.IDAssertion

Processa os pedidos de configuração de login para Segurança de Serviços da Web usando a asserção de identidade.

Essa configuração de login é para aplicativos Web Services Security Draft 13 JAX-RPC (Versão 5.x). Para obter informações adicionais, consulte "Identificar Método de Autenticação de Asserção" no centro de informações.

wssecurity.IDAssertionUsernameToken

Processa os pedidos de configuração de login para Segurança de Serviços da Web usando a asserção de identidade.

Essa configuração de login é para aplicativos Web Services Security V1.0 JAX-RPC.

A propriedade customizada com.ibm.wsspi.wssecurity.auth.module.IDAssertionLoginModule.disableUserRegistryCheck pode ser configurada para o módulo de login JAAS IDAssertionUsernameToken. Esta propriedade é uma opção para o módulo de login JAAS de asserção de identidade de Segurança de Serviços da Web, wssecurity.IDAssertionUsernameToken. A propriedade indica que o módulo de login não deve executar uma verificação de registro do usuário ao processar um token de identidade de entrada.

wssecurity.PKCS7

Verifica um certificado X.509 com uma Certificate Revocation List em um objeto PKCS7 (Public Key Cryptography Standards #7).

Esta configuração de login é para sistemas da Versão 6.0.x.

wssecurity.PkiPath

Verifica um certificado X.509 com um caminho de PKI (Infra-estrutura da Chave Pública).

Esta configuração de login é para sistemas da Versão 6.0.x.

wssecurity.signature

Processa pedidos de configuração de login para Segurança de Serviços da Web usando a validação de assinatura digital.

Esta configuração de login é para sistemas da Versão 5.x.

wssecurity.UsernameToken

Verifica a autenticação básica (nome do usuário e senha).

Quando você utiliza o tempo de execução JAX-RPC, as seguintes propriedades customizadas podem ser configuradas para o módulo de login JAAS UsernameToken:

A propriedade customizada com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule.disableUserRegistryCheck pode ser configurada para o módulo de login JAAS UsernameToken. Esta propriedade é uma opção para o módulo de login JAAS UsernameToken de Segurança de Serviços da Web, com.ibm.wsspi.wssecurity.auth.module.UsernameLoginModule. A propriedade indica que o módulo de login não deve executar uma verificação de registro do usuário ao processar um token de nome de usuário de entrada.

wssecurity.X509BST

Verifica um BST (Token de Segurança Binário) X.509 verificando a validade do certificado e o caminho do certificado.

Esta configuração de login é para sistemas da Versão 6.0.x.

LTPA_WEB

Processa pedidos de login para componentes no contêiner da Web como servlets e arquivos JavaServer pages (JSP).

O módulo de login com.ibm.ws.security.web.AuthenLoginModule é predefinido na configuração de login LTPA. É possível incluir os módulos de login personalizados antes ou depois desse módulo na configuração de login LTPA_WEB.

A configuração de login LTPA_WEB pode processar o objeto HttpServletRequest, o objeto HttpServletResponse e o nome do aplicativo da Web que são transmitidos usando um manipulador de retorno de chamada. Para obter informações adicionais, consulte "Exemplo: Customizando uma Configuração de Autenticação e de Logon do Java Authentication and Authorization Service do Lado do Servidor" no centro de informações.

LTPA

Processa pedidos de login que não são manipulados pela configuração de login LTPA_WEB.

Esta configuração de login é usada pelo WebSphere Application Server Versão 6.1 e versões anteriores.

O módulo de login com.ibm.ws.security.server.lm.ltpaLoginModule é predefinido na configuração de login LTPA. É possível incluir os módulos de login personalizados antes ou depois desse módulo na configuração de login do LTPA. Para obter informações adicionais, consulte "Exemplo: Customizando uma Configuração de Autenticação e de Logon do Java Authentication and Authorization Service do Lado do Servidor" no centro de informações.

LTPA_WEB

Processa pedidos de login para componentes no contêiner da Web como servlets e arquivos JavaServer pages (JSP).

DESERIALIZE_ASYNCH_CONTEXT

Processa solicitações de login para beans assíncronos.

A configuração de DESERIALIZE_ASYNCH_CONTEXT é usada apenas para beans assíncronos. O planejador utiliza o gerenciador de alarme de beans assíncronos para "Início Adiado", o que permite a serialização e a desserialização do contexto de J2EE. Esta configuração de login é usada ao usar beans assíncronos, Planejador e Cronômetros de EJB.

CAUTION:

A configuração de login de DESERIALIZE_ASYNCH_CONTEXT possui uma limitação. Qualquer operação que requer validação de token nos lognModules configurados na configuração de login de DESERIALIZE_ASYNC_CONTEXT pode resultar na API lançando repetidamente a TokenExpiredException.

Nome do arquivo: usec_sysjaas.html