Segurança do Conector Java EE

A arquitetura do conector Java™ 2 Platform, Enterprise Edition (Java EE) define uma arquitetura padrão para conectar o J2EE ao Enterprise Information System (EIS) heterogêneo. Exemplos de EIS incluem sistemas ERP (Enterprise Resource Planning), de TP (Transaction Processing) de mainframe e de banco de dados.

A arquitetura de conector permite a um fornecedor de EIS fornecer um adaptador de recursos padrão para seu EIS. Um adaptador de recursos é um driver de software no nível do sistema que é utilizado por um aplicativo Java para conectar a um EIS. O adaptador de recurso se conecta a um servidor de aplicativos e fornece conectividade entre o EIS, o servidor de aplicativos e o aplicativo corporativo. Acessar as informações no EIS geralmente requer controle de acesso para evitar acessos não autorizados. Os aplicativos J2EE devem autenticar-se no EIS para abrir uma conexão.

A arquitetura de segurança do conector J2EE foi projetada para estender o modelo de segurança de ponta a ponta para aplicativos baseados em J2EE incluírem a integração com ambientes EIS. Um servidor de aplicativos e um EIS colaboram para assegurar a autenticação correta de um proprietário de recurso, o qual estabelece uma conexão com um EIS subjacente. A arquitetura do conector identifica os seguintes mecanismos como os mecanismos de autenticação comumente suportados, embora outros mecanismos possam ser definidos:
  • BasicPassword: O mecanismo de autenticação básico baseado na senha do usuário específico de um EIS.
  • [AIX Solaris HP-UX Linux Windows][IBM i]Kerbv5: Mecanismo de autenticação baseado no Kerberos Versão 5

Os aplicativos definem se devem usar a conexão gerenciada por aplicativo ou a conexão gerenciada por contêiner nos elementos resource-ref no descritor de implementação. Cada elemento resource-ref descreve uma ligação de referência de connection factory única. O elemento res-auth em um elemento resource-ref, cujo valor é Application ou Container, indica se o código do bean corporativo pode executar conexão ou se o servidor de aplicativos pode conectar-se ao gerenciador de recursos utilizando a configuração de mapeamento do proprietário. O elemento resource-ref é definido tipicamente no tempo de montagem do aplicativo com uma ferramenta de montagem. resource-ref também pode ser definido, ou redefinido, na hora da implementação.

Conexão Gerenciada do Aplicativo

Para acessar um sistema EIS, os aplicativos localizam um connection factory no namespace JNDI (Java Naming and Directory Interface) e chamam o método getConnection nesse objeto do connection factory. O método getConnection pode requerer um ID do usuário e um argumento de senha. Um aplicativo J2EE pode transmitir um ID de usuário e uma senha ao método getConnection que, subseqüentemente, transmite as informações para o adaptador de recursos. No entanto, a especificação de um ID de usuário e uma senha no código do aplicativo pode comprometer a segurança.

O ID do usuário e a senha, se codificados no código-fonte Java, estarão disponíveis para desenvolvedores e testadores da organização. Além disso, o ID do usuário e a senha serão visíveis aos usuários se eles descompilarem a classe Java.

O ID do usuário e a senha não podem ser alterados sem primeiro requerer uma alteração no código. Alternativamente, o código do aplicativo pode recuperar conjuntos de IDs de usuário e senhas do armazenamento persistente ou de um serviço externo. Essa abordagem exige que administradores de TI configurem e gerenciem um ID do usuário e senha usando o mecanismo específico do aplicativo.

Para acessar esses dados de autenticação, o servidor de aplicativos suporta a especificação de um alias de autenticação gerenciado por componente em um recurso. Esses dados de autenticação são comuns a todas as referências do recurso. Clique em Recursos > Adaptadores de Recursos > Connection Factories J2C > configuration_name. Selecione Usar alias de autenticação gerenciado pelo componente.

Quando res-auth=Application, os dados de autenticação são obtidos dos seguintes elementos, em ordem:
  1. O ID do usuário e a senha transmitidos ao método getConnection
  2. O alias de autenticação gerenciado por componente na connection factory ou na origem de dados
  3. O nome do usuário e a senha das propriedades customizadas na origem de dados

As propriedades do nome do usuário e da senha podem ser inicialmente definidas no arquivo RAR (Resource Adapter Archive).

[AIX Solaris HP-UX Linux Windows][z/OS]Essas propriedades também podem ser definidas no console administrativo ou com script wsadmin a partir das propriedades customizadas.

[IBM i]Não utilize as propriedades customizadas, as quais permitem que usuários se conectem aos recursos.

Conexão Gerenciada por Contêiner

O ID do usuário e a senha para os EIS (Enterprise Information Systems) de destino podem ser fornecidos pelo servidor de aplicativos. O produto fornece a funcionalidade de conexão gerenciada por contêiner. O servidor de aplicativos localiza os dados de autenticação apropriados para o EIS de destino para permitir que o cliente estabeleça uma conexão. O código do aplicativo não precisa fornecer um ID de usuário e uma senha na chamada getConnection quando está configurado para utilizar a conexão gerenciada por contêiner, e os dados de autenticação não precisam ser comuns a todas as referências a um recurso. O JAAS (Java Authentication and Authorization Service) utiliza um mecanismo de autenticação plugável para usar uma configuração de login pré-configurada do JAAS e LoginModule para mapear uma identidade de segurança do cliente e credenciais no encadeamento em execução para um ID de usuário e uma senha pré-configurados.

O produto suporta um módulo LoginModule de mapeamento padrão de credenciais de muitos para um que mapeia qualquer identidade de cliente no encadeamento em execução para um ID de usuário e uma senha pré-configurados para um EIS de destino especificado. O módulo de mapeamento padrão tem uma finalidae especial do módulo LoginModule do JAAS que retorna uma credencial PasswordCredential que é especificada pela entrada de dados de autenticação do J2C (Java 2 connector). O módulo LoginModule de mapeamento padrão executa uma consulta de tabela, mas não executa a autenticação em si. O ID do usuário e a senha são armazenados juntos com um alias na lista de dados de autenticação J2C.

A lista de dados de autenticação J2C está localizada no painel Segurança Global a partir de Java Authentication and Authorization Service > Dados de Autenticação J2C. O proprietário padrão e a função de mapeamento de credenciais são definidos pela configuração de login do JAAS do aplicativo DefaultPrincipalMapping.

Os dados de autenticação J2C modificados por meio do console administrativo serão efetivados quando a modificação for salva no repositório e a Conexão de Teste for executada. Além disso, os dados de autenticação J2C modificados por meio do script wsadmin serão efetivados quando qualquer aplicativo for iniciado ou reiniciado para um determinado processo de servidor de aplicativos. A modificação dos dados de autenticação J2C é efetivada pela chamada do método MBean SecurityAdmin, updateAuthDataCfg. Configure o parâmetro HashMap como null para permitir que o MBean Securityadmin atualize os dados de autenticação J2C utilizando os valores mais recentes do repositório.

Não modifique a configuração de login DefaultPrincipalMapping, pois o produto inclui aprimoramentos de desempenho nessa configuração de mapeamento padrão freqüentemente utilizada. O produto não suporta a modificação da configuração DefaultPrincipalMapping, a alteração do módulo LoginModule padrão, nem o empilhamento de um módulo LoginModule customizado na configuração.

[z/OS]Na plataforma z/OS, se um ID de usuário e uma senha não estiverem presentes ou forem padronizados por um alias, o tempo de execução do WebSphere Application Server procurará por um ID de usuário do SAF (System Authorization Facility) no objeto.

Para a maioria dos sistemas, o método padrão com um mapeamento de muitos para um é suficiente. No entanto, o produto suporta o proprietário customizado e as configurações de mapeamento de credenciais. Os módulos de mapeamento customizados podem ser incluídos na configuração do JAAS de logins do aplicativo, criando uma nova configuração de login do JAAS com um nome exclusivo. Por exemplo, um módulo de mapeamento customizado pode fornecer mapeamento um-a-um ou a funcionalidade Kerberos.

As conexões confiáveis também fornecem um mapeamento de um para um enquanto suportam a propagação da identidade do cliente. Além de utilizar o objeto de contexto confiável do DB2, as conexões confiáveis podem aproveitar as vantagens do conjunto de conexões para reduzir a perda de desempenho do fechamento e da reabertura de conexões com uma identidade diferente. O uso de conexões confiáveis aumenta também a segurança do banco de dados DB2, eliminando a necessidade de designar todos os privilégios para um único usuário. A conexão é estabelecida por um usuário cujas credenciais são confiáveis pelo servidor DB2 para abrir a conexão e o mesmo usuário é também confiável para reivindicar a identidade dos outros usuários que acessam o servidor DB2 a partir do aplicativo. Uma nova configuração de mapeamento chamada TrustedConnectionMapping foi criada para conexões confiáveis implementadas.

É possível também uutilizar o console administrativo do WebSphere Application Server para ligar as referências do connection factory do gerenciador de recursos a um dos factories do recurso configurado. Se o valor do elemento res-auth for Contêiner no descritor de implementação para seu aplicativo, você deverá especificar a configuração do mapeamento. Para especificar a configuração de mapeamento, use o link Referências de Recurso em Referências no painel Aplicativos > Tipos de Aplicativos > Aplicativos Corporativos do Websphere > application_name. Consulte Mapeando de Referências de Recursos para Referências para obter instruções adicionais.

Módulos de Mapeamento e Propriedades de Mapeamento do J2C

Os módulos de mapeamento são módulos de login especiais do JAAS que fornecem funcionalidade de mapeamento de proprietário e de credencial. É possível definir e configurar os módulos de mapeamento customizados utilizando o console administrativo.

É possível também definir e transmitir dados de contexto para os módulos de mapeamento, utilizando as opções de login em cada configuração de login do JAAS. No produto, também é possível definir os dados de contexto utilizando propriedades de mapeamento em cada ligação de referência da connection factory.

As opções de login definidas em cada configuração de login do JAAS são compartilhadas entre todos os recursos que utilizam os mesmos módulos de configuração e mapeamento de login do JAAS. As propriedades de mapeamento definidas para cada ligação de referência da connection factory são utilizadas exclusivamente pela referência de recurso.

Considere um cenário de uso no qual um serviço de mapeamento externo é utilizado.

Por exemplo, é possível usar o serviço GSO (conexão global) do Tivoli Access Manager. Utilize o GSO do Tivoli Access Manager para localizar dados de autenticação para os dois servidores de backend.

Você tem dois servidores EIS: DB2 e MQ. Porém, os dados de autenticação para DB2 são diferentes daqueles para MQ. Utilize a opção de login em uma configuração de login de mapeamento do JAAS para especificar os parâmetros necessários para estabelecer uma conexão com o serviço GSO do Tivoli Access Manager. Utilize as propriedades de mapeamento de uma ligação de referência da connection factory para especificar qual servidor EIS requer o ID do usuário e a senha.

Para obter informações mais detalhadas sobre como desenvolver um módulo de mapeamento, consulte o tópico Módulos de Mapeamento do J2C Principal.

Nota:
  • A configuração de mapeamento na connection factory foi movida para a referência da connection factory do gerenciador de recursos. Os módulos de login do mapeamento que são desenvolvidos utilizando tipos de retornos de chamada do JAAS do WebSphere Application Server Versão 5 podem ser utilizados pela referência do connection factory do gerenciador de recursos, mas os módulos de login do mapeamento não podem aproveitar as vantagens do recurso de propriedades do mapeamento customizado.
  • A ligação de referência da connection factory suporta propriedades de mapeamento e transmite essas propriedades aos módulos de login de mapeamento por meio de um novo retorno de chamada WSMappingPropertiesCallback. Além disso, o retorno de chamada WSMappingPropertiesCallback e o novo retorno de chamada WSManagedConnectionFactoryCallback são definidos no pacote com.ibm.wsspi. Utilize os novos módulos de login de mapeamento com os novos tipos de retorno de chamada.

Entrega de Mensagens Seguras com Entrada SecurityContext

As informações seguras podem ser fornecidas por um adaptador de recursos EIS para o servidor de aplicativos, usando o contexto do fluxo de segurança. O mecanismo do contexto do fluxo de segurança permite que o gerenciador de trabalho execute as ações de uma instância de Trabalho com uma identidade estabelecida. Estas ações incluem a entrega de mensagens para terminais de mensagens Java EE, processadas como beans acionados por mensagens (MDB) sob uma identidade configurada em um domínio de segurança do servidor de aplicativos.

Atenção: O contexto do fluxo de segurança só é suportado para adaptadores de recursos compatíveis com JCA 1.6. Atualmente, o produto não fornece um adaptador de recursos integrado que suporte um contexto do fluxo de segurança O uso da entrada SecurityContext para a entrega de mensagens seguras requer um adaptador de recursos que suporte o sistema de mensagensJava EE e o contexto do fluxo de segurança.

A entrega de mensagens seguras para um terminal de mensagens requer que a segurança global esteja ativada na configuração de segurança global. Também é necessário que a segurança do aplicativo esteja ativada no servidor de aplicativos que hospeda o aplicativo fornecedor do MDB do terminal de mensagens. Para obter mais informações sobre segurança global, consulte o tópico "Configurações da Segurança Global".

A política de segurança do descritor de implementação do aplicativo deve estar configurada com funções que estejam associadas a identidades de usuários no domínio do aplicativo, que é o registro do usuário do domínio de segurança que é o escopo do aplicativo. Essa configuração de segurança ativa a segurança EJB e autoriza o acesso a métodos de MDB às identidades de usuários específicas no domínio do aplicativo. Para obter mais informações sobre a visão geral de segurança, consulte o tópico "Segurança".

A entrega de mensagens seguras também requer que o adaptador de recursos defina implementações para as interfaces WorkContextProvider e SecurityContext. Para entregar uma mensagem segura, um adaptador de recursos primeiro envia uma instância de trabalho que fornece uma implementação SecurityContext, usada pelo gerenciador de trabalho para estabelecer o assunto da conexão para essa instância de trabalho.

Ao estabelecer o assunto da execução, SecurityContext pode fornecer implementações de callback do Java Authentication Service Provider Interface for Containers (JASPIC), usadas pelo gerenciador de trabalho para determinar as identidades do responsável pela chamada e do grupo (CallerPrincipalCallback, GroupPrincipalCallback) e para autenticar a identidade do responsável pela chamada e a senha (PasswordValidationCallback). Se a identidade do responsável pela chamada estiver no domínio do aplicativo, o gerenciador de trabalho determinará a identidade construindo uma instância do WSSubject contendo o diretor do responsável pela chamada, todos os diretores do grupo e todas as credenciais privadas.

Alternativamente, SecurityContext pode fornecer um assunto de execução que seja uma instância da instância do WSSubject criada por outro login ou módulo de autenticação. O gerenciador de trabalho só aceita essa instância do WSSubject quando o diretor do responsável pela chamada da instância está no domínio do aplicativo ou em um domínio confiável. Para obter mais informações sobre regiões, consulte o tópico "Configurando Regiões Confiáveis de Entrada para Diversos Domínios de Segurança".

O gerenciador de trabalho rejeita uma instância de Trabalho sempre que esta não pode estabelecer uma instância do WSSubject. Entretanto, ele efetua dispatch na instância em um encadeamento gerenciado da instância do WSSubject que tenha sido declarada ou aceita. Se SecurityContext não fornecer nenhuma identidade do responsável pela chamada, a instância de Trabalho efetuará dispatch em uma instância do WSSubject que contenha o diretor não autenticado do responsável pela chamada.

Ao receber dispatch, uma instância de Trabalho pode tentar entregar mensagens ao MDB do aplicativo seguro. Todas as mensagens são entregues na instância do WSSubject estabelecida para a instância de Trabalho. O colaborador de segurança EJB permite acesso ao método onMessage do MDB sempre que o diretor do responsável pela chamada da instância do WSSubject está associado a uma função declarada no descritor de implementação do aplicativo. Caso contrário, o colaborador negará acesso e a entrega da mensagem falhará. Durante a entrega, o MDB pode usar os Métodos de Contexto EJB, isCallerInRole e getCallerPrincipal, para tomar decisões de acesso adicionais e o MDB pode acessar outras entidades no domínio de segurança para o qual o diretor do responsável pela chamada possui autorização.


Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=csec_j2csecurity
Nome do arquivo: csec_j2csecurity.html