Propagação de Atributo de Segurança

Com propagação do atributo de segurança, o WebSphere Application Server pode transportar atributos de segurança (conteúdo de Assunto autenticado e informações de contexto de segurança) de um servidor para outro em sua configuração. O WebSphere Application Server pode obter esses atributos de segurança de um registro do usuário corporativo, que consulta atributos estáticos, ou de um módulo de login customizado, que pode consultar atributos estáticos ou dinâmicos. Os atributos dinâmicos de segurança, que são customizados por natureza, podem incluir a força de autenticação utilizada para a conexão, a identidade do responsável pela chamada original, o local do responsável pela chamada original, o endereço IP do responsável pela chamada original, etc.

A propagação do atributo de segurança fornece serviços de propagação utilizando a serialização Java™ para quaisquer objetos que estejam contidos no Objeto. Entretanto, o código Java deve ser capaz de serializar e desserializar esses objetos. A linguagem de programação Java especifica as regras de como o código Java pode serializar um objeto. Como podem ocorrer problemas ao lidar com diferentes plataformas e versões de software, o WebSphere Application Server também oferece uma estrutura de token que permite customizar a funcionalidade da serialização. A estrutura de tokens possui outros benefícios que incluem a habilidade de identificar a exclusividade do token. Essa singularidade determina como o Assunto é armazenado em cache e o objetivo do token. A estrutura de token define quatro interfaces de token de marcador que ativam o tempo de execução do WebSphere Application Server a determinar como propagar o token.

Importante: Todo token customizado utilizado nessa estrutura não é usado pelo WebSphere Application Server para autorização ou autenticação. A estrutura serve como uma forma de notificar o WebSphere Application Server que você deseja que esses tokens sejam propagados de uma maneira particular. O WebSphere Application Server trata de detalhes da propagação, mas não lida com serialização ou desserialização de tokens customizados. A serialização e a desserialização desses tokens customizados são feitas pela implementação e manipuladas por um módulo de login customizado.

Com o WebSphere Application Server Versão 6.0 e posterior, um provedor customizado do Java Authorization Contract for Container (JACC) pode ser configurado para reforçar o controle de acesso de aplicativos do Java Platform, Enterprise Edition (Java EE). Um provedor JACC customizado pode explorar os atributos de segurança customizados no assunto do JAAS do responsável pela chamada ao tomar decisões sobre o controle de acesso.

Ao autenticar um pedido, os módulos de login determinam se esse pedido é um login inicial ou um login de propagação. Um login inicial é o processo de autenticar as informações do usuário, geralmente um ID do usuário e senha, e, em seguida, chamar as APIs (interfaces de programação de aplicativos) do registro do usuário remoto para procurar atributos seguros que representam os direitos de acesso do usuário. Um login de propagação é o processo de validar as Informações sobre o usuário, normalmente um token Lightweight Third Party Authentication (LTPA), e então desserializar uma série de tokens que constituem objetos customizados e objetos de estruturas de token conhecidos como WebSphere Application Server.

Os tokens marcadores a seguir são introduzidos na estrutura:
Token de Autorização
O token de autorização contém a maioria dos atributos de segurança relacionados à autorização que são propagados. O token de autorização padrão é utilizado pelo mecanismo de autorização do WebSphere Application Server para fazer com que o Java Platform, Enterprise Edition (Java EE) tome as decisões de autorização. Os fornecedores de serviços podem utilizar as implementações customizadas de tokens de autorização para isolar seus dados em um token diferente; desempenhar serialização e desserialização customizadas e tomar decisões de autorização customizadas utilizando as informações em seus tokens, no momento apropriado. Para obter informações sobre como utilizar e implementar esse tipo de token, consulte Using the default propagation token to propagate security attributes e Implementing a custom propagation token for security attribute propagation.
Token SSO (Conexão Única)
Um token SingleSignonToken customizado que é incluído no Assunto é automaticamente incluído na resposta como um cookie de HTTP e contém os atributos enviados de volta aos navegadores da Web. O método getName da interface do token com o método getVersion definem o nome do cookie. O WebSphere Application Server define um token SingleSignonToken padrão com o nome LtpaToken e Versão 2. O nome do cookie incluído é LtpaToken2. Não inclua informações sensitivas, informações confidenciais ou dados criptografados no cookie de resposta.

Recomenda-se também que ao utilizar cookies, deve-se utilizar o protocolo SSL (Secure Sockets Layer) para proteger o pedido. Usando um token SSO, os usuários da web podem autenticar-se uma vez ao acessar recursos da web em vários WebSphere Application Server. Um token SSO customizado amplia essa funcionalidade, incluindo processamento customizado no cenário de conexão única. Para obter informações adicionais sobre tokens de SSO, consulte Implementando a Conexão Única para Minimizar as Autenticações do Usuário da Web. Para obter informações sobre como utilizar e implementar esse tipo de token, consulte Using the default single sign-on token with default or custom token factory to propagate security attributes e Implementing a custom single sign-on token for security attribute propagation.

Token de Propagação
O token de propagação não está associado ao usuário autenticado, portanto, não é armazenado no Assunto. Em vez disso, o token de propagação é armazenado no encadeamento e segue a chamada onde quer que ela vá. Quando um pedido é enviado para saída para outro servidor, os tokens de propagação desse encadeamento são enviados com o pedido e são executados pelo servidor de destino. Os atributos que são armazenados no encadeamento são propagados independentemente dos comutadores do usuário RunAs do Java Platform, Enterprise Edition (Java EE).

O token de propagação padrão monitora e registra todas as alterações de usuários e de hosts. É possível incluir informações adicionais no token de propagação padrão utilizando as APIs (interfaces de programação de aplicativos) do WSSecurityHelper. Para recuperar e definir as implementações customizadas de um token de propagação, é possível utilizar a classe WSSecurityPropagationHelper. Para obter informações sobre como utilizar e implementar esse tipo de token, consulte Using the default propagation token to propagate security attributes e Implementing a custom propagation token for security attribute propagation.

Token de Autenticação
O token de autenticação flui para servidores de recebimento de dados e contém a identidade do usuário. Esse tipo de token tem a mesma função que o token LTPA (Lightweight Third Party Authentication) de versões anteriores. Embora esse tipo de token normalmente seja reservado a fins internos do WebSphere Application Server, é possível incluir esse token ao Assunto e o token é propagado usando o método getBytes da interface do token.

Um token de autenticação customizado é utilizado somente para a finalidade do fornecedor de serviços que o inclui no Assunto. O WebSphere Application Server não o utiliza para fins de autenticação porque uma autenticação padrão existe e é usada para autenticação do WebSphere Application Server. Esse tipo de token está disponível para o fornecedor de serviços para identificar como os dados customizados utilizam o token para tomar decisões de autenticação customizadas. Para obter informações sobre como utilizar e implementar esse tipo de token, consulte Default authentication token e Implementing a custom authentication token for security attribute propagation.

Token de autenticação Kerberos
O token de autenticação do Kerberos contém as credenciais do Kerberos, como nome do Kerberos principal, GSSCredential e credencial de delegação do Kerberos. Esse token é propagado para o servidor de recebimento de dados. Embora esse tipo de token normalmente seja reservado para fins internos do WebSphere Application Server, se ele tiver o GSSCredential é possível usar o método getGSSCredential para extrair o GSSCredential. É possível, então, colocá-lo no objeto para ser utilizado para seu aplicativo. Esse token é criado quando você autentica-se no WebSphere Application Server com autenticação do Kerberos ou da Web SPNEGO.

Propagação Horizontal versus Propagação de Recebimento de Dados

Em WebSphere Application Server, tanto a propagação horizontal, que utiliza conexão única para pedidos da Web, quanto a propagação downstream, que utiliza a Chamada de Método Remoto via Internet Inter-ORB Protocol (RMI/IIOP) para acessar enterprise beans, estão disponíveis.

Propagação Horizontal

Na propagação horizontal, os atributos de segurança são propagados entre servidores front-end. Os atributos de segurança serializados, que são o conteúdo do Assunto e os tokens de propagação, podem conter atributos estáticos e dinâmicos. O token SSO (Conexão Única) armazena informações adicionais específicas do sistema necessárias para propagação horizontal. As informações contidas no token de SSO indica ao servidor de recebimento onde o servidor de origem está localizado e como comunicar-se com esse servidor. Além disso, o token de SSO também contém a chave para consultar os atributos serializados. Para ativar a propagação horizontal, você deve configurar o token de conexão única e os recursos de propagação do atributo de segurança de entrada da Web. É possível configurar esses dois recursos utilizando o console administrativo.

Quando os servidores de front-end estão configurados e no mesmo domínio de replicação do DRS (Data Replication Service), o servidor de aplicativos automaticamente propaga as informações serializadas para todos os servidores no mesmo domínio. Na figura 1, o aplicativo 1 é implementado no servidor 1 e no servidor 2 e os dois servidores são membros do mesmo domínio de replicação do DRS. Se um pedido originar do aplicativo 1 no servidor 1 e, em seguida, for redirecionado para o aplicativo 1 no servidor 2, os atributos de login originais serão localizados no servidor 2 sem pedidos remotos adicionais.

No entanto, se o pedido originar do aplicativo 1 no servidor 1 ou no servidor 2, mas o pedido for redirecionado para o aplicativo 2 no servidor 1 ou no servidor 2, as informações serializadas não serão localizadas no cache do DRS, pois os servidores não estão configurados no mesmo domínio de replicação. Como resultado, um pedido remoto JMX (Java Management Extensions) é enviado de volta ao servidor de origem que hospeda o aplicativo 1 para obter as informações serializadas de modo que as informações de login originais estejam disponíveis para o aplicativo. Obtendo as informações serializadas utilizando um único retorno de chamada remota JMX para o servidor de origem, os benefícios a seguir são obtidos:
  • Você obtém a função de recuperar informações de login do servidor original.
  • Você não precisa executar nenhuma chamada remota do registro do usuário, pois o servidor de aplicativos pode gerar novamente o Assunto a partir das informações serializadas. Sem essa capacidade, o servidor de aplicativos pode fazer de cinco a seis chamadas remotas separadas.
Figura 1. Propagação HorizontalPropagação horizontal

Implicações de Desempenho para Propagação Horizontal

As implicações de desempenho da chamada remota do DRS ou JMX dependem de seu ambiente. A chamada remota do DRS ou JMX é utilizada para obter os atributos de login originais. A propagação horizontal reduz muitas das chamadas remotas do registro do usuário, nos casos em que essas chamadas causam a maioria dos problemas de desempenho de um aplicativo. No entanto, a desserialização desses objetos também pode causar degradação de desempenho, mas essa degradação pode ser menor do que a das chamadas remotas do registro do usuário. Recomenda-se testar seu ambiente com propagação horizontal ativada e desativada. Nos casos em que você deve utilizar a propagação horizontal para preservar os atributos de login originais, teste se DRS ou JMX fornece melhor desempenho em seu ambiente. Geralmente, recomenda-se configurar o DRS por motivos de failover e desempenho. No entanto, como o DRS propaga informações para todos os servidores do mesmo domínio de replicação (sendo os servidores acessados ou não), pode haver uma degradação de desempenho se muitos servidores estiverem no mesmo domínio de replicação. Nesse caso, reduza o número de servidores no domínio de replicação ou não configure os servidores em um domínio de replicação do DRS. A segunda sugestão faz com que uma chamada remota JMX recupere os atributos, quando necessário, o que pode ser mais rápido em geral.

Cache de segurança (WSSecureMap)

Na Figura 1, o cache de segurança (WSSecureMap) é o cache dinâmico usado para propagação de atributo de segurança. O cache WSSecureMap armazena atributos de segurança usados para recriar credenciais de usuário; ele é escalado com o número de usuários que efetuam login. O tempo de vida padrão de WSSecureMap é o mesmo que o tempo limite do token LTPA. Ou seja, as entradas de cache WSSecureMap são liberadas quando o usuário tiver efetuado logout. O padrão de uso para WSSecureMap é regular.

Configure o tamanho do cache WSSecureMap no console administrativo. (Segurança > Segurança global > Propriedades customizadas > Novo) e defina com.ibm.ws.security.WSSecureMapInitAtStartup e com.ibm.ws.security.WSSecureMapSize para controlar como o cache é usado.

Propagação de Recebimento de Dados

Em propagação de recebimento de dados, um Assunto é gerado no servidor front-end da Web, tanto por um login de propagação ou por um login de registro do usuário. O WebSphere Application Server propaga o recebimento de dados com informações de segurança para chamadas de enterprise bean quando ambas, a saída de Chamada de Método Remoto e a propagação de entrada estão ativadas.

Benefícios da Propagação dos Atributos de Segurança

O recurso de propagação do atributo de segurança do WebSphere Application Server possui dois benefícios a seguir:

  • Ativa o WebSphere Application Server a usar as informações do atributo de segurança para fins de autenticação e autorização. A propagação dos atributos de segurança pode eliminar a necessidade de chamadas do registro do usuário em cada salto remoto ao longo de uma chamada. Versões anteriores do WebSphere Application Server propagaram somente o nome de usuário do usuário autenticado, mas ignoraram outras informações de atributo de segurança que precisavam ser recriadas em recebimento de dados usando as chamadas de registro de usuário remoto. Para destacar os benefícios dessa nova funcionalidade, considere o exemplo a seguir:

    Em releases anteriores, é possível utilizar um servidor proxy reverso (RPSS), como o WebSEAL, para autenticar o usuário, reunir informações do grupo e reunir outros atributos de segurança. Conforme informado anteriormente, o WebSphere Application Server aceitou a identidade do usuário autenticado, mas desaprovou as informações adicionais do atributo de segurança. Para criar um Assunto do Java Authentication e Authorization Service (JAAS) contendo os objetos WSCredential e WSPrincipal necessários, o WebSphere Application Server fez de 5 a 6 chamadas para o registro do usuário. O objeto WSCredential contém várias informações de segurança que são necessárias para autorizar um recurso do Java EE. O objeto WSPrincipal contém o nome da região e o usuário que representa o proprietário do Assunto.

    Na liberação atual do servidor de aplicativos, as informações obtidas do servidor de proxy reverso podem ser usadas pelo WebSphere Application Server e propagadas em recebimento de dados a outros recursos do servidor, sem chamadas adicionais para registro de usuário. O restante das informações do atributo de segurança permite que você proteja os recursos do servidor adequadamente, concedendo a autorização apropriada e tomando decisões com base na confiança. Os comutadores de usuários que ocorrem devido às configurações de RunAs do Java EE não fazem com que o servidor de aplicativos perca as informações originais do responsável pela chamada. Essas informações são armazenadas no PropagationToken localizado no encadeamento em execução.

  • Permite que fornecedores terceirizados se conectem em tokens customizados. A interface do token contém um método getBytes que permite que a implementação do token defina a serialização customizada, os métodos de criptografia, ou ambos.
  • Fornece a capacidade de ter vários tokens do mesmo tipo em um Assunto criado por diferentes fornecedores. O WebSphere Application Server pode tratar de vários tokens para o mesmo propósito. Por exemplo, é possível ter vários tokens de autorização no Assunto e cada token pode ter atributos de autorização distintos que são gerados por diferentes fornecedores.
  • Fornece a capacidade de ter um ID exclusivo para cada tipo de token utilizado para formular um identificador de Assunto mais exclusivo do que apenas o nome do usuário em casos em que atributos dinâmicos podem alterar o contexto de um login do usuário. O tipo de token tem um método getUniqueId() que é utilizado para retornar uma cadeia exclusiva para finalidades de armazenamento em cache. Por exemplo, é possível precisar propagar um ID de local, que indica o local a partir do qual o usuário efetua login no sistema. Esse ID de local pode ser gerado durante o login original utilizando um servidor proxy reverso ou a configuração de login WEB_INBOUND e incluído no Assunto antes da serialização. Outros atributos também podem ser incluídos no Assunto e utilizar um ID exclusivo. Todos os IDs exclusivos devem ser considerados para a exclusividade de todo o Assunto. O WebSphere Application Server tem capacidade de especificar o que é exclusivo sobre as informações no Assunto, o que pode afetar a maneira como o usuário acessa o Assunto posteriormente.

Í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_secattributeprop
Nome do arquivo: csec_secattributeprop.html