Domínios de Segurança Múltiplos
O WebSphere Security Domains (WSD) fornece a flexibilidade de usar configurações de segurança diferentes em WebSphere Application Server. O WSD também é chamado de domínios de segurança múltiplos ou, simplesmente, de domínios de segurança. É possível configurar diferentes atributos de segurança, como o UserRegistry, para aplicativos diferentes.
- Por Que os Domínios de Segurança são Úteis
- Relacionamento Entre Segurança Global e Domínios de Segurança
- Conteúdo de um Domínio de Segurança
- Criando Domínios de Segurança
- Configurando Atributos a Domínios de Segurança
- Associando Escopos a Domínios de Segurança
- Relacionamento entre os Domínios de Segurança de Nível do Servidor Antigos e de Segurança Novos
- Como Atributos de Segurança do Nível do Domínio São Utilizados por Aplicativos e Tempo de Execução de Segurança
- Modelo de Programação de Segurança de Aplicativo e Cliente ao Utilizar Domínios de Segurança
- Implementação de Aplicativo em várias Configurações de Domínio
- Comunicação de várias Regiões
- Associando um Nó com Domínios de Segurança
- Domínios de Segurança em um Ambiente de Versão Mista
- Modificando Domínios de Segurança
Por Que os Domínios de Segurança são Úteis
Os WebSphere Security Domains fornecem dois benefícios principais:
- Os aplicativos administrativos do WebSphere Application Server podem ser configurados com um conjunto diferente de configurações de segurança daquele para aplicativos de usuário.
- Eles permitem que um conjunto de aplicativos tenha um conjunto de configurações
de segurança diferente do outro conjunto de aplicativos.
Por exemplo, a administração do WebSphere Application Server pode ser configurado a um registro do usuário de RACF enquanto os aplicativos podem ser configurados a um registro do usuário de LDAP.
Por exemplo, a administração do WebSphere Application Server pode ser configurada para um registro do usuário de repositório associado, enquanto os aplicativos podem ser configurados para um registro do usuário de LDAP.
Nas versões anteriores do WebSphere Application Server, todos os aplicativos administrativos e do usuário compartilham a maioria dos atributos de segurança. Todos os aplicativos de usuário e administrativos em WebSphere Application Server utilizam atributos de segurança global por padrão. Por exemplo, um registro do usuário definido na segurança global é utilizado para autenticar um usuário para cada aplicativo na célula.
Nesse release do WebSphere Application Server, entretanto, é possível utilizar vários atributos de segurança para aplicativos de usuário além dos atributos de segurança globais, criar um domínio de segurança para aqueles atributos de segurança que devem diferenciar, e associá-los aos servidores e clusters que hospedam aqueles aplicativos de usuário. É possível também associar um domínio de segurança à célula. Todos os aplicativos de usuário na célula utilizam esse domínio de segurança, caso nenhum domínio tenha sido associado a eles anteriormente. Entretanto, atributos de segurança global ainda são necessários para aplicativos administrativos, como o console administrativo, os recursos de nomenclatura e MBeans.
Se você utilizou segurança de nível do servidor em releases anteriores do WebSphere Application Server, deveria agora usar vários domínios de segurança, desde que eles sejam mais flexíveis e fáceis de configurar.
A segurança no nível do servidor é reprovada neste release. Leia Relacionamento Entre Segurança Global e Domínios de Segurança para obter informações adicionais.
Relacionamento Entre Segurança Global e Domínios de Segurança
A Segurança Global se aplica a todas as funções administrativas e à configuração de segurança padrão para aplicativos de usuário. Domínios de segurança podem ser utilizados para definir uma configuração customizada para aplicativos de usuário.
Você deve ter uma configuração de segurança global definida antes de poder criar domínios de segurança. A configuração de segurança global é utilizada por todos os aplicativos administrativos, como console administrativo, recursos de nomenclatura e Mbeans. Se nenhum domínio de segurança estiver configurado, todos os aplicativos utilizarão informações da configuração de segurança global. Os aplicativos de usuário, como os EJBs (Enterprise JavaBeans), os servlets e os aplicativos administrativos utilizam a mesma configuração de segurança.
Quando você cria um domínio de segurança e o associa a um escopo, somente os aplicativos de usuário nesse escopo utilizam os atributos de segurança que estão definidos no domínio de segurança. Os aplicativos administrativos, bem como as operações de nomenclatura nesse escopo, utilizam a configuração de segurança global. Defina os atributos de segurança nesse nível de domínio que precisam ser diferentes daqueles no nível global. Se as informações forem comuns, o domínio de segurança não precisará conter informações duplicadas. Quaisquer atributos que estiverem ausentes no domínio serão obtidos da configuração global. Os dados de configuração da segurança global são armazenados no arquivo security.xml, que está localizado no diretório $WAS_HOME/profiles/$ProfileName/cells/$CellName.
A figura a seguir fornece um exemplo de um domínio de segurança múltiplo onde a célula, um servidor e um cluster são associados a domínios de segurança diferentes. Conforme mostrado na figura, os aplicativos de usuário no servidor S1.1, bem como o cluster, utilizam atributos de segurança que são definidos no Domain2 e Domain3 respectivamente (já que esses escopos estão associados a esses domínios). O servidor S2.2 não está associado a um domínio. Como resultado, o aplicativo de usuário S2.2 utiliza o domínio que está associado à célula (Domain1) por padrão. Os atributos de segurança que estiverem ausentes no nível do domínio serão obtidos da configuração global.

A figura a seguir mostra os vários atributos de segurança de alto nível que podem ser definidos na configuração de segurança global e aqueles que podem ser substituídos no nível do domínio.

Conteúdo de um Domínio de Segurança
Um domínio de segurança é representado por dois arquivos de configuração. Um arquivo de configuração contém a lista de atributos que são configurados no domínio de segurança. O outro arquivo de configuração contém os escopos que utilizam o domínio de segurança. As informações de domínio de segurança são armazenadas no diretório $WAS_HOME/profiles/$ProfileName/config/waspolicies/default/securitydomains/$SecurityDomainName. Para cada domínio de segurança que é configurado, um diretório $SecurityDomainName é criado contendo dois arquivos: o arquivo security-domain.xml contém a lista de atributos de segurança configurados para o domínio de segurança e o arquivo security-domain-map.xml contém os escopos que utilizam o domínio de segurança.
A figura a seguir indica o local dos arquivos relacionados ao domínio de segurança principal e o conteúdo desses arquivos.

Criando Domínios de Segurança
Utilize as tarefas do console administrativo ou os comandos de script para criar domínios de segurança. No console administrativo, acesse os domínios de segurança clicando em
. A ajuda estará disponível para cada painel do console administrativo.Para obter uma lista completa das tarefas do console administrativo e dos comandos de script, consulte os links em "Tarefas relacionadas" no final deste documento.
Quando você cria um domínio de segurança, deve fornecer um nome exclusivo para o domínio, os atributos de segurança que deseja configurar para o domínio de segurança e os escopos necessários para utilizar o domínio de segurança. Depois de configurado, os servidores que utilizam o domínio de segurança devem ser reiniciados. Os aplicativos do usuário nesses escopos utilizam então os atributos que são definidos no domínio de segurança. Todos os atributos que não estão configurados no nível de domínio são obtidos na configuração de segurança global. Os aplicativos administrativos e as operações de nomenclatura nos escopos sempre utilizam os atributos de segurança da configuração de segurança global. Você deve gerenciar ativamente esses atributos.
Todo domínio de segurança novo deve ser compatível com esses atributos de segurança global que são herdados pelos aplicativos de usuário que são designados ao domínio.
Diferentemente do JAAS e das propriedades customizadas, uma vez que os atributos globais sejam customizados para um domínio, eles não são mais utilizados pelos aplicativos de usuário.
O painel de domínios de segurança no console administrativo permite designar recursos e selecionar os atributos de segurança apropriados para seu domínio. O painel exibe os atributos de segurança chave na configuração global; é possível decidir substituí-los no nível de domínio, se for necessário. Depois de configurado e salvo os atributos no nível de domínio, o valor do resumo no painel exibe o valor customizado do domínio (marcado com a palavra "customizado" em texto preto).
Um escopo (um servidor, um cluster, um barramento de integração de serviços ou uma célula) pode ser associado a apenas um domínio. Por exemplo, você não pode definir dois domínios que tenham o escopo inteiro na célula. Vários escopos, entretanto, podem ser definidos no mesmo domínio de segurança. Por exemplo, um domínio pode ter seu escopo definido para Server1 e Server2 somente dentro da célula.
A seção de escopos designados no painel de domínio de segurança exibe duas visualizações: uma visualização que permite selecionar e designar escopos para o domínio e uma visualização que permite ver uma lista dos escopos atualmente designados. Para sua comodidade, você também tem a flexibilidade para copiar todos os atributos de segurança de um domínio de segurança existente ou a configuração global em um novo domínio de segurança e depois modificar somente os atributos que devem ser diferentes. Você ainda deve associar os escopos a esses domínios copiados.
Comandos de script também fornecem a capacidade para criar, copiar e modificar domínios de segurança. Após criar um domínio, você deve executar os comandos apropriados para associar atributos de segurança e escopos a ele.
Configurando Atributos a Domínios de Segurança
Os atributos de segurança que podem ser configurados no nível de domínio em WebSphere Application Server Versão 9.0 são:
- Segurança do aplicativo
- Segurança do Java™ 2
- Região do usuário (registro)
- Associação de confiança
- Autenticação da Web SPNEGO (Simple and Protected GSS-API Negotiation)
- Segurança RMI/IIOP (CSIv2)
- logins do JAAS (Application, System and J2C Authentication Data)
- Java Authentication SPI
- Atributos do mecanismo de autenticação
- Provedor de autorização
- Repositórios federados
Propriedades do z/OS
- Propriedades Customizadas
Os painéis de domínios de segurança no console administrativo exibem todos esses atributos de segurança.
Alguns dos outros atributos bem conhecidos que você não pode substituir no nível de domínio são Kerberos, Audit, Web Single Sign-on (SSO) e Tivoli Access Manager (TAM). O atributo Secure Socket Layer (SSL) já suporta diferentes escopos, mas não faz parte da configuração de domínio. Para todos os atributos que não são suportados no nível do domínio, aplicativos de usuário em um domínio compartilham sua configuração no nível global.
Todo domínio de segurança novo deve ser compatível com esses atributos de segurança global que são herdados pelos aplicativos de usuário que são designados ao domínio. Você deve gerenciar ativamente esses atributos. Por exemplo, se você customizar apenas uma configuração do JAAS no nível de domínio, deverá assegurar-se de que ela funcione com o registro do usuário configurado no nível global (se o registro do usuário não estiver customizado no nível de domínio).
Diferentemente do JAAS e das propriedades customizadas, uma vez que os atributos globais sejam customizados para um domínio, eles não são mais utilizados pelos aplicativos de usuário.
O tempo de execução do cliente Tivoli Access Manager é usado para fornecer autenticação (usado por TrustAssociationInterceptor e PDLoginModule) e autorização (usado para JACC) entrando em contato com os servidores TAM. Há apenas um tempo de execução do Tivoli Access Manager compartilhado por todos os servidores em uma célula. Leia o tópico de configuração do provedor JACC do Tivoli Access Manager para obter informações adicionais.
Não é possível ter uma configuração do Tivoli Access Manager diferente no nível de domínio de segurança para substituir a configuração no nível de célula. Entretanto, é possível em algum grau especificar a configuração de Trust Association Interceptor (TAI) e JACC no nível do domínio de segurança. Por exemplo, é possível usar um TAI diferente ou um provedor de autorização diferente. Como a conectividade do servidor TAM pode ser definida apenas no nível global, é possível ter uma variedade de TAIs definidos e configurados no nível do domínio de segurança. Alguns destes TAIs não podem usar o repositório do usuário TAM, enquanto outros podem. Os TAIs que precisam se conectar ao TAM também se conectarão ao servidor TAM definido globalmente. De modo semelhante, para autorização, é possível ter uma variedade de provedores de autorização externos configurados no nível de domínio. Entretanto, se qualquer um destes provedores de autorização externos requerer conexão com o TAM, eles acabarão conversando com o servidor TAM configurado globalmente singular.
Associando Escopos a Domínios de Segurança
Quando um domínio de segurança está associado a um servidor que não faz parte de um cluster, todos os aplicativos de usuário nesse servidor utilizam os atributos do domínio de segurança. Quaisquer atributos que estiverem ausentes serão obtidos da configuração de segurança global. Se o servidor fizer parte de um cluster, você poderá associar o domínio de segurança ao cluster, mas não aos membros individuais nesse cluster. O comportamento de segurança permanece consistente em todos os membros de cluster.
Se um servidor for fazer parte de um cluster, crie um cluster primeiro e associe o domínio de segurança a ele. Você deve ter associado um domínio a um servidor antes de ele ser membro de um cluster. Nesse caso, mesmo que o domínio esteja associado ao servidor diretamente, o código de tempo de execução de segurança não procurará no domínio. Quando um servidor é um membro de cluster, o tempo de execução de segurança desconsidera quaisquer domínios de segurança associados diretamente ao servidor. Remova o escopo do servidor do domínio de segurança e associe o escopo do cluster a ele.
Um domínio de segurança também pode ser associado à célula. Isso normalmente é feito quando desejar associar todos os aplicativos de usuário no WebSphere Application Server para um domínio de segurança. Neste cenário, todos os aplicativos administrativos e as operações de nomenclatura utilizam a configuração de segurança global enquanto todos os aplicativos de usuário utilizam a configuração no nível do domínio. Se quiser dividir as informações sobre configuração de segurança para aplicativos de usuário e administrativos, isso é tudo que você precisa.
Se tiver um ambiente com uma mistura de versões, ou pretende ter no futuro, e quiser associar domínios de segurança no nível da célula, leia Domínios de Segurança em um Ambiente de Versão Mista para obter informações adicionais.
Se estiver em um servidor de perfil de base que possui seu próprio domínio de segurança definido, e que é associado a um gerenciador de implementação, associe o escopo do servidor ao domínio de segurança, e não ao escopo da célula. Quando você associa esse nó, as informações sobre o domínio de segurança são propagadas para o gerenciador de implementação. Se o escopo da célula estiver associado a ele, a configuração de implementação de rede utilizará essa configuração de segurança, que pode afetar aplicativos existentes. Durante a associação, o escopo da célula é alterado para o escopo do servidor que está sendo associado. Se o escopo do servidor estiver associado ao domínio de segurança, somente esse servidor utilizará o domínio de segurança após a associação. Outros aplicativos em outros servidores e clusters não são afetados. Entretanto, se esse servidor de perfil de base estiver registrado para o processo do Agente Administrativo, você poderá associar o escopo da célula ao domínio de segurança se quiser que todos os servidores do perfil de base utilizem o mesmo domínio de segurança para todos os seus aplicativos de usuário. Leia sobre Associando um Nó com Domínios de Segurança para obter informações adicionais.
Você pode ter um domínio de segurança associado no nível de célula e também outros domínios de segurança associados a vários clusters ou servidores individuais (aqueles que não fazem parte de nenhum clusters). Nesse caso, o tempo de execução de segurança primeiro verifica se algum domínio de segurança está associado ao servidor ou a um cluster. Se houver um domínio de segurança associado ao servidor ou a um cluster, os atributos de segurança definidos nele serão utilizados para todos os aplicativos nesse servidor ou cluster. Quaisquer atributos de segurança ausentes neste domínio de servidor ou cluster serão obtidos da configuração de segurança global, e não da configuração de domínio associada à célula.
Se o servidor ou cluster não tiver seu próprio domínio definido, o código de tempo de execução de segurança utilizará os atributos de segurança do domínio associados à célula (se houver alguma definida). Quaisquer atributos de segurança ausentes no domínio da célula serão herdados da configuração de segurança global.
Relacionamento entre os Domínios de Segurança de Nível do Servidor Antigos e de Segurança Novos
Em liberações anteriores do WebSphere Application Server, você poderia associar um pequeno conjunto de atributos de segurança em um nível de servidor. Esses atributos eram utilizados por todos os aplicativos no nível do servidor. A forma anterior de configuração dos atributos de segurança foi descontinuada no WebSphere Application Server 7.0 e será removida em uma liberação futura.
Você deve agora utilizar os novos domínios de segurança começando em WebSphere Application Server 7.0, já que esses domínios de segurança são mais facilmente gerenciados e muito mais flexíveis. Por exemplo, em versões anteriores do WebSphere Application Server, você deve associar manualmente a mesma configuração de segurança a todos os membros de cluster, configurando os mesmos atributos de segurança para cada servidor em um cluster.
A ferramenta de migração migra as informações de configuração de segurança existentes no nível do servidor para a nova configuração de domínio de segurança quando o modo de compatibilidade de script for false (-scriptCompatibility="false"). Um novo domínio de segurança é criado para cada configuração de segurança do servidor se ele não fizer parte de um cluster. Se ele fizer parte de um cluster, um domínio de segurança será associado ao cluster, e não a todos os servidores nesse cluster. Em ambos os casos, todos os atributos de segurança que estavam configurados no nível do servidor em releases anteriores serão migrados para a nova configuração de domínio de segurança, e o escopo apropriado será designado aos domínios de segurança.
Se o modo de compatibilidade de script estiver configurado como true, a configuração de segurança do nível do servidor não será migrada para a nova configuração de domínios de segurança. A antiga configuração de segurança de servidor será migrada sem nenhuma alteração. O tempo de execução de segurança detecta que a configuração de segurança antiga existe e utiliza essa informação, mesmo que um domínio de segurança esteja associado tanto diretamente quanto indiretamente ao servidor. Se o modo de compatibilidade de script estiver configurado como true, remova a configuração de segurança do nível do servidor e crie um domínio de segurança com o mesmo conjunto de atributos de segurança.
Como Atributos de Segurança do Nível do Domínio São Utilizados por Aplicativos e Tempo de Execução de Segurança
Esta seção descreve como os atributos individuais no nível do domínio são utilizados pelo tempo de execução de segurança e como isso afeta a segurança do aplicativo do usuário. Como todos esses atributos de segurança também são definidos no nível global, mais informações sobre esses atributos podem ser obtidas em qualquer lugar. Para os objetivos desta seção, a ênfase será no comportamento no nível do domínio.
- Segurança do Aplicativo:
Selecione Ativar Segurança do Aplicativo para ativar ou desativar a segurança para aplicativos de usuário. Quando essa seleção é desativada, todos os EJBs e aplicativos da Web no domínio de segurança não são mais protegidos. O acesso é concedido a esses recursos sem autenticação do usuário. Quando você ativa essa seleção, a segurança J2EE é forçada para todos os EJBs e aplicativos da Web no domínio de segurança. The J2EE security is only enforced when Global Security is enabled in the global security configuration, (that is, you cannot enable application security without first enabling Global Security at the global level).
- Segurança Java 2:
Selecione Usar Segurança Java 2 para ativar ou desativar a segurança Java 2 no nível de domínio ou para designar ou incluir propriedades relacionadas à segurança Java 2. Esta opção permite ativar ou desativar a segurança do Java 2 no nível de processo (JVM), para que todos os aplicativos (administrativos e de usuário) possam ativar ou desativar a segurança do Java 2.
- Região do Usuário (Registro do Usuário):
Essa seção possibilita configurar o registro do usuário para o domínio de segurança. É possível configurar separadamente qualquer registro que é usado no nível de domínio. Leia sobre Configurando Atributos a Domínios de Segurança para obter informações adicionais.
Ao configurar um registro no nível do domínio, você pode optar por definir o nome de sua própria região para o registro. O nome da região distingue um registro do usuário de outro. O nome da região é utilizado em múltiplos lugares – no painel de login do cliente Java para solicitar o usuário, no cache de autenticação e ao utilizar uma autorização nativa.
No nível de configuração global, o sistema cria a região para o registro do usuário. Em liberações anteriores do WebSphere Application Server, apenas um registro do usuário é configurado no sistema. Quando você tem domínios de segurança múltiplos, é possível configurar registros múltiplos no sistema. Para que as regiões sejam exclusivas nesses domínios, configure o nome de sua própria região para um domínio de segurança. Também é possível escolher o sistema para criar um nome de região exclusivo se ele tiver certeza de que é exclusivo. Nesse caso, o nome da região será baseado no registro que está sendo utilizado.
Para registros LDAP, o host:porta do servidor LDAP é o nome da região gerado pelo sistema. Para S.O. local, o nome da máquina do S.O. local é o nome da região. Para registros de usuário customizados, a região é aquela retornada pelo método getRealm ( ) da implementação de registro customizada.
Se os nomes de região gerados pelo sistema não forem exclusivos o suficiente, você poderá escolher a opção para o sistema gerar o nome da região. Se não, escolha um nome de região exclusivo para cada domínio de segurança onde o registro do usuário está configurado. Se o repositório do usuário básico for o mesmo, utilize o mesmo nome de região em domínios diferentes. A partir de uma perspectiva de tempo de execução de segurança, nomes de região iguais têm o mesmo conjunto de informações de usuários e grupos. Por exemplo, quando informações de usuários e grupos são exigidas de uma região, o primeiro repositório do usuário que corresponde à região é utilizado.
Se um registro ocalOS que não está centralizado é configurado para qualquer domínio. e esse domínio é associado com servidores ou clusters em nós que não estão no mesmo sistema do gerenciador de implementação, o nome da região precisa ser fornecido. Este nome da região deve ser igual àquele que seria gerado no nó. O nome da região pode ser obtido chamando o método getRealm() no SecurityAdmin MBean daquele nó. Geralmente, o nome da região para registros localOS é o nome do host da máquina. Neste caso, você não deve deixar o sistema gerar o nome da região, mas, em vez disso, obter o nome do domínio que é usado pelos processos no nó.Se você selecionar o sistema para gerar o domínio para o registro localOS no momento da configuração do registro do usuário, ele escolhe o registro localOS que é usado pelo gerenciador de implementação. Se o domínio configurado não corresponder ao domínio usado pelos servidores, então existem problemas de autorização. Também observe que neste caso, o domínio que usa este registro local somente pode ser associado com servidores e clusters que pertencem a nós na mesma máquina.
No WebSphere Application Server Versão 7.0, o registro do usuário dos repositórios associados só pode ser configurado no nível global e possui apenas uma instância por célula, mas qualquer domínio pode usá-lo configurando-o como o registro ativo. No WebSphere Application Server Versão 8.0, é possível configurar uma instância exclusiva de um repositório associado no nível do domínio em um ambiente múltiplo do domínio de segurança.
Quando um domínio de segurança é copiado do nível global, os usuários e grupos definidos no nível global também são copiados para o domínio de segurança. Isso também é verdadeiro ao copiar a partir de um domínio existente. Um domínio de segurança recentemente criado que utiliza o repositório VMM baseado em arquivo requer que o usuário ocupe o repositório com usuários e grupos.
Também uma novidade desta liberação do WebSphere Application Server, a nova caixa de seleção Usar Esquema Global para o Modelo, na página do console administrativo Definições da Configuração de Região, configura a opção do esquema global para o modelo de dados em um ambiente múltiplo do domínio de segurança. O esquema global se refere ao esquema do domínio admin.
Quando mais de um registro do usuário estiver em um processo, a consulta de nomenclatura que utiliza ”UserRegistry“ como o nome de consulta retornará o registro do usuário que é usado pelos aplicativos de usuário. O registro do usuário utilizado pelos aplicativos administrativos é limitado pelo nome da consulta, ”AdminUserRegistry“.
Conforme descrito em Comunicação de várias Regiões, quando um aplicativo em uma região se comunica com um aplicativo em outra região utilizando tokens LTPA, as regiões devem ser confiáveis. O relacionamento confiável pode ser estabelecido usando o link de entrada Domínio de autenticação confiável – no painel de registro do usuário ou usando o comando addTrustedRealms. É possível estabelecer a confiança entre regiões diferentes. Um usuário com login efetuado em uma região pode acessar recursos em outra região. Se a confiança não for estabelecida entre as duas regiões, a validação do token LTPA falhará.
Nota: O nome da região usando no arquivo web.xml não está relacionado à região do registro do usuário. - Associação de Confiança:
When you configure the trust association interceptor (TAI) at a domain level, the interceptors configured at the global level are copied to the domain level for convenience. You can modify the interceptor list at the domain level to fit your needs. Only configure those interceptors that are to be used at the domain level.
Trust Association Interceptor do Tivoli Access Manager só pode ser configurado no nível global. A configuração de domínio também pode utilizá-los, mas não pode ter uma versão diferente do trust association interceptor. Apenas uma instância dos Trust Association Interceptors do Tivoli Access Manager podem existir na célula.
- Autenticação da web SPNEGO:
A autenticação da Web SPNEGO, que permite a você configurar SPNEGO para autenticação de recurso da Web, pode ser configurada no nível de domínio.
Nota: Em WebSphere Application Server Versão 6.1, um TAI que utiliza o Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) para negociar com segurança e autenticar pedidos de HTTP para recursos assegurados foi introduzido. Em WebSphere Application Server 7.0, esse função foi descontinuada. A autenticação da Web SPNEGO assumiu sua posição para oferecer recarregamento dinâmico dos filtros SPNEGO e para permitir fallback para o método de login do aplicativo. - Segurança RMI/IIOP (CSIv2):
O atributo de segurança RMI/IIOP refere-se às propriedades do protocolo CSIv2 (Common Secure Interoperability version 2). Ao configurar esses atributos no nível de domínio, a configuração de segurança RMI/IIOP no nível global é copiada por conveniência.
É possível alterar os atributos que precisam ser diferentes no nível de domínio. As configurações da camada Transporte para comunicações de entrada CSIv2 deve ser a mesma para os níveis global e de domínio. If they are different, the domain level attributes are applied to all of the application in the process.
Quando um processo se comunica com outro processo com uma região diferente, os tokens de autenticação e propagação LTPA não são propagados para o servidor de recebimento de dados, a menos que esse servidor esteja na lista de regiões confiáveis de saída. Isso pode ser feito usando o link de saída Domínio de autenticação confiável – no painel de comunicação de saída CSIv2 ou usando a tarefa do comando addTrustedRealms. Leia sobre Comunicação de várias Regiões para obter informações adicionais.
- JAAS (Java Authentication
and Authorization Service):
Os logins do aplicativo JAAS, os logins do sistema JAAS e os aliases de dados de autenticação J2C do JAAS podem todos ser configurados no nível de domínio. Por padrão, todos os aplicativos no sistema têm acesso aos logins JAAS configurados no nível global. O tempo de execução de segurança verifica primeiro os logins JAAS no nível de domínio. Se não localizá-los, ele os verificará na configuração de segurança global. Configure qualquer um desses logins JAAS em um domínio apenas quando precisar especificar um login utilizado exclusivamente pelos aplicativos do domínio de segurança.
Apenas nas propriedades do JAAS e customizadas, se os atributos globais forem customizados para um domínio, eles poderão ser ainda utilizados pelos aplicativos do usuário.
- Java Authentication SPI
(JASPI)
Especifica as definições de configuração de um provedor de autenticação Java Authentication SPI (JASPI) e módulos de autenticação associados a serem aplicados no nível de domínio.
Selecione Provedores para criar ou editar um provedor de autenticação JASPI.
Nota: O provedor de autenticação JASPI pode ser ativado com provedores configurados no nível de domínio. Por padrão, todos os aplicativos no sistema têm acesso aos provedores de autenticação JASPI configurados no nível global. O tempo de execução de segurança verifica primeiro os provedores de autenticação JASPI no nível de domínio. Se não localizá-los, ele os verificará na configuração de segurança global. Configure os provedores de autenticação JASPI em um domínio apenas quando o provedor tiver que ser usado exclusivamente pelos aplicativos nesse domínio de segurança. - Atributos do Mecanismo de Autenticação:
Especifica as várias configurações de cache que devem ser aplicadas ao nível de domínio.
- Configurações do cache de autenticação - utilize para especificar suas configurações do cache de autenticação. A configuração especificada neste painel é aplicada apenas a este domínio.
- Tempo Limite de LTPA - Você pode configurar um valor de tempo limite de LTPA diferente no nível do domínio. O valor de tempo limite padrão é de 120 minutos, que é configurado no nível global. Se o tempo limite de LTPA for configurado no nível do domínio, qualquer token criado no domínio de segurança ao acessar aplicativos de usuário terá esse tempo de expiração.
- Utilize nomes de usuário qualificados por região - Quando essa seleção estiver ativada, os nomes de usuário retornados por métodos, como getUserPrincipal( ) são qualificados com a região de segurança (registro do usuário) utilizada por aplicativos do domínio de segurança.
- Provedor de Autorização:
É possível configurar um provedor JACC (Java Authorization Contract for Containers) de terceiros externo no nível de domínio. O provedor JACC do Tivoli Access Manager só pode ser configurado no nível global. Os domínios de segurança ainda poderão utilizá-lo se não substituírem o provedor de autorização por um outro provedor JACC.
Os atributos JACC, por exemplo, o objeto de Política, são baseados no nível da JVM. Isso indica que só pode existir um objeto de política JACC em um processo da JVM. No entanto, quando você tem diversos provedores JACC configurados, o processo do gerenciador de implementação deve tratar todos esses provedores na mesma JVM porque ele deve propagar a política de autorização de aplicativos para o respectivo provedor com base no nome do aplicativo.
Se seu provedor JACC puder tratar a propagação da política de autorização para vários provedores, será possível configurá-lo no nível global. Nesse caso, quando um aplicativo é instalado, esse provedor JACC é chamado no processo do gerenciador de implementação e, é responsabilidade desse provedor JACC propagar as informações para o provedor JACC correspondente com base no nome do aplicativo transmitido no id de contexto.
Outra forma de se fazer isso é configurar a propriedade customizada, com.ibm.websphere.security.allowMultipleJaccProviders=true, no nível de segurança global. Quando essa propriedade é configurada, o WebSphere Application Server propaga as informações da política de autorização para o provedor JACC associado ao domínio que corresponde ao servidor de destino onde o aplicativo está instalado. Essa propriedade só é utilizada no processo do gerenciador de implementação desde que os servidores gerenciados não hospedem vários provedores JACC.
É possível configurar, adicionalmente, as opções de autorização SAF no nível de domínio de segurança, que são as seguintes:
- O ID do usuário não autenticado
- O mapeador do perfil do SAF
- Whether to enable SAF delegation
- Se o perfil APPL deve ou não ser utilizado para restringir o acesso ao WebSphere Application Server
- Se as mensagens de falha de autorização serão suprimidas
- A estratégia de registro de auditoria do SMF
- O prefixo do perfil do SAF
Verificações CBIND são consideradas operações administrativas e, no entanto, o valor do nível global do prefixo do perfil do SAF que é especificado é utilizado quando se determina o nome do recurso CBIND a ser verificado. Por exemplo: CB.BIND.<cluster_name ou SAF_profile_prefix>.
Para obter informações adicionais sobre as opções de autorização SAF, leia sobre Autorização do z/OS System Authorization Facility.
- Propriedades Customizadas:
Configure propriedades customizadas no nível do domínio que sejam novas ou diferentes daqueles no nível global. By default, all of the custom properties at the global security configuration can be accessed by all of the applications in the cell. O código de tempo de execução de segurança verifica primeiro a propriedade customizada no nível de domínio. Se não localizá-la, ele tentará obter a propriedade customizada na configuração de segurança global.
Apenas nas propriedades do JAAS e customizadas, se os atributos globais forem customizados para um domínio, eles poderão ser ainda utilizados pelos aplicativos do usuário.
Modelo de Programação de Segurança de Aplicativo e Cliente ao Utilizar Domínios de Segurança
Um cliente Java ou um aplicativo que atua como um cliente que acessa um EJB geralmente faz primeiro uma consulta de nomenclatura. O recurso de nomenclatura, que é utilizado por aplicativos administrativos e de usuário, é considerado um recurso administrativo. Ele é protegido pelas informações de configuração de segurança global. Em uma configuração com diversos domínios na qual a segurança global está usando uma região (o registro do usuário) e um domínio está usando uma região diferente, o cliente Java deve autenticar-se em duas regiões diferentes. A primeira autenticação é necessária para a região na configuração de segurança global para que a operação de nomenclatura seja bem-sucedida; e a segunda autenticação é necessária para acessar o EJB, que utiliza uma região diferente.
A função CosNamingRead protege todas as operações de leitura de nomenclatura. A essa função é geralmente designado o objeto especial Todos. Isso implica que qualquer usuário, válido ou não, pode consultar o namespace. Quando domínios múltiplos forem definidos, se a função CosNamingRead tiver o objeto especial Todos, o código de tempo de execução de segurança no lado do cliente não solicitará que você efetue login. Ele utilizará o objeto NÃO AUTENTICADO para acessar a operação de nomenclatura. Após a operação de consulta de nomenclatura ser concluída, quando o cliente tentar acessar o EJB, ele verá um painel de login que indicará a região atualmente utilizada por esse aplicativo EJB (ou seja, a região utilizada no domínio). O cliente então apresenta as credenciais de usuário apropriadas para essa região, que pode acessar o EJB. Essa lógica se aplica a todas as variações de origem de login, incluindo properties e stdin, e não apenas quando a origem de login estiver configurada como prompt.
Se o objeto especial Todos for removido da função CosNamingRead, você será solicitado duas vezes. Se a origem de login for properties, será possível remover o comentário da propriedade com.ibm.CORBA.loginRealm no arquivo $WAS_HOME/profiles/$ProfileName/properties/sas.client.props e incluir as regiões apropriadas usando “|” como o separador. Você também deve inserir os usuários e senhas correspondentes nas propriedades com.ibm.CORBA.loginUserid e com.ibm.CORBA.loginPassword, respectivamente. Quando você estiver usando o logon programático no código do cliente Java, você deverá autenticar duas vezes com credenciais de usuário diferentes; uma vez antes de realizar uma consulta de nomenclatura do EJB (o usuário deve estar na região global) e depois, antes de chamar qualquer método no EJB (o usuário deve estar na região do domínio EJB).
A função CosNamingRead definida no servidor de segurança do z/OS não é referenciada para determinar
se as operações de leitura de nomenclatura estão protegidas em um ambiente de domínio de múltipla
segurança, mesmo quando a autorização SAF está ativada. Em vez disso,
as configurações no arquivo admin-authz.xml são utilizadas. Alternativamente, é possível usar a propriedade customizada com.ibm.security.multiDomain.setNamingReadUnprotected para
controlar se as operações de leitura de nomenclatura são protegidas. Esta propriedade substituirá quaisquer designações feitas à função CosNamingRead, independentemente de qual provedor de autorização for usado.
Em geral, quando um cliente Java precisar autenticar em várias e diferentes regiões, ele terá de fornecer as informações de credenciais de todas essas regiões. Se a origem de login for prompt ou stdin, ele será avisado para efetuar login várias vezes, uma para cada região. Se a origem de login estiver configurada como properties, as propriedades adequadas no arquivo sas.client.props (ou qualquer arquivo relacionado) serão utilizadas para autenticação para regiões diferentes.
Em certos cenários, um cliente pode fazer diversas chamadas para a mesma região. Por exemplo, o cliente Java pode acessar um recurso utilizando realm1 seguido pelo acesso a um recurso utilizando realm2 e retornar para acessar um recurso na região realm1 novamente. Nesse caso, o cliente receberá um prompt três vezes; primeiro, para realm1, segundo para realm2 e, finalmente, para realm1 novamente.
Por padrão, o objeto que é utilizado para efetuar login em uma região não é armazenado em cache pelo código do lado do cliente. Se você tiver este cenário, e desejar que o cliente armazene o assunto em cache com base na região, configure a propriedade com.ibm.CSI.isRealmSubjectLookupEnabled como true no arquivo sas.client.props. Se a propriedade com.ibm.CSI.isRealmSubjectLookupEnabled estiver configurada, o código do cliente armazenará o assunto em cache com base no nome da região. Na próxima vez em que o cliente Java precisar autenticar nesse região, o cache será localizado para obter o objeto e o cliente não receberá um prompt. Além disso, quando a propriedade com.ibm.CSI.isRealmSubjectLookupEnabled é configurada, o mesmo assunto que foi registrado na primeira vez é usado para logins subsequentes. Se as informações do objeto precisarem ser alteradas, então essa propriedade não deverá ser definida.
Se o cliente estiver fazendo um login programático, ele poderá transmitir a região junto com o usuário e a senha necessários para autenticar. Neste caso, quando a propriedade com.ibm.CORBA.validateBasicAuth é configurada como true (o valor padrão) no arquivo sas.client.props, o registro que corresponde ao nome da região é usado para login. A região deve ser suportada no processo em que ocorre a autenticação.
Ao usar as configurações JAAS do WSLogin, você também deve configurar a opção use_realm_callback no arquivo wsjaas_client.config em $WAS_HOME/profiles/$ProfileName/properties do nome da região a ser passado para o manipulador de retorno de chamada. Se quiser especificar uma URL de provedor diferente para o servidor de nomes, configure a opção use_appcontext_callback e transmita as propriedades de URL do provedor em um mapa de hash para WSLogin.
Se você não souber o nome da região, use <default> como o nome. A autenticação é feita na região do aplicativo. Se a operação de leitura de nomenclatura não tiver o objeto especial Todos designado, você deverá fornecer a região que é utilizada pelos aplicativos administrativos (o registro utilizado na configuração de segurança global), bem como as informações apropriadas de usuário e senha nesse registro para que a operação de consulta seja bem-sucedida.
Depois que a operação de consulta for bem-sucedida, execute outro login programático fornecendo a região do aplicativo (ou <default>) e as informações de usuário e senha do usuário apropriado no registro usado pelo aplicativo. Isso se assemelha aos casos em que a origem de login é prompt. Você deve se autenticar duas vezes, uma para o registro utilizado pela configuração de segurança global (para a operação de consulta de nomenclatura) e novamente para o registro utilizado pelo aplicativo para acessar o EJB.
Se com.ibm.CORBA.validateBasicAuth é configurado como false no arquivo $WAS_HOME/profiles/$ProfileName/properties/sas.client.props, o login programático pode usar <default> como o nome da região para as operações de consulta e EJB. A autenticação real ocorre somente quando o recurso é acessado no lado do servidor, em cujo caso a região é calculada com base no recurso acessado.
O novo suporte de domínio de segurança começando em WebSphere Application Versão 7.0 não altera o modelo de programação da segurança do aplicativo atual. Entretanto, oferece mais flexibilidade e recursos, como o seguinte:
- Os aplicativos de usuário ainda podem localizar o objeto do registro do usuário utilizando a consulta de nomenclatura para “UserRegistry”. Para o objeto do registro utilizado pelos aplicativos administrativos, a consulta de nomenclatura para ”AdminUserRegistry“ pode ser utilizada.
- O uso de aplicativo da configuração de login JAAS não é alterado em uma configuração de domínios múltiplos. Entretanto, se um aplicativo tiver que consultar a configuração JAAS especificada no nível do domínio, o administrador e o implementador desse aplicativo deverão se certificar de que esse domínio está configurado com as configurações JAAS que são exigidas pelo aplicativo.
- Se um aplicativo precisar se comunicar com outros aplicativos utilizando regiões diferentes, o relacionamento confiável deve ser estabelecido para comunicações de entrada e de saída durante o uso de tokens LTPA. Leia sobre Comunicação de várias Regiões para obter informações adicionais.
- Ao usar o login programático nos aplicativos, se você quiser efetuar login na região usada pelo aplicativo, use <default> como o nome da região ou forneça o nome da região que o aplicativo está usando. Se precisar efetuar login na região global, você deverá fornecer o nome da região global. Se fornecer qualquer outra região, somente um objeto de autenticação básica será criado. Quando o pedido realmente fluir para o servidor hospedando essa região, a autenticação real do usuário ocorrerá se esse servidor hospedar a região. Se o servidor não hospedar a região, o login falhará.
Implementação de Aplicativo em várias Configurações de Domínio
Quando se instala um aplicativo em uma configuração de domínios múltiplos, todos os módulos no aplicativo devem ser instalados nos servidores ou clusters que pertencem ao mesmo domínio de segurança. Se não, dependendo dos atributos de segurança configurados nesses domínios de segurança, o resultado pode ser um comportamento inconsistente. Por exemplo, se os domínios contiverem registros do usuário diferentes, as informações sobre usuários e grupos podem ser diferentes, o que pode causar comportamento inconsistente durante o acesso aos módulos. Outro exemplo é mostrado quando dados JAAS são diferentes entre os domínios de segurança. As configurações JAAS não ficam acessíveis em todos os módulos no aplicativo. O código de tempo de execução de segurança e as tarefas de comando contam com a associação de um domínio a um aplicativo ao lidar com atributos como registro do usuário, configurações de login JAAS, dados de autenticação J2C e autorização.
Na maioria dos casos, a implementação do aplicativo falha quando um aplicativo é implementado em domínios diferentes. Entretanto, como era possível em liberações anteriores do WebSphere Application Server, quando apenas alguns atributos eram suportados no nível do servidor, a ferramenta de implementação procura por atributos que estão configurados nos domínios. Se os atributos no domínio forem os mesmos que os suportados em releases anteriores, o console administrativo solicitará uma confirmação para se certificar de que você quer implementar módulos aplicativos em domínios de segurança múltiplos. A menos que exista um requisito absoluto para a implementação de aplicativos em domínios diferentes, pare a implementação e selecione os servidores e clusters no mesmo domínio de segurança.
Comunicação de várias Regiões
Quando aplicativos se comunicam utilizando o protocolo RMI/IIOP e o LTPA é o mecanismo de autenticação, o token LTPA é transmitido entre os servidores envolvidos. O token LTPA contém o ID exclusivo qualificado da região (também chamado accessId) do usuário que está efetuando login no aplicativo de front-end. Quando esse token é recebido pelo servidor de recebimento de dados, ele tenta decriptografar o token. Se as chaves LTPA forem compartilhadas entre os dois servidores, a decriptografia será bem-sucedida e o accessId do usuário será obtido do token. A região no accessId é verificada com a região atual que é utilizada pelo aplicativo. Se as regiões corresponderem, a validação do token LTPA será bem-sucedida e prosseguirá com a autorização. Se as regiões não corresponderem, a validação do token falhará, já que o usuário da região externa não poderá ser validado na região atual do aplicativo. Se os aplicativos não precisarem se comunicar uns com os outros ao utilizarem RMI/IIOP e o mecanismo de autenticação LTPA, você não precisará fazer mais nada com relação a isso.
Se quiser que a comunicação de várias regiões seja bem-sucedida ao utilizar RMI/IIOP e tokens LTPA, primeiro você deverá estabelecer a confiança entre as regiões envolvidas, tanto para comunicações de entrada quanto de saída.
Para o servidor que origina o pedido, sua região deve ter as regiões nas quais ele pode confiar para enviar o token. Isso é chamado de outboundTrustedRealms. Para o servidor que recebe o pedido, sua região precisa confiar nas regiões das quais pode receber tokens LTPA. Isso é chamado de inboundTrustedRealms.
As regiões confiáveis de saída podem ser estabelecidas utilizando o comando addTrustedRealms com a opção –communicationType configurada como saída. Elas também podem ser estabelecidas no console administrativo clicando-se em Regiões de autenticação confiáveis - saída no painel Comunicações de saída do CSIv2.
As regiões confiáveis de entrada podem ser estabelecidas utilizando a mesma tarefa de comando addTrustedRealms com a opção –communicationType configurada como entrada. Elas também podem ser estabelecidas pelo uso do console administrativo.
A figura posterior nesta seção mostra a comunicação entre aplicativos que usam diferentes regiões do usuário (registros) usando RMI/IIOP. Neste exemplo, o aplicativo app1 (por exemplo, um servlet) é configurado para usar o registro do usuário realm1. O aplicativo app2 (por exemplo, um EJB) é configurado para utilizar o registro do usuário realm2. O usuário (user1) efetua login inicialmente no servlet no app1, que tenta acessar um EJB no app2. O seguinte deve ser definido:
- Em Domain1, realm1 deve confiar em realm2 para a comunicação de saída.
- Em Domain2, realm2 deve confiar em realm1 para a comunicação de entrada.
- O accessId para user1 deve ser configurado na tabela de autorizações para app2.
Quando o token LTPA que contém o accessId de user1 é recebido por app2, ele decriptografa o token. Os dois servidores compartilham as mesmas chaves LTPA. O token LTPA se certifica de que a região externa é uma região confiável e faz a autorização com base no accessId de user1. Se a propagação do atributo de segurança não estiver desativada, as informações sobre o grupo de user1 também serão propagadas para app2. Os grupos podem ser utilizados para a verificação de autorização, desde que a tabela de autorizações contenha informações sobre o grupo. É possível associar um assunto especial, AllAuthenticatedInTrustedRealms, às funções em vez de incluir usuários e grupos individuais na tabela de autorizações.
Se os aplicativos no exemplo anterior forem implementados em células diferentes, você deverá fazer o seguinte:
- Compartilhar chaves LTPA entre as células.
- Atualizar a tabela de autorizações para app2 com accessIds de usuários e grupos externos através do utilitário wsadmin. O console administrativo não tem acesso às regiões fora do escopo da célula.

Depois de estabelecida a confiança entre as regiões, quando o servidor receber o token LTPA e o token for decriptografado, ele verificará se a região externa está em sua lista de regiões confiáveis de entrada. Se ela for confiável, a autenticação será bem-sucedida. Entretanto, como ela é uma região externa, ela não procura o registro do usuário para reunir informações sobre ele. Todas as informações que estiverem no token LTPA serão utilizadas para autorizar o usuário.
A única informação do token LTPA é o ID exclusivo do usuário. Esse ID exclusivo do usuário deve existir na tabela de autorizações deste aplicativo. Se existir, a autorização será bem-sucedida. Entretanto, se a propagação do atributo estiver ativada, atributos de autorização adicionais (grupos aos quais esse usuário pertence) do usuário serão enviados do servidor de origem para o servidor de recebimento. Esses atributos adicionais são utilizados para tomar as decisões de acesso. Se as informações sobre os grupos existirem nos tokens de propagação, elas serão utilizadas ao tomar a decisão de autorização.
Conforme mencionado anteriormente, as informações sobre os usuários ou os grupos das regiões confiáveis devem existir na tabela de autorizações do aplicativo de recebimento. Especificamente, o accessId dos usuários e/ou grupos deve existir no arquivo de ligação do aplicativo. Esse deve ser o caso quando o aplicativo for implementado. No console administrativo, quando um aplicativo for implementado em um domínio, será possível incluir os accessIds dos usuários e grupos de qualquer uma das regiões confiáveis na tabela de autorizações.
Você também tem uma opção de associar um assunto especial, AllAuthenticatedInTrustedRealms, às funções em vez de incluir usuários e grupos individuais. Isto é semelhante ao assunto especial AllAuthenticated que é suportado atualmente. A diferença é que o assunto especial AllAuthenticated se refere aos usuários na mesma região que o aplicativo, enquanto o assunto especial AllAuthenticatedInTrustedRealms se aplica a todos os usuários nas regiões confiáveis e na região do aplicativo.
É possível associar o accessId utilizando o script de instalação $AdminApp. Como o accessId tem um formato exclusivo, use a tarefa de comando listRegistryUsers com displayAccessIds configurado como true. Se um nome ou formato inválido for inserido nesse campo, a autorização falhará.
As informações do usuário e do grupo das regiões confiáveis são obtidas pelo gerenciador de implementação, uma vez que ele tem acesso a todas as configurações de registro do usuário em todos os domínios. Entretanto, em determinadas situações, não é possível obter as informações sobre os usuários e grupos.
Por exemplo, se um servidor hospedado em um nó externo estiver utilizando localOS como o registro para seu domínio, o gerenciador de implementação não poderá obter as informações sobre os usuários e grupos, a menos que esteja executando na mesma instalação do sistema operacional. O sistema operacional externo deve ser contatado para obter essas informações. Isso pode ser feito diretamente chamando o registro do servidor associado a esse domínio. Os servidores associados ao domínio precisam estar iniciados para isso funcione. Você também deve configurar a propriedade, com.ibm.websphere.allowRegistryLookupOnProcess, como true nas propriedades customizadas de segurança de nível superior. Quando essa propriedade estiver definida, o código do gerenciador de implementação procurará um dos servidores associados ao domínio de segurança e obterá as informações sobre usuários e grupos diretamente dele. Isso é possível chamando um MBean em um dos servidores.
Se o MBean em algum dos servidores que estiver utilizando esse domínio não puder ser acessado, o console administrativo exibirá um painel em que será possível inserir o usuário e as informações do accessId manualmente para cada usuário e grupo. É importante que o formato correto do accessId seja inserido nesse campo. O formato do accessId do usuário é user:realmName/userUniqueId. O realmName é o nome da região em que o usuário reside e o userUniqueId é o uniqueId que representa o usuário, dependendo do registro que é utilizado.
Por exemplo, para LDAP, o uniqueUserId é o Nome Distinto (DN), para o registro do S.O. local Windows, é o SID do usuário. Para plataformas Unix, ele é o UID. Para registros customizados, ele depende da implementação.
Da mesma forma, para grupos, o formato accessId é group:realmName/groupUniqueId. Conforme mencionado anteriormente, utilize os comandos listRegistryUsers e listRegistryGroups com a opção –displayAccessIds configurada como true, para que seja possível obter o formato correto para o domínio ou a região na qual você está interessado.
Depois que os usuários e grupos das regiões confiáveis ou o objeto especial AllAuthenticatedInTrustedRealms seja incluído na tabela de autorizações do aplicativo, ele estará pronto para aceitar pedidos de outros aplicativos que estejam utilizando qualquer uma das regiões confiáveis. A validação do token LTPA no servidor de recebimento primeiro verifica para garantir que a região seja confiável. O mecanismo de autorização, então, verifica se o usuário externo e/ou os grupos ou o assunto especial AllAuthenticatedInTrustedRealms estão recebendo acesso às funções necessárias para acessar o recurso. Se tiverem, o acesso será concedido.
A comunicação cruzada da região é aplicável apenas ao utilizar a autorização incorporada do WebSphere. Se você estiver utilizando outros mecanismos de autorização, incluindo SAF para z/OS, qualquer autorização de região cruzada poderá ser obtida implementando os módulos de login customizados que mapeiam usuários externos para usuários em seu próprio repositório.
Associando um Nó com Domínios de Segurança
Quando um domínio de segurança for configurado em uma versão base e for associado a uma célula, o domínio de segurança configurado na versão base também será configurado para esse servidor na célula. A mesma configuração de segurança do domínio poderá ser utilizada pelo servidor antes e depois da federação. Se um servidor base tiver de ser associado a uma célula, o recurso designado ao domínio de segurança deverá ser o escopo do servidor em vez do escopo da célula.
Se for esperado que o servidor base seja registrado com um processo de Agente Administrativo, utilize o escopo da célula como o recurso se a intenção for que todos os servidores do perfil de base utilizem esse domínio de segurança.
Se durante a associação o domínio de segurança já existir no nível de célula, o comando addNode falhará. É possível usar a opção –excludesecuritydomains para não incluir o domínio de segurança durante a federação.
Quando o nó federado for removido de uma célula, os recursos nesse nó deverão ser removidos dos domínios de segurança. Se os domínios de segurança tiverem clusters associados a eles que estendam nós, os nós não serão removidos. É possível sempre remover recursos dos domínios de segurança ou de quaisquer domínios que não sejam usados utilizando comandos de script ou o console administrativo.
Domínios de Segurança em um Ambiente de Versão Mista
Você deve criar domínios de segurança, uma vez que todos os nós tenham sido migrados para a versão mais recente. Isso será especialmente verdadeiro se houver uma necessidade de associar a célula a um domínio. Entretanto, se você desejar criar domínios em um ambiente de versão mista, lembre-se do seguinte:
- Se um domínio de célula inteira for criado em uma configuração de versão mista, um domínio chamado PassThroughToGlobalSecurity será criado automaticamente.
Todos os clusters mistos são designados a esse domínio no momento da criação do domínio da célula inteira. Este domínio PassThroughToGlobalSecurity
é especial no sentido de que os atributos não podem ser incluídos nele, somente
recursos podem ser designados a ele.
Todos os recursos designados ao domínio PassThroughToGlobalSecurity usam as informações de configuração de segurança global. Sempre que um nó da configuração de versão mista for migrado para a versão mais recente, os servidores e os clusters desses nós serão incluídos nesse domínio. Os aplicativos em todos os servidores e clusters desses nós não utilizam o domínio da célula inteira; em vez disso, eles utilizam a configuração de segurança global antes e após a migração.
Se qualquer um destes servidores precisar usar o domínio de toda a célula, você deverá remover estes recursos deste domínio PassThroughToGlobalSecurity. Novos servidores e clusters que são criados no nó migrado usam o domínio de toda a célula, não o domínio PassThroughToGlobalSecurity. Como resultado, você tem uma mistura de servidores e clusters, alguns deles utilizando a configuração de segurança global e alguns utilizando o domínio da célula inteira.
- Depois de criado o domínio de célula inteira, a inclusão de algum membro de cluster de versão anterior em um cluster do WebSphere Application Server Versão 9.0 é restrita, pois essa ação resulta em um cluster misto. Essa restrição também ocorre quando um cluster do WebSphere Application Server Versão 9.0 está associado a um domínio. e um membro do cluster da versão anterior for incluído nesse cluster. Essa restrição será necessária para evitar a associação de um domínio de segurança em um cluster misto.
- Se possível, você deve criar um domínio da célula inteira depois que todos os nós tenham sido migrados. Nesse caso, o domínio da célula inteira será aplicável à célula inteira e não apenas a partes dela. Isto também elimina a necessidade de criar o domínio PassThroughToGlobalSecurity e o cenário de cluster misto com domínios de segurança.
Modificando Domínios de Segurança
Utilize as tarefas do console administrativo ou os comandos de script para modificar domínios de segurança. Para obter uma lista completa das tarefas administrativas e dos comandos de script, consulte os links em "Tarefas relacionadas" no final deste documento.
Uma vez que um domínio de segurança esteja criado e associado a um conjunto de escopos, os servidores associados a esse novo domínio deverá ser reiniciado. Depois de reiniciados, os aplicativos nos escopos associados ao novo domínio utilizam os atributos de segurança definidos no domínio.
Alterações a quaisquer dos atributos de domínio exigem o reinício de todos os escopos designados a ele. Se novos escopos forem incluídos, ele precisarão também ser reiniciados. Quaisquer modificações à configuração do domínio, seja nos atributos de segurança ou nos escopos, terá impacto nesses aplicativos que estão utilizando a configuração de domínio.
Antes de fazer modificações em um domínio existente, considere os possíveis impactos a seguir. Por exemplo, se um registro do usuário que estiver configurado em um domínio for removido e os servidores forem reiniciados, o registro do usuário do domínio da célula inteira (se um for definido) ou a configuração de segurança global será então utilizado. Isso pode impactar a autenticação e a autorização do aplicativo. Os usuários e grupos associados a um aplicativo pode não ser mais válido no novo registro. Outro exemplo a considerar é quando as configurações do JAAS são removidas de um domínio. Os aplicativos que dependem disso não são mais capazes de utilizar as configurações do JAAS. Sempre que uma configuração de segurança for alterada, pode impactar seus aplicativos, portanto todas as alterações na configuração de segurança devem ser feitas com o máximo cuidado.
![[z/OS]](../images/ngzos.gif)
PTFs de Tolerância Necessários para Ambientes de Release Misto
PTFs de tolerância são necessários para ambientes de liberação mista nos quais versões anteriores do WebSphere Application Server para clientes IIOP do z/OS interoperam com um servidor de aplicativos do WebSphere Application Server Versão 9.0 para z/OS que hospeda diversos domínios de segurança.
O cliente pré-Versão 9.0 IIOP requer uma atualização de seu código de processamento de local IIOP para executar localizações IIOP nos domínios de segurança de um servidor de aplicativos Versão 9.0.
WebSphere Application Server para
z/OS 5.1: W510246
WebSphere Application Server para
z/OS v6.0: 602.29
WebSphere Application Server para
z/OS v6.1: 610.17
Esse requisito se aplica apenas a clientes do IIOP do WebSphere para z/OS que chamam pedidos em relação ao servidor de aplicativos do WebSphere para z/OS com vários domínios de segurança configurados e ativados.