Capítulo 4. Arquitetura de Extensão de Segurança do JBoss
A discussão anterior da camada geral de segurança do JBoss declara que o JBoss Security Extension framework (JBossSX) é uma implantação das interfaces da camada de segurança. Este é o propósito principal do framework do JBossSX. O framework apresenta uma boa oferta de possibilidades de personalização para integração em infra-estruturas existentes. Uma infra-estrutura de segurança pode ser qualquer coisa de um banco de dados ou um servidor LDAP para um pacote de software de segurança sofisticado. A flexibilidade de integração é atingida usando o Pluggable Authentication Model (PAM) disponível no framework JAAS.
A parte principal do framework do JBOssSX é a implantação do
org.jboss.security.plugins.JaasSecurityManager. Esta é a implantação padrão das interfaces AuthenticationManager e RealmMapping. A Figura 4.1, “Relação entre o valor do descritor <security-domain> de implantação, recipiente do componente e JaasSecurityManager.” apresenta como o JaasSecurityManager integra-se ao EJB e camadas de recipientes da web, baseados no elemento <security-domain> do descritor de implantação do componente correspondente.

Figura 4.1. Relação entre o valor do descritor <security-domain> de implantação, recipiente do componente e JaasSecurityManager.
A Figura 4.1, “Relação entre o valor do descritor <security-domain> de implantação, recipiente do componente e JaasSecurityManager.” representa um aplicativo empresarial que contém ambos EJBs e conteúdo da web protegidos sob o
jwdomain de domínio de segurança. Os recipientes EJB e da web possuem um interceptor de arquitetura que reforça o modelo de segurança do recipiente. No período de implantação, o valor do elemento <security-domain> nos descritores jboss.xml e jboss-web.xml é usado para obter uma instância do gerenciador de segurança associada com o recipiente. Em seguida, o interceptor de segurança usa o gerenciador de segurança para executar sua função. Quando um componente protegido for solicitado, o interceptor de segurança delega checagens de segurança para proteger a instância do gerenciador de segurança associado com o recipiente.
A implementação JBossSX
JaasSecurityManager executa checagens de segurança baseadas na informação associada com a instância que resulta da execução dos módulos de logon JAAS configurados sob o nome de combinação do valor do elemento <security-domain>. Nós descreveremos mais a fundo a implementação JaasSecurityManager e seu uso na próxima seção.
4.1. Como o JaasSecurityManager usa o JAAS
O
JaasSecurityManager usa os pacotes JAAS para implementar o AuthenticationManager e o comportamento de interface RealmMapping. Basicamente, seu comportamento deriva de uma execução das instâncias do módulo de logon que estão configuradas sob o nome que coincide ao domínio de segurança pelo qual o JaasSecurityManager foi determinado. Os módulos de logon implantam a autenticação do principal do domínio de segurança e o comportamento do mapeamento de função. Portanto, você pode usar o JaasSecurityManager através de diferentes domínios de segurança simplesmente pela conexão de diferentes configurações de módulo do logon pelos domínios.
Para ilustração dos detalhes do uso do
JaasSecurityManager do processo de autenticação do JAAS, você passará pela invocação do cliente de uma invocação do método da página principal do EJB. O pré-requisito da configuração é que o EJB seja implantado no servidor do JBoss e seus métodos de interface da página principal sejam protegidos usando os elementos <method-permission> no descritor, além de ser determinado um domínio de segurança nomeado jwdomain, usando o descritor jboss.xml do elemento <security-domain>.

Figura 4.2. Etapas de Autenticação do Método da Página Principal do EJB e Invocação da Autorização.
A Figura 4.2, “Etapas de Autenticação do Método da Página Principal do EJB e Invocação da Autorização.” fornece uma visualização do cliente à comunicação do servidor. Segue abaixo as etapas numeradas:
- O cliente deve executar um logon JAAS para estabelecer o principal e os credenciais para a autenticação, além de ser etiquetado Logon ao Lado do Cliente na figura. Este é o procedimento de como os clientes estabelecem suas identidades no JBoss. O suporte para apresentação da informação de logon através das propriedades
InitialContextdo JNDI é fornecido através de uma configuração alternativa.O logon JAAS implica na criação de uma instânciaLoginContexte passagem do nome da configuração a ser usada. O nome da configuração éother. Este logon de uma única vez associa o principal do logon e as credenciais com todas as invocações do método EJB subsequentes. Perceba que o processo pode não ser autenticado pelo usuário. A natureza do logon ao lado do cliente depende da configuração do módulo de logon que o cliente usa. Nesta amostra, a entrada da configuração do logon ao lado do clienteotheré configurada para uso do móduloClientLoginModule(umorg.jboss.security.ClientLoginModule). Este é o módulo ao lado do cliente padrão que simplesmente efetua o bind no nome do usuário e senha para a camada de invocação EJB do JBoss para uma autenticação mais tarde no servidor. A identidade do cliente não é autenticada no cliente. - O cliente obtém uma interface da página principal do EJB e tenta criar um bean. Esse evento é etiquetado como a Invocação do Método de Página Principal. Isto resulta no envio da invocação do método da interface de página principal ao servidor do JBoss. A invocação inclui os argumentos do método passados pelo cliente, juntamente com a identidade do usuário e credenciais do logon do JAAS ao lado do cliente, executados na Etapa 1.
- No lado do servidor, o interceptor de segurança primeiramente requer a autenticação do usuário invocando a chamada, que uma vez ao lado do cliente, envolve o logon do JAAS.
- O domínio de segurança pelo qual o EJB é protegido determina a escolha dos módulos de logon. O nome do domínio de segurança é usado como o nome da entrada da configuração do logon passado ao construtor
LoginContext. O domínio de segurança EJB é ojwdomain. Caso o logon do JAAS autenticar o usuário, o JAASSubjecte contém o seguinte em seuPrincipalsSet:- O
java.security.Principalque corresponde à identidade do cliente, como é conhecida no ambiente de segurança da implantação. - O
java.security.acl.GroupnomeadoRolesque contém o nome de função a partir do domínio do aplicativo pelo qual o usuário é determinado. Os objetosorg.jboss.security.SimplePrincipalsão usados para representar os nomes de função. OSimplePrincipalé uma implantação baseada na sequência simples doPrincipal. Essas funções são usadas para validar as funções determinadas aos métodos noejb-jar.xmle na implantação do métodoEJBContext.isCallerInRole(String). - Um
java.security.acl.Groupopcional nomeadoCallerPrincipal, que contém umorg.jboss.security.SimplePrincipalúnico que corresponde à identidade do chamador do domínio do aplicativo. O membro do grupo únicoCallerPrincipalserá o valor retornado pelo métodoEJBContext.getCallerPrincipal(). O propósito do mapeamento é permitir umPrincipaltambém conhecido no ambiente de segurança opcional para mapear umPrincipalcom o nome conhecido pelo aplicativo. Na ausência de um mapeamentoCallerPrincipal, o principal do ambiente de segurança implantado é usado como o valor do métodogetCallerPrincipal. Quer dizer, o principal operacional é o mesmo que o principal do domínio do aplicativo.
- O passo final da checagem do interceptor de segurança é verificar que o usuário autenticado possui permissão para invocar o método solicitado. Isto é etiquetado como Autorização ao lado do servidor na Figura 4.2, “Etapas de Autenticação do Método da Página Principal do EJB e Invocação da Autorização.”. As seguintes etapas descrevem a execução da autorização:
- Obtém os nomes das funções permitidas para acesso ao método EJB a partir do container. Os nomes da função são determinados pelo descritor
ejb-jar.xmldos elementos <role-name> de todos os elementos <method-permission> contendo o método invocado. - Caso nenhuma função tenha sido determinada ou o método seja especificado num elemento exclude-list, o acesso ao método será negado. Do contrário, o método
doesUserHaveRoleé invocado no gerenciador de segurança pelo interceptor de segurança para verificar se o chamador possui um dos nomes de função determinados. Esse método interage através dos nomes de função e checa se o grupoRolesdo Assunto do usuário autenticado contém umSimplePrincipalcom o nome de função determinado. O acesso é permitido caso qualquer nome de função seja membro do grupoRoles. O acesso é negado caso nenhum dos nomes de funções forem membros. - Caso o EJB for configurado por um proxy de segurança personalizada, a invocação de método é delegada também. Caso o proxy de segurança desejar negar acesso ao chamador, ele lançará um
java.lang.SecurityException. Caso nenhumSecurityExceptionfor lançado, o acesso ao método é permitido e a invocação de método passa ao próximo interceptor do recipiente. Perceba que oSecurityProxyInterceptormanuseia esta checagem e este interceptor não é apresentado. - O Tomcat gerencia elementos de restrição de segurança e verificação de função para as conexões do JBoss Web.Quando uma solicitação receber uma conexão da web, o Tomcat checa as restrições de segurança definidas no
web.xmlque coincide com o recurso solicitado e o método HTTP acessado.Caso uma restrição existir, o Tomcat chama o JaasSecurityManager para executar a autenticação principal, que em troca garante que as funções do usuário sejam associadas com o objeto do principal.A verificação da função é executada inteiramente pelo Tomcat, incluindo as checagens dos parâmetros, tais comoallRolese se é que oSTRICT_MODEé usado ou não.
Cada invocação do método EJB protegido, ou acesso do conteúdo da web protegido, requer a autenticação e autorização do chamador uma vez que a informação de segurança é manuseada como um atributo sem estado da solicitação que deve ser apresentada e validada em cada solicitação. Isto pode ser uma operação cara caso o logon do JAAS envolver a comunicação cliente-para-servidor. Devido a isto, o
JaasSecurityManager suporta a noção de um cache de autenticação que é usado para armazenar a informação do principal e credencial a partir dos logons anteriores bem sucedidos. Você pode especificar a instância do cache de autenticação para uso como parte da configuração JaasSecurityManager conforme descrito na seção seguinte do serviço MBean associado. Na ausência de qualquer cache de usuário definido, o cache padrão que mantém a informação do credencial para o período de tempo configurável será usado.