Guia de Segurança

Plataforma do Aplicativo JBoss Enterprise 6.2

Para uso com a Plataforma do Aplicativo JBoss Enterprise 6

Sande Gilda

Darrin Mison

David Ryan

Misty Stanley-Jones

Tom Wells

Resumo

Este livro é um guia para a segurança do JBoss Enterprise Application Plataform 6 e seus lançamentos de patch.

Parte I. Segurança para o JBoss Enterprise Application Plataform 6

Capítulo 1. Introdução

1.1. Red Hat JBoss Enterprise Application Platform 6 (JBoss EAP 6)

O JBoss Enterprise Application Plataform 6 (JBoss EAP 6) é uma plataforma de middleware potente, segura e rápida construída sobre os padrões de código aberto e compatível com a especificação do Java Enterprise Edition 6. Ela integra o JBoss Aplication Server 7 com cluster de alta disponibilidade, mensagem potente, cache distribuído e outras tecnologias para criação de uma plataforma estável e escalável.
A nova estrutura modular permite que serviços sejam habilitados apenas quando requeridos, aumentando significantemente a velocidade de iniciação. O Console de Gerenciamento e a Interface da Linha de Comando removem a necessidade de editar os arquivos de configuração XML manualmente, adicionando a habilidade de script e tarefas automáticas. Além disso, ela inclui os frameworks de desenvolvimento que podem ser usados para a segurança do desenvolvimento e aplicativos Java EE escalável rapidamente.
Reportar um erro

1.2. Segurança do JBoss Enterprise Application Platform 6

Segurança de computadores é um termo geral dado ao campo da tecnologia de informação que lida com a segurança dos ambientes virtuais que energizam a idade digital. Isto pode incluir proteção de dados e integridade, provas de risco e vulnerabilidade e protocolos de autenticação e autorização.
Os dados do computador é um bem muito importante para a maioria das organizações. A proteção de dados é vital e forma o core da maioria dos negócios. O JBoss EAP fornece uma abordagem de multicamada à segurança para cuidar dos dados de todos os estágios.
Os sistemas de segurança verdadeiros são aqueles designados de baixo para cima com a segurança como o recurso principal. Tais sistemas usam o princípio de Segurança por Design. Em tais sistemas, os ataques maléficos e infiltrações são aceitas como parte e parcela do aparato de segurança normal e os sistemas são designados a funcionar ao redor deles.
A segurança pode ser aplicada no nível do sistema operacional, middleware e aplicativo. Por favor refira-se ao Guia de Segurança do Red Hat Enterprise Linux para maiores informações sobre a segurança no nível do sistema operacional.
Nos capítulos adiante, você irá ler a respeito dos diferentes níveis e camadas de segurança com o JBoss EAP 6. Essas camadas fornecem a infraestrutura para todas as funcionalidades de segurança com a plataforma.
Reportar um erro

Capítulo 2. Visão Geral da Segurança

2.1. Segurança Declarativa

O Declarative security é o método de separar as questões de segurança de seu código de aplicativo pelo uso do contêiner para gerenciar a segurança. O contêiner usa um sistema de autorização baseado tanto nas permissões de arquivo ou usuários, grupos e funções. Essa abordagem é normalmente superior à segurança programmatic, que fornece ao próprio aplicativo toda a responsabilidade de segurança.
O JBoss EAP 6 fornece uma segurança declarativa através dos security domains.
Reportar um erro

2.1.1. Visão Geral do Java EE Declarative Security

O modelo de segurança J2EE é declarativo na forma que você descreve as funções de segurança e permissões num descritor XML padrão ao invés de incorporar segurança em seu componente comercial. Isto isola a segurança do código de nível comercial uma vez que a segurança tende a ser uma função onde o componente é implantado de um aspecto hereditário da lógica comercial do componente. Por exemplo, considere um Automated Teller Machine (ATM - Caixa Eletrônico) que é usado para acessar uma conta bancária. As solicitações de segurança, funções e permissões irão variar independente de como você acessa a conta bancária, baseado em qual banco você está gerenciando sua conta, onde o caixa eletrônico está localizado, entre outros.
O fornecimento de segurança ao aplicativo J2EE é baseado na especificação das solicitações de segurança do aplicativo pelo uso dos descritores de implantação ejb-jar.xml e web.xml.
Reportar um erro

2.1.2. Referências de Segurança

Ambos Enterprise Java Beans (EJBs) e servlets podem declarar um ou mais elementos <security-role-ref>.
Ilustração do Modelo de Referência de Segurança

Figura 2.1. Modelo de Referência das Funções de Segurança

Este elemento declara que o componente está usando o valor do atributo role-nameType do elemento <role-name> como um argumento ao método isCallerInRole(String). Com o uso do método isCallerInRole, um componente pode verificar se é que o chamador está em uma função que foi declarada com um elemento <security-role-ref> ou <role-name>. O valor do elemento <role-name> deve ser ligado ao elemento <security-role> através do elemento <role-link>. O uso típico do isCallerInRole é executar uma verificação de segurança que não pode ser definida usando os elementos de função baseada no <method-permissions>.

Exemplo 2.1. Fragmento do descritor ejb-jar.xml

  
  <!-- A sample ejb-jar.xml fragment -->
    <ejb-jar>
      <enterprise-beans>
        <session>
          <ejb-name>ASessionBean</ejb-name>
          ...
          <security-role-ref>
            <role-name>TheRoleICheck<role-name>
              <role-link>TheApplicationRole</role-link>
          </security-role-ref>
        </session>
      </enterprise-beans>
    ...
    </ejb-jar>

Nota

Este fragmento é uma amostra apenas. Nas implantações, os elementos desta seção devem conter nomes de função e links à implantação EJB.

Exemplo 2.2. Fragmento do descritor web.xml


<web-app>
  <servlet>
    <servlet-name>AServlet</servlet-name>
    ...
    <security-role-ref>
      <role-name>TheServletRole</role-name>
      <role-link>TheApplicationRole</role-link>
    </security-role-ref>
  </servlet>
    ...
</web-app>
Reportar um erro

2.1.3. Identidade de Segurança

O Enterprise Java Bean (EJB) pode especificar a identidade que outro EJB deve usar quando invoca métodos em componentes usando o elemento <security-identity>.
Ilustração do Modelo de Identidade de Segurança J2EE

Figura 2.2. Modelo de Dados da Identidade de Segurança J2EE

A identidade da invocação pode ser o chamador atual ou pode ser uma função específica. O assembler do aplicativo usa o elemento <security-identity> com um elemento filho <use-caller-identity>. Isto indica que a identidade do chamador atual deve ser propagada como a identidade de segurança para invocações do método feitas pelo EJB. A propagação da identidade de segurança é o default usado na ausência de uma declaração do elemento <security-identity> explícito.
Alternativamente, o assembler do aplicativo pode usar o elemento filho <run-as> ou <role-name> para especificar que a função de segurança específica fornecida pelo valor do elemento <role-name> deve ser usada como identidade de segurança para as invocações do método realizadas pelo EJB.
Perceba que isto não altera a identidade do chamador conforme visto pelo método EJBContext.getCallerPrincipal(). Ao invés disto, as funções de segurança do chamador são configuradas à função única especificada pelo valor do elemento <run-as> ou <role-name>.
Um caso de uso para o elemento <run-as> é prevenir que clientes externos de acessarem os EJBs internos. Você configura este comportamento pela determinação dos elementos <method-permission> EJB internos, que restringem o acesso à função nunca determinada a um cliente externo. Os EJBs que em troca usam os EJBs internos são então configurados a um <run-as> ou <role-name> igual à função restringida. O seguinte fragmento do descritor descreve uma amostra de uso do elemento <security-identity>. 

<ejb-jar>
    <enterprise-beans>
        <session>
            <ejb-name>ASessionBean</ejb-name>
            <!-- ... -->
            <security-identity>
                <use-caller-identity/>
            </security-identity>
        </session>
        <session>
            <ejb-name>RunAsBean</ejb-name>
            <!-- ... -->
            <security-identity>
                <run-as>
                    <description>A private internal role</description>
                    <role-name>InternalRole</role-name>
                </run-as>
            </security-identity>
        </session>
    </enterprise-beans>
    <!-- ... -->
</ejb-jar>
Quando você usa <run-as> para determinar uma função específica para chamadas de saída, um principal nomeado anonymous é determinado a todas as chamadas de saída. Caso você deseje que outro principal seja associado com a chamada, você deve associar um <run-as-principal> com o bean no arquivo jboss.xml. O seguinte fragmento associa um principal nomeado internal com o RunAsBean a partir da amostra anterior. 

<session>
    <ejb-name>RunAsBean</ejb-name>
    <security-identity>
        <run-as-principal>internal</run-as-principal>
    </security-identity>
</session>
O elemento <run-as> também está disponível em definições servlet no arquivo web.xml. A seguinte amostra apresenta como determinar a função InternalRole a um servlet: 

  <servlet>
    <servlet-name>AServlet</servlet-name>
    <!-- ... -->
    <run-as> 
        <role-name>InternalRole</role-name>
    </run-as>
  </servlet>
As chamadas a partir deste servlet são associadas com o principal anônimo. O elemento <run-as-principal> está disponível no arquivo jboss-web.xml para determinar um principal específico para ir junto com a função run-as. O seguinte fragmento apresenta com associar um principal nomeado internal para o servlet acima. 

  <servlet>
    <servlet-name>AServlet</servlet-name>
    <run-as-principal>internal</run-as-principal>
  </servlet>
Reportar um erro

2.1.4. Funções de Segurança

O nome de função de segurança referenciado tanto pelo elemento security-role-ref ou security-identity precisa mapear uma das funções declaradas do aplicativo. Um assembler do aplicativo define as funções de segurança lógica pela declaração dos elementos security-role. O valor role-name é um nome de função do aplicativo lógico como Administrador, Arquiteto, Gerente de Vendas, etc.
A nota importante a ser lembrada sobre as especificações J2EE é que as funções de segurança no descritor de implantação são usadas para definir a visualização de segurança de um aplicativo. As funções definidas nos descritores de implantação não devem ser confundidas com os grupos de usuários, usuários, principais e outros conceitos que existem no ambiente operacional enterprise de destino. As funções do descritor de implantação são construções com os nomes de domain específicos do aplicativo. Por exemplo, um aplicativo de banco pode usar nomes de função tais como Gerente de Banco, Caixa ou Cliente.
No JBoss EAP, um elemento security-role é apenas usado para mapear os valores security-role-ref/role-name à função lógica que a função do componente referencia. As funções determinadas do usuário são uma função dinâmica do gerenciador de segurança do aplicativo. O JBoss não requer a definição dos elementos security-role com o objetivo de declarar as permissões do método. No entanto, a especificação dos elementos security-role continua uma prática de garantia de portabilidade pelos servidores e para a manutenção do descritor da implantação.

Exemplo 2.3. Um fragmento do descritor ejb-jar.xml que ilustra o uso do elemento security-role.

<!-- A sample ejb-jar.xml fragment --><ejb-jar><assembly-descriptor><security-role><description>The single application role</description><role-name>TheApplicationRole</role-name></security-role></assembly-descriptor></ejb-jar>

Exemplo 2.4. Uma amostra do fragmento do descritor ejb-jar.xml que ilustra o uso do elemento security-role.

<!-- A sample web.xml fragment --><web-app><security-role><description>The single application role</description><role-name>TheApplicationRole</role-name></security-role></web-app>
Reportar um erro

2.1.5. Permissões de Método EJB

Um assembler do aplicativo pode determinar as funções que são permitidas para invocar a página principal do EJB e os métodos de interface remota através das declarações do elemento method-permission.
Ilustração do elemento de permissões do método J2EE

Figura 2.3. Elemento de Permissões do Método J2EE

Cada elemento method-permission contém um ou mais elementos filho role-name que definem as funções lógicas que são permitidas para acessar os métodos EJB conforme identificado pelos elementos filho do método. Você também pode especificar o elemento unchecked ao invés do elemento role-name para declarar que qualquer usuário autenticado pode acessar os métodos indentificados pelos elementos filho do método. Além disso, você pode declarar que ninguém deve acessar um método que possui o elemento exclude-list. Caso um EJB possu métodos que não foram declarados por uma função usando um elemento method-permission, os métods EJB possuem o default para serem excluídos do uso. Isto é equivalente ao default dos métodos no exclude-list.
Ilustração do elemento do método J2EE

Figura 2.4. Elemento do Método J2EE

Existem três estilos suportados das declarações do elemento do método.
A primeira é usada para referência a todos os métodos da interface do componente e da página principal do bean enterprise nomeado: 
<method><ejb-name>EJBNAME</ejb-name><method-name>*</method-name></method>
O segundo estilo é usado para referenciar o método especificado da interface do componente ou página principal do bean enterprise nomeado: 
  <method><ejb-name>EJBNAME</ejb-name><method-name>METHOD</method-name></method>
Caso exista múltiplos métodos com o mesmo nomes sobrecarregado, este estilo refere-se a todos os dos métodos sobrecarregados.
O terceiro estilo é usado para referir-se a um método com um conjunto de método com o nome sobrecarregado: 
<method><ejb-name>EJBNAME</ejb-name><method-name>METHOD</method-name><method-params><method-param>PARAMETER_1</method-param><!-- ... --><method-param>PARAMETER_N</method-param></method-params></method>
O método deve ser definido na página principal do bean enterprise ou interface remota. Os valores do elemento method-param são o nome inteiramente qualificado do tipo de parâmetro do método correspondente. Caso hajam múltiplos métodos com a mesma assinatura sobrecarregada, a permissão é aplicada a todos os métodos sobrecarregados coincidentes.
O elemento method-intf opcional pode ser usado para diferenciar métodos com o mesmo nome e assinatura que são definidos em ambas interfaces remota e da página principal de um bean enterprise.
O Exemplo 2.5, “Um fragmento do descritor ejb-jar.xml que ilustra o uso do elemento method-permission.” fornece amostras completas do uso do elemento method-permission.

Exemplo 2.5. Um fragmento do descritor ejb-jar.xml que ilustra o uso do elemento method-permission.

<ejb-jar><assembly-descriptor><method-permission><description>The employee and temp-employee roles may access any
                method of the EmployeeService bean </description><role-name>employee</role-name><role-name>temp-employee</role-name><method><ejb-name>EmployeeService</ejb-name><method-name>*</method-name></method></method-permission><method-permission><description>The employee role may access the findByPrimaryKey,
                getEmployeeInfo, and the updateEmployeeInfo(String) method of
                the AardvarkPayroll bean </description><role-name>employee</role-name><method><ejb-name>AardvarkPayroll</ejb-name><method-name>findByPrimaryKey</method-name></method><method><ejb-name>AardvarkPayroll</ejb-name><method-name>getEmployeeInfo</method-name></method><method><ejb-name>AardvarkPayroll</ejb-name><method-name>updateEmployeeInfo</method-name><method-params><method-param>java.lang.String</method-param></method-params></method></method-permission><method-permission><description>The admin role may access any method of the
                EmployeeServiceAdmin bean </description><role-name>admin</role-name><method><ejb-name>EmployeeServiceAdmin</ejb-name><method-name>*</method-name></method></method-permission><method-permission><description>Any authenticated user may access any method of the
                EmployeeServiceHelp bean</description><unchecked/><method><ejb-name>EmployeeServiceHelp</ejb-name><method-name>*</method-name></method></method-permission><exclude-list><description>No fireTheCTO methods of the EmployeeFiring bean may be
                used in this deployment</description><method><ejb-name>EmployeeFiring</ejb-name><method-name>fireTheCTO</method-name></method></exclude-list></assembly-descriptor></ejb-jar>
Reportar um erro

2.1.6. Anotações de Segurança de Beans Enterprise

Os beans enterprise usam Anotações para passar informação ao implantador sobre a segurança e outros aspectos do aplicativo. O implantador pode configurar a política de segurança do bean enterprise para o aplicativo caso especificado nas anotações ou no descritor de implantação.
Quaisquer valores de métodos explicitamente especificados no descritor da implantação substitui os valores da anotação. Caso o valor do método não for especificado no descritor da implantação, aqueles valores determinados usando anotações serão usados. A granularidade é baseada por método.
Essas anotações que endereçam segurança e podem ser usadas nos beans enterprise incluem o seguinte:
@DeclareRoles
Declara cada função de segurança declarada no código. Por favor consulte Java EE 5 Tutorial Declaring Security Roles Using Annotations para maiores informações sobre as funções de configuração.
@RolesAllowed, @PermitAll e @DenyAll
Especifica permissões de método para anotações. Refira-se ao Java EE 5 TutorialSpecifying Method Permissions Using Annotations para maiores informações sobre a configuração das permissões do método de anotação.
@RunAs
Configura a identidade de segurança propagada de um componente. Por favor consulte Java EE 5 TutorialConfiguring a Component’s Propagated Security Identity para maiores informações sobre a configuração das identidades de segurança propagadas usando anotações.
Reportar um erro

2.1.7. Restrições de Segurança do Conteúdo da Web

Num aplicativo da web, a segurança é definida pelas funções que possuem permissão de acesso ao conteúdo por um URL default que identifica o conteúdo protegido. Este conjunto de informações é declarado pelo uso do elemento web.xmlsecurity-constraint.
Ilustração das Restrições de Segurança do Conteúdo da Web

Figura 2.5. Restrições de Segurança do Conteúdo da Web

O conteúdo a ser protegido é declarado usando um ou mais elementos <web-resource-collection>. Cada elemento <web-resource-collection> contém séries opcionais de elementos <url-pattern> seguidos por uma série opcional de elementos <http-method>. O valor do elemento <url-pattern> especifica um URL default referente a solicitação de combinação de URL para que a solicitação corresponda a uma tentativa de acesso ao conteúdo protegido. O valor do elemento <http-method> especifica o tipo de solicitação HTTP a ser permitido.
O elemento <user-data-constraint> opcional especifica as solicitações para a camada de transporte do cliente à conexão do servidor. A solicitação pode ser para a integridade do conteúdo (prevenindo dados interferindo no processo de comunicação) ou para confidencialidade (prevenindo a leitura enquanto em trânsito). O valor do elemento <transport-guarantee> especifica o grau pelo qual a comunicação entre o cliente e o servidor devem ser protegida. Os seus valores são NONE, INTEGRAL e CONFIDENTIAL. Um valor NONE significa que o aplicativo não requer qualquer garantia de transporte. Um valor INTEGRAL significa que o aplicativo requer que os dados sejam enviados entre o cliente e o servidor. O valor CONFIDENTIAL significa que o aplicativo requer que os dados sejam transmitidos numa maneira que previne outras entidades de observarem os conteúdos da transmissão. Na maioria das vezes, a presença do aviso INTEGRAL ou CONFIDENTIAL indica que o uso do SSL é solicitado.
O elemento <login-config> opcional é usado para configurar o método de autenticação que deve ser usado, o nome realm que deve ser usado para o aplicativo e os atributos que são necessários pelo mecanismo de login de formulário.
Ilustração da Configuração de Login da Web

Figura 2.6. Configuração de Login da Web

O elemento filho <auth-method> especifica o mecanismo de autenticação para o aplicativo da web. O usuário deve autenticar usando o mecanismo configurado, como pré-requisito para ganhar acesso a quaisquer recursos da web que são protegidos por uma restrição de autorização. Os valores <auth-method> legais são BASIC, DIGEST, FORM, e CLIENT-CERT. O elemento filho <realm-name> especifica o nome realm a ser usado no HTTP básico e autorização de resumo. O elemento filho <form-login-config> especifica o login assim como as páginas de erro que devem ser usadas no login baseado em formulário. Caso o valor <auth-method> não for FORM, então o form-login-config e seus elementos filhos serão ignorados.
A seguinte amostra de configuração indica que qualquer URL no caminho /restricted do aplicativo da web requer uma função AuthorizedUser. Não há garantia de transporte requerido e o método de autenticação usado para obtenção da identidade do usuário é a autenticação HTTP BÁSICO.

Exemplo 2.6. Fragmento Descritor web.xml

<web-app>
    <security-constraint>
        <web-resource-collection>
            <web-resource-name>Secure Content</web-resource-name>
            <url-pattern>/restricted/*</url-pattern>
        </web-resource-collection>
        <auth-constraint>
            <role-name>AuthorizedUser</role-name>
        </auth-constraint>
        <user-data-constraint>
            <transport-guarantee>NONE</transport-guarantee>
        </user-data-constraint>
    </security-constraint>
    <!-- ... -->
    <login-config>
        <auth-method>BASIC</auth-method>
        <realm-name>The Restricted Zone</realm-name>
    </login-config>
    <!-- ... -->
    <security-role>
        <description>The role required to access restricted content </description>
        <role-name>AuthorizedUser</role-name>
    </security-role>
</web-app>
Reportar um erro

2.1.8. Habilitação da Autenticação baseada no Formulário

A autenticação baseada no formulário fornece flexibilidade na definição de uma página JSP/HTML personalizada para login e uma página separada pela qual usuários são direcionados caso um erro ocorrer durante o login.
A autenticação baseada no formulário é definida pela inclusão do <auth-method>FORM</auth-method> no elemento <login-config> do descritor de implantação, web.xml. As páginas de login e erro estão definidas no <login-config>, conforme abaixo: 
<login-config>
  <auth-method>FORM</auth-method>
  <form-login-config>
    <form-login-page>/login.html</form-login-page>
    <form-error-page>/error.html</form-error-page>
  </form-login-config>
</login-config>
Quando um aplicativo da web com a autenticação baseada no formulário é implantado, o contêiner da web usa o FormAuthenticator para direcionar os usuários à página apropriada. O JBoss EAP mantém um pool de sessão do qual a informação de autenticação não precisa estar presente para cada solicitação. Quando o FormAuthenticator recebe uma solicitação, isto solicita ao org.apache.catalina.session.Manager por uma sessão existente. Caso a sessão não existir, uma nova sessão é criada. O FormAuthenticator verifica então os credenciais da sessão.

Nota

Cada sessão é identificada pela ID de sessão, uma sequência de 16 bites gerada de valores diferenciados. Esses valores são recuperados a partir do /dev/urandom (Linux) por default e aplicados hash com o MD5. As checagens são executadas na criação da ID da sessão para certificar-se de que a ID criada é única.
Uma vez verificada, a ID de sessão é determinada como parte de uma cookie e, então retornada ao cliente. Esta cookie é esperada nas solicitações de cliente subsequentes e é usada para identificar a sessão do usuário.
A cookie é passada ao cliente é o par de valor do nome com diversos atributos opcionais. O atributo identificador é chamado JSESSIONID. O seu valor é uma sexagésima sequência da ID de sessão. Esta cookie é configurada a ser não persistente. Isto significa que no lado do cliente, ela continua a ser excluída quando o navegador existir. No lado do servidor, as sessões expiram após 60 segundos de inatividade, pelas quais os objetos de sessão e a informação de credencial das mesmas são excluídas.
Vamos dizer que um usuário tenta acessar um aplicativo da web que está protegido com a autenticação baseada no formulário. O FormAuthenticator efetua o cache na solicitação, cria uma nova sessão se necessário e redireciona o usuário à página de login definida no login-config. (Nos códigos de amostra anteriores, a página de login é login.html.) O usuário então insere seu nome de usuário e senha no formulário HTML fornecido. O nome de usuário e senha são passados ao FormAuthenticator através da ação do formulário j_security_check.
O FormAuthenticator então autentica o nome de usuário e senha em relação ao realm anexado ao contexto do aplicativo da web. No JBoss Enterprise Application Platform, o realm é JBossWebRealm. Quando a autenticação é bem sucedida, o FormAuthenticator recupera a solicitação salva do cache e redireciona o usuário a sua solicitação original.

Nota

O servidor reconhece as solicitações de autenticação do formulário apenas quando o URI finaliza com /j_security_check e pelo menos os parâmetros j_username e j_password existirem.
Reportar um erro

2.1.9. Habilitação da Segurança Declarativa

Os elementos de segurança do Java EE que foram cobertos até agora, descrevem as solicitações de segurança apenas da perspectiva do aplicativo. O implantador do aplicativo mapeia as funções a partir do domain no ambiente de implantação, uma vez que os elementos de segurança do Java EE declaram funções lógicas. As especificações do Java EE omitem esse aplicativo dos detalhes específicos do servidor.
Com o objetivo de mapear as funções do aplicativo no ambiente implantado, você deve especificar um gerenciador de segurança que implementa o modelo de segurança Java EE usando os descritores de implantação específicos do JBoss EAP. Refira-se à amostra do modelo de login personalizado para maiores detalhes sobre a configuração de segurança.
Reportar um erro

Capítulo 3. Introdução ao JAAS

3.1. JAAS

O framework do JBossSX é baseado no JAAS API. Você deve entender os elementos básicos do JAAS API antes de você poder entender os detalhes de implantação do JBossSX. As seguintes seções fornecem uma introdução ao JAAS para prepará-lo à discussão de arquitetura mais adiante neste guia.
O JAAS 1.0 API consiste de um conjunto de pacotes Java designados à autenticação e autorização do usuário. O API implementa uma versão do Java do framework dos Pluggable Authentication Modules (PAM - Módulos de Autenticação Plugáveis) e estende a arquitetura de controle de acesso ao java 2 Plataform para suportar a autorização baseada no usuário.
O JAAS foi lançado primeiramente como um pacote de extensão para o JDK 1.3 e é empacotado com o JDK 1.5. Uma vez que o framework JBossSX usa apenas as capacidades do JAAS para implantar o modelo de segurança J2EE baseado na função, esta introdução foca apenas neste tópico.
A autenticação é executada de maneira plugável. Isto permite que os aplicativos Java permaneçam independentes das tecnologias de autenticação subjacente e permite que o gerenciador de segurança JBossSX funcione em infraestruturas de segurança diferentes. A integração com a infraestrutura de segurança é alcançável sem a alteração da implantação do gerenciador de segurança do JBossSX. Você precisa apenas alterar a configuração dos usos JAAS da pilha de autenticação.
Reportar um erro

3.2. Classes JAAS Core

As classes JAAS core podem ser divididas em três categorias: comum, autenticação e autorização. A seguinte lista apresenta apenas as classes comum e de autenticação uma vez que elas são classes usadas para implantar a funcionalidade do JBossSX descritas neste capítulo.
Essas são as classes comuns:
  • Subject (javax.security.auth.Subject)
Essas são as classes de autenticação:
  • Configuration (javax.security.auth.login.Configuration)
  • LoginContext (javax.security.auth.login.LoginContext)
Essas são as interfaces associadas:
  • Principal (java.security.Principal)
  • Callback (javax.security.auth.callback.Callback)
  • CallbackHandler (javax.security.auth.callback.CallbackHandler)
  • LoginModule (javax.security.auth.spi.LoginModule)
Reportar um erro

3.3. Classes Assunto e Principal

Com o objetivo de autorizar o acesso aos recursos, os aplicativos devem autenticar primeiramente a fonte da solicitação. O framework JAAS define o assunto do termo para representar uma fonte da solicitação. A classe Subject é a classe central no JAAS. O Subject representa uma informação a uma entidade única, tal como uma pessoa ou serviço. Ele abrange os principais da entidade, os credenciais públicos e os credenciais privados. O JAAS APIs usa a interface do Java 2 java.security.Principal existente para representar um principal, que é essencialmente um nome digitado.
Durante o processo de autenticação, um assunto é povoado com as identidades associadas ou principais. O assunto pode possuir diversos principais. Por exemplo, uma pessoa possui o nome principal (John Doe), um número de segurança principal (123-45-6789) e um nome de usuário principal (johnd), todos eles ajudam a distinguir o assunto a partir de outros assuntos. Existem dois métodos disponíveis para recuperar os principais associados com um assunto: 
public Set getPrincipals() {...}
public Set getPrincipals(Class c) {...}
O getPrincipals() retorna todos os principais contidos no assunto. O getPrincipals(Class c) retorna apenas aqueles principais que são instâncias da classe c ou uma de suas subclasses. Um conjunto vazio é retornado caso o assunto não possua principais coincidentes.
Perceba que a interface java.security.acl.Group é uma subinterface do java.security.Principal, de forma que uma instância no conjunto de principais pode representar um agrupamento lógico de outros principais ou grupos de principais.
Reportar um erro

3.4. Autenticação do Assunto

A Autenticação do Assunto requer um login JAAS. O processo de login consiste dos seguintes critérios:
  1. Um aplicativo inicia um LoginContext e passa o nome da configuração do login e um CallbackHandler para popular os assuntos Callback, conforme requerido pela configuração LoginModules.
  2. O LoginContext consulta o Configuration para carregar todos os LoginModules incluídos na configuração de login nomeada. Caso tal nome não existir, a configuração other é usada como default.
  3. O aplicativo invoca o método LoginContext.login.
  4. O método de login invoca todos os LoginModules carregados. Uma vez que cada LoginModule tenta autenticar o assunto, ele invoca o método de manuseio no CallbackHandler associado para obter a informação requerida pelo processo de autenticação. A informação requerida é passada ao método de manuseio na forma de um array dos assuntos Callback. No caso de êxito, os LoginModules associam os principais e credenciais relevantes ao assunto.
  5. O LoginContext retorna o status de autenticação ao aplicativo. O sucesso é representado por um retorno de um método de login. A falha é representada através de um LoginException sendo lançado pelo método de login.
  6. Caso a autenticação suceder, o aplicativo recupera o assunto autenticado usando o método LoginContext.getSubject.
  7. Após o escopo da autenticação do assunto ser concluído, todos os principais e informações relacionadas associadas ao assunto pelo método login podem ser removidas pela invocação do método LoginContext.logout.
A classe LoginContext fornece os métodos básicos para autenticação dos assuntos e oferece uma maneira de desenvolver um aplicativo que é independente da tecnologia de autenticação subjacente. O LoginContext consulta um Configuration para determinar os serviços de autenticação configurados a um aplicativo em particular. As classes LoginModule representam os serviços de autenticação. Portanto, você pode plugar diferentes módulos de login num aplicativo sem a alteração do próprio aplicativo. Os seguintes códigos apresentam as etapas requeridas por um aplicativo para autenticar um assunto. 
CallbackHandler handler = new MyHandler();
LoginContext lc = new LoginContext("some-config", handler);

try {
    lc.login();
    Subject subject = lc.getSubject();
} catch(LoginException e) {
    System.out.println("authentication failed");
    e.printStackTrace();
}
                        
// Perform work as authenticated Subject
// ...

// Scope of work complete, logout to remove authentication info
try {
    lc.logout();
} catch(LoginException e) {
    System.out.println("logout failed");
    e.printStackTrace();
}
                        
// A sample MyHandler class
class MyHandler 
    implements CallbackHandler
{
    public void handle(Callback[] callbacks) throws
        IOException, UnsupportedCallbackException
    {
        for (int i = 0; i < callbacks.length; i++) {
            if (callbacks[i] instanceof NameCallback) {
                NameCallback nc = (NameCallback)callbacks[i];
                nc.setName(username);
            } else if (callbacks[i] instanceof PasswordCallback) {
                PasswordCallback pc = (PasswordCallback)callbacks[i];
                pc.setPassword(password);
            } else {
                throw new UnsupportedCallbackException(callbacks[i],
                                                       "Unrecognized Callback");
            }
        }
    }
}
Os desenvolvedores integram uma tecnologia de autenticação pela criação de uma implementação da interface LoginModule. Isto permite o administrador a plugar diferentes tecnologias de autenticação num aplicativo. Você pode encadear diversos LoginModules para permitir que mais de uma tecnologia de autenticação participe no processo de autenticação. Por exemplo, um LoginModule pode executar uma autenticação baseada no nome/senha do usuário, enquanto que outro pode realizar a interface aos dispositivos de hardware tais como leituras de cartões smart ou autenticadores biométricos.
O ciclo de vida de um LoginModule é dirigido pelo objeto LoginContext em relação ao cliente que cria e emite o método de login. O processo consiste de duas fases. As etapas do processo são:
  • O LoginContext cria cada configuração LoginModule usando seu construtor sem argumento público.
  • Cada LoginModule é inicializado com uma chamada ao seu método inicializar. O Subject argumento é garantido como não nulo. A assinatura do método inicializar é: public void initialize(Subject subject, CallbackHandler callbackHandler, Map sharedState, Map options)
  • O método login é chamado para iniciar o processo de autenticação. Por exemplo, a implementação do método pode perguntar ao usuário pelo nome e senha do usuário e então verificar a informação em relação aos dados stored num serviço de nomeação tal como o NIS ou LDAP. As implementações alternativas podem realizar a interface para cartões smart e dispositivo biométricos, ou simplesmente extrair a informação do usuário a partir de um sistema de operação subjacente. A validação da identidade do usuário por cada LoginModule é considerada fase 1 da autenticação JAAS. A assinatura do método login é boolean login() throws LoginException . Um LoginException indica falha. Um valor de retorno verdadeiro indica que o método foi bem sucedido, onde um valor de retorno de falso indica que o módulo de login deve ser ignorado.
  • Caso a autenticação no geral LoginContext suceder, o commit é invocado em cada LoginModule. Caso a fase 1 suceder para o LoginModule, o método de confirmação continua com a fase 2 e associa os principais relevantes, credenciais públicos e/ou credenciais privados com o assunto. Caso a fase 1 falhar para um LoginModule, então o commit remove qualquer estado de autenticação stored anteriormente, tais como nomes e senhas de usuários. A assinatura do método commit é: boolean commit() throws LoginException . A falha em concluir a fase de confirmação é indicada pelo lançamento do LoginException. Um retorno verdadeiro indica que o método sucedeu, onde um retorno falso indica que o módulo de login deve ser ignorado.
  • Caso a autenticação no geral LoginContext, então o método abort é invocado em cada LoginModule. O método abort remove ou destroi qualquer estado de autenticação criado pelos métodos inicializar ou login. A assinatura do método abort é boolean abort() throws LoginException . A falha em completar a fase abort é indicada pelo lançamento de um LoginException. Um retorno verdadeiro indica que o método sucedeu, onde um retorno falso indica que o módulo de login deve ser ignorado.
  • Com o objetivo de remover o estado de autenticação após êxito de login, o aplicativo invoca logout no LoginContext. Isto em troca resulta numa invocação do método logout em cada LoginModule. O método logout remove os principais e credenciais originalmente associados com o assunto durante a operação commit. Os credenciais devem ser destruídos sob remoção. A assinatura do método logout é: boolean logout() throws LoginException . A falha em concluir o processo de saída é indicado pelo lançamento um LoginException. Um retorno verdadeiro indica que o método sucedeu, onde um retorno de falso indica que o módulo de login deve ser ignorado.
Quando um LoginModule precisa comunicar-se com o usuário para obter a informação de autenticação, ele usa um objeto CallbackHandler. Os aplicativos implementam a interface CallbackHandler e passam isto ao LoginContext, que envia a informação de autenticação diretamente aos módulos de login subjacente.
Os módulos de login usam o CallbackHandler para tanto obter a entrada de usuários, tais como uma senha ou PIN do cartão smart e para suprir informação aos usuários, tais como informação de status. Permitir que o aplicativo especifique o CallbackHandler, os LoginModules subjacentes continuam independentes de maneiras diferentes dos aplicativos interagirem com os usuários. Por exemplo: uma implementação CallbackHandler para um aplicativo GUI pode exibir uma janela para solicitar a entrada do usuário. Por outro lado, uma implementação CallbackHandler para um ambiente não GUI, tal como um servidor do aplicativo, pode simplesmente obter a informação do credencial pelo uso de um API do servidor do aplicativo. A interface CallbackHandler possui um método de implementação: 
void handle(Callback[] callbacks)
    throws java.io.IOException, 
           UnsupportedCallbackException;
A interface Callback é a última classe de autenticação que vamos ver. Ela é uma interface tagging da qual diversas implementações default são fornecidas, incluindo o NameCallback e PasswordCallback usados num exemplo anterior. O LoginModule usa um Callback para solicitar informação requerida pelo mecanismo de autenticação. O LoginModules passa um array de Callbacks diretamente ao método CallbackHandler.handle durante a fase de login de autenticação. Caso um callbackhandler não entender como usar o objeto Callback passado ao método de manuseio, ele lança um UnsupportedCallbackException para anular a chamada de login.
Reportar um erro

Parte II. Segurança da Plataforma

Capítulo 4. O Subsistema de Segurança

4.1. Subsistema de Segurança

O subsistema de segurança fornece a infraestrutura a todas funcionalidades de segurança no JBoss EAP 6. A maioria dos elementos de configuração raramente precisam ser alterados. O único elemento de configuração que pode ser alterado é se utilizarmos o deep-copy-subject-mode. Além disso, você pode configurar as propriedades de segurança sobre o sistema. A maioria da configuração é relacionada ao security domains.
Modo de Cópia Profunda

Caso o modo assunto de cópia profunda for desabilitado (por default), a cópia de uma estrutura de segurança faz uma referência à original, ao invés de copiar toda a estrutura de dados. Este comportamento é mais eficiente, porém é sujeito à corrupção de dados caso múltiplos threads com a mesma identidade limparem o assunto por um esvaziamento ou uma operação de saída.

O modo assunto de cópia profunda leva a uma cópia completa da estrutura de dados e todos os seus dados associados a serem efetuados, contanto que eles sejam marcados como clonados. Isto é mais um thread-safe, porém é mais eficiente.
Propriedades de Segurança do Sistema

Você pode determinar as propriedades de segurança do sistema, que é aplicado à classe java.security.Security.

Security Domain

O security domain é um conjunto de configurações de segurança declarativa Java Authentication and Authorization Service (JAAS) que um ou mais aplicativos usam para controlar a autenticação, autorização, auditoria e mapeamento. Os security domains estão incluídos por default: jboss-ejb-policy, jboss-web-policy e other. Você pode criar quantos security domains você venha precisar para acomodar as necessidades de seus aplicativos.

Reportar um erro

4.2. Estrutura do Subsistema de Segurança

O subsistema de segurança é configurado no managed domain ou arquivo de configuração autônomo. A maioria dos elementos de configuração podem ser configurados usando o console de gerenciamento baseado na web ou CLI de gerenciamento baseado no console. Segue abaixo uma representação XML de uma amostra do subsistema de segurança.

Exemplo 4.1. Amostra do Subsistema de Segurança

<subsystem xmlns="urn:jboss:domain:security:1.2">
	<security-management>
		...
	</security-management>
	<security-domains>
        <security-domain name="other" cache-type="default">
            <authentication>
                <login-module code="Remoting" flag="optional">
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
                <login-module code="RealmUsersRoles" flag="required">
                    <module-option name="usersProperties" value="${jboss.domain.config.dir}/application-users.properties"/>
                    <module-option name="rolesProperties" value="${jboss.domain.config.dir}/application-roles.properties"/>
                    <module-option name="realm" value="ApplicationRealm"/>
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
            </authentication>
        </security-domain>
        <security-domain name="jboss-web-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
        <security-domain name="jboss-ejb-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
    </security-domains>
    <vault>
    	...
    </vault>
</subsystem>
Os elementos <security-management>, <subject-factory> e <security-properties> não estão presentes na configuração default. Os elementos <subject-factory> e <security-properties> foram substituídos a partir do JBoss EAP 6.
Reportar um erro

4.3. Configuração do Subsistema de Segurança

4.3.1. Configuração do Subsistema de Segurança

Você pode configurar o subsistema de segurança usando o CLI de Gerenciamento ou Console de Gerenciamento baseado na web.
Cada elemento de nível superior com o subsistema de segurança contém informação sobre um aspecto diferente de configuração de segurança. Refira-se à Seção 4.2, “Estrutura do Subsistema de Segurança” para uma amostra da configuração do subsistema de segurança.
<security-management>
Esta seção descreve os comportamentos de alto nível do subsistema de segurança. Cada configuração é opcional. Não é comum alterar qualquer uma dessas configurações, a não ser para o modo assunto de cópia profunda.
Opções Descrição
deep-copy-subject-mode
Especifica se é que copiar ou conectar os tokens de segurança para uma segurança adicional do thread.
authentication-manager-class-name
Especifica uma classe de implementação do AuthenticationManager a ser usada.
authorization-manager-class-name
Especifica o nome da classe da implementação AuthorizationManager alternativa.
audit-manager-class-name
Especifica o nome da classe da implementação AuditManager alternativa.
identity-trust-manager-class-name
Especifica o nome da classe da implementação IdentityTrustManager a ser usado.
mapping-manager-class-name
Especifica o nome da classe da implementação MappingManager para uso.
<subject-factory>
A criação do assunto controla a criação das instâncias do assunto. Isto pode usar o gerenciador da autenticação para verificar o chamador. O uso principal da fábrica do assunto é para os componentes JCA estabelecerem um assunto. Não é necessário modificar a fábrica do assunto.
<security-domains>
O elemento do contêiner que mantém os security domains múltiplos. O security domain pode conter informação sobre o módulo autenticação, autorização e auditoria assim como a autenticação JASPI e a configuração JSSE. O seu aplicativo especificaria um security domain para gerenciar sua informação de segurança.
<security-properties>
Contém os nomes e valores das propriedades que são configuradas na classe java.security.Security.
Reportar um erro

4.3.2. Gerenciamento de Segurança

4.3.2.1. Modo Assunto de Cópia Profunda

Caso o modo de sujeito de cópia profunda for desabilitado (por default), a cópia de uma estrutura de dados de segurança faz uma referência à original, ao invés de copiar toda a estrutura de dados. Este comportamento é mais eficiente, porém é sujeito à corrupção de dados caso múltiplos threads com a mesma identidade limpem o sujeito por um esvaziamento ou uma operação de saída.
O modo de sujeito de cópia profunda leva a uma cópia completa da estrutura de dados e todos os seus dados associados a serem efetuados, contanto que eles sejam marcados como clonados. Isto é mais um thread-safe, porém é mais eficiente.
O modo assunto de cópia profunda é configurado como parte do subsistema de segurança.
Reportar um erro

4.3.2.2. Habilitação do Modo Assunto de Cópia Profunda

Você pode habilitar o modo de segurança de cópia profunda a partir do console de gerenciamento baseado na web ou CLI de gerenciamento.

Procedimento 4.1. Habilitação do Modo de Segurança do Modo de Segurança de Cópia profunda a partir do Console de Gerenciamento

  1. Efetue o log ao Console de Gerenciamento.

    O console de gerenciamento normalmente está disponível no URL tal como o http://127.0.0.1:9990/. Ajuste este valor para suprir suas necessidades.

  2. Managed Domain: Selecione o perfil apropriado.

    Num managed domain, o subsistema de segurança é configurado por perfil e você pode habilitar ou desabilitar o modo de segurança de cópia profunda em cada, independentemente.
    Com o objetivo de selecionar um perfil, clique no rótulo Profiles no canto direito superior da exibição do console, e selecione o perfil que você deseja selecionar a partir da caixa de seleção Profile no canto esquerdo superior.

  3. Abra o menu de configuração Security Subsystem.

    Expanda o item do menu Security na parte direita do console de gerenciamento e clique no link Security Subsystem.

  4. Modifique o valor deep-copy-subject-mode.

    Clique no botão Edit. Verifique a caixa ao lado Deep Copy Subjects: para habilitar o modo assunto de cópia profunda.
Habilite o Modo Assunto de Cópia Profunda usando o CLI de Gerenciamento

Caso você prefira usar o CLI de Gerenciamento para habilitar esta opção, use um dos seguintes comandos.

Exemplo 4.2. Managed Domain

/profile=full/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)

Exemplo 4.3. Servidor Autônomo

/subsystem=security:write-attribute(name=deep-copy-subject-mode,value=TRUE)
Reportar um erro

4.3.3. Security Domains

4.3.3.1. Security Domains

Os security domains fazem parte do subsistema de segurança do JBoss EAP 6. Toda a configuração de segurança é agora gerenciada centralmente, pelo domain controller de um managed domain ou pelo servidor autônomo.
O security domain consiste de configurações para autenticação, autorização, mapeamento de segurança e auditoria. Ele implementa a segurança declarativa Java Authentication and Authorization Service (JAAS).
A autenticação refere-se à verificação de identidade de um usuário. Na terminologia de segurança, este usuário é referido como principal. Embora a autenticação e autorização sejam diferentes, muitos dos módulos de autenticação incluídos também manuseiam a autorização.
Um authorization é uma política de segurança pela qual o servidor determina se é que o usuário autenticado possui permissão aos privilégios específicos de acesso ou recursos no sistema ou operação. Na terminologia de segurança, isto é normalmente referido como uma função.
O Security mapping refere-se à habilidade de adicionar, modificar ou excluir a informação a partir do principal, função ou atributo antes de passar a informação ao seu aplicativo.
O gerenciador de auditoria permite você configurar o provider modules para controlar a maneira que os eventos de segurança são relatados.
Caso você use security domains, você pode remover toda a configuração de segurança específica. Isto permite você alterar os parâmetros de segurança centralmente. Um cenário comum que beneficia-se deste tipo de estrutura de configuração é o processo de movimento dos aplicativos entre os ambientes de teste e produção.
Reportar um erro

4.3.3.2. Picketbox

O Picketbox é um framework de segurança de fundação que fornece capacidades de autenticação, autorização, auditoria e mapeamento para os aplicativos Java sendo executados no JBoss EAP 6. Isto fornece as seguintes capacidades num framework único com uma configuração única.
Reportar um erro

Capítulo 6. Java Security Manager

6.1. Java Security Manager

Java Security Manager
O Java Security Manager é uma classe que gerencia a fronteira externa da área restrita do Java Virtual Machine (JVM), controlando como o código em execução pode interagir com os recursos fora do JVM. Quando o Java Security Manager é ativado, o Java API checa por aprovação do Java Security Manager antes de executar uma vasta variedade de operações potencialmente sem segurança.
O Java Security Manager usa uma política de segurança para determinar se é que uma ação gerada será permitida ou recusada.
Reportar um erro

6.2. Políticas do Java Security Manager

Security Policy
O conjunto de permissões definidas para diferentes classes do código. O Java Security Manager compara ações solicitadas pelos aplicativos em relação à política de segurança. Caso uma ação seja permitida pela política, o Security Manager permitirá que ação entre em vigor. Caso a ação não seja permitida pela política, o Security Manager recusará aquela ação. A política de segurança pode definir as permissões baseadas na localização do código ou na assinatura de segurança.
O Java Security Manager e a política de segurança usados são configurados usando as opções java.security.manager e java.security.policy do Java Virtual Machine.
Reportar um erro

6.3. Execução do JBoss EAP com o Java Security Manager

Com o objetivo de especificar o Java Security Manager, você precisa editar as opções Java passadas à instância do servidor ou domain durante o processo bootstrap. Por este motivo, você não pode passar os parâmetros como opções aos scripts domain.sh ou standalone.sh. O seguinte procedimento irá guiá-lo através destas etapas de configuração da sua instância para execução com uma política do Java Security Manager.

Pré-requisitos

  • Antes de você seguir este procedimento, você precisa gravar uma política de segurança, usando o comando policytool que está incluído no seu Java Development Kit (JDK). Este procedimento assume que a sua política está localizada no EAP_HOME/bin/server.policy.
  • O servidor domain e autônomo deve ser completamente interrompido antes de você editar quaisquer arquivos de configuração.
Execute o seguinte procedimento para cada host físico ou instância em seu domain, caso você tenha associados domain por todos os sistemas múltiplos.

Procedimento 6.1. Edição dos Arquivos de Configuração

  1. Abra o arquivo de configuração

    Abra o arquivo de configuração para edição. Este arquivo está localizado em dois locais, dependendo de você estar usando um managed domain ou servidor autônomo. Este não é um arquivo executável usado para usar o servidor ou domain.

    • Managed Domain

      EAP_HOME/bin/domain.conf

    • Servidor Autônomo

      EAP_HOME/bin/standalone.conf

  2. Adição das opções Java no final de cada arquivo.

    Adicione a seguinte linha no final do arquivo. Você pode modificar o valor -Djava.security.policy para especificar a localização exata de sua política de segurança. Isto deve ocorrer em uma linha, sem quebra de linha. Você pode modificar o -Djava.security.debug para efetuar o log de mais ou menos informações pela especificação do nível de depuração. O mais verboso é failure,access,policy. 
    JAVA_OPTS="$JAVA_OPTS -Djava.security.manager -Djboss.home.dir=$PWD/.. -Djava.security.policy==$PWD/server.policy -Djava.security.debug=failure"

  3. Início do domain ou servidor.

    Inicie o domain ou servidor como o normal.
Reportar um erro

6.4. Gravação da Política do Java Security Manager

Introdução

Um aplicativo chamado policytool está incluído na maioria das distribuições JRE e JDK, para o propósito de criação e edição das políticas de segurança do Java Security Manager. A informação detalhada sobre policytool é conectado a partir do http://docs.oracle.com/javase/6/docs/technotes/tools/.

Informação Básica

A política de segurança consiste dos seguintes elementos de configuração:

CodeBase
A localização do URL (excluindo a informação domain e host) onde o código é originado. O parâmetro é opcional.
SignedBy
O alias usado no keystore para referência do assinante cuja chave privada era usada para inserir o código. Isto pode ser um valor único ou lista de vírgula separada de valores. Este parâmetro é opcional. Caso omitido, a presença ou falta de assinatura não possui impacto no Java Security Manager.
Principals
A lista dos pares principal_type/principal_name, que devem ser apresentados com o conjunto principal de thread sendo executados. A entrada dos Principals é opcional. Caso seja omitida, isto significa "quaisquer principals".
Permissões
A permissão é o acesso que é concedido ao código. Muitas permissões são fornecidas como parte da especificação do Java Enterprise Edition 6 (Java EE 6). Este documento descreve apenas as permissões adicionais que são fornecidas pelo JBoss EAP 6.

Procedimento 6.2. Configuração de uma nova Política do Java Security Manager

  1. Inicie o policytool.

    Inicie a ferramenta policytool em uma das seguintes manerias:

    • Red Hat Enterprise Linux

      A partir de seu GUI ou prompt de comando, execute o /usr/bin/policytool.

    • Servidor Microsoft Windows

      Execute o policytool.exe a partir do menu de Iniciação ou do bin\ de sua instalação do Java. A localização pode variar.

  2. Criação de uma política.

    Selecione Add Policy Entry para criar uma política. Adicione parâmetros que você precisa, e clique em Done.

  3. Edição de uma política existente

    Selecione a política a partir da lista das políticas existentes e selecione o botão Edit Policy Entry. Edite os parâmetros conforme seja necessário.

  4. Exclusão de uma política existente.

    Selecione a política da lista de políticas existentes e selecione o botão Remove Policy Entry.

Permissão Específica ao JBoss EAP 6

org.jboss.security.SecurityAssociation.getPrincipalInfo
Fornece acesso aos métodos org.jboss.security.SecurityAssociation.getPrincipal() e getCredential(). O risco relacionado com o uso desta permissão do período de execução é a habilidade de ver o chamador de thread atual e credenciais.
org.jboss.security.SecurityAssociation.getSubject
Fornece o método org.jboss.security.SecurityAssociation.getSubject().
org.jboss.security.SecurityAssociation.setPrincipalInfo
Fornece acesso aos métodos org.jboss.security.SecurityAssociation.setPrincipal(), setCredential(), setSubject(), pushSubjectContext() e popSubjectContext(): O risco relacionado com o uso desta permissão do período de execução é a habilidade de determinar o chamador do thread atual e credenciais.
org.jboss.security.SecurityAssociation.setServer
Fornece acesso ao método org.jboss.security.SecurityAssociation.setServer. O risco relacionado com o uso desta permissão do período de execução é a habilidade de habilitar ou desabilitar o storage multi-thread do chamador principal e credencial.
org.jboss.security.SecurityAssociation.setRunAsRole
Fornece acesso aos métodos org.jboss.security.SecurityAssociationpushRunAsRole(), popRunAsRole(), pushRunAsIdentity() e popRunAsIdentity(). O risco relacionado com o uso desta permissão do período de execução é a habilidade de alterar o chamador atual para executar como função principal.
org.jboss.security.SecurityAssociation.accessContextInfo
Fornece acesso aos métodos getter e setter org.jboss.security.SecurityAssociation.accessContextInfo() e accessContextInfo(). Isto permite que você determine e configure a informação do contexto de segurança atual.
org.jboss.naming.JndiPermission
Fornece as permissões especiais para arquivos e diretórios num caminho de árvore JNDI especificado ou de forma recursiva a todos os subdiretórios. O JndiPermission consiste de um pathname e um conjunto de permissões válidas relacionadas ao arquivo ou diretório.
As permissões disponíveis incluem:
  • bind
  • rebind
  • unbind
  • pesquisa
  • lista
  • listBindings
  • createSubcontext
  • todos
Os pathnames finalizados em /* indicam que as permissões especificadas são aplicadas a todos os arquivos e diretórios do nome do pathname. Os pathnames finalizados em /- indicam permissões recursivas em todos os arquivos e subdiretórios do pathname. Os pathnames consistentes do <<ALL BINDINGS>> de token especial coincidem com qualquer arquivos do diretório.
org.jboss.security.srp.SRPPermission
A classe de permissão personalizada para proteção de acesso à informação SRP confidencial como sessão privada e chave privada. Essa permissão não possui quaisquer ações definidas. O destino getSessionKey() fornece acesso à chave de sessão privada que resulta da negociação SRP. O acesso à esta chave permite a criptografia e descriptografia de mensagens que foram criptografadas à chave da sessão.
org.hibernate.secure.HibernatePermission
A classe de permissão fornece permissões básicas para segurança das sessões Hibernate. O destino para esta propriedade é o nome de entidade. As ações disponíveis incluem:
  • inserir
  • excluir
  • atualizar
  • ler
  • * (todos)
org.jboss.metadata.spi.stack.MetaDataStackPermission
Fornece uma classe de permissão personalizada para controle de como os chamadores interagem com a pilha metadados. As permissões disponíveis são:
  • modificar
  • enviar (à pilha)
  • pop (fora da pilha)
  • inspecionar (na pilha)
  • * (todos)
org.jboss.config.spi.ConfigurationPermission
Garante a determinação das propriedades de configuração. Define apenas os nomes de destino e nenhuma das ações. Os destinos para esta propriedade incluem:
  • <property name> (a propriedade que este código possui permissão de configurar)
  • * (todas as propriedades)
org.jboss.kernel.KernelPermission
Garante acesso à configuração do kernel. Define apenas os nomes do destino de permissão e sem ações. Os destinos para a propriedade incluem:
  • acesso (à configuração do kernel)
  • configuração (implica no acesso)
  • * (todos)
org.jboss.kernel.plugins.util.KernelLocatorPermission
Garante acesso ao kernel. Define apenas os nomes do destino de permissão e nenhuma ação. Os destinos para a propriedade incluem:
  • kernel
  • * (todos)
Reportar um erro

6.5. Políticas do Gerenciador de Segurança de Depuração

Você pode habilitar a informação de depuração para auxiliá-lo com os problemas relacionados com a política de segurança. A opção java.security.debug configura o nível de informação relatada de segurança. O comando java -Djava.security.debug=help produzirá resultado de ajuda sobre tudo a respeito das opções de depuração. A configuração do nível de depuração para all é útil quando solucionando problemas de uma falha relacionada com a segurança, cuja causa é totalmente desconhecida. No entanto, para uso geral isto produzirá informações demasiadas. O default geral de sensibilidade é access:failure.

Procedimento 6.3. Habilitação de depuração geral

  • Este procedimento irá habilitar o nível geral de sensibilidade da informação de depuração relacionada com segurança.

    Adição da seguinte linha ao arquivo de configuração do servidor.
    • Caso a instância do JBoss EAP 6 estiver sendo executada num managed domain, a linha é adicionada ao arquivo bin/domain.conf para o Linux ou arquivo bin/domain.conf.bat para Windows.
    • Caso a instância do JBoss EAP 6 estiver sendo executada como um servidor autônomo, a linha é adicionada ao arquivo bin/standalone.conf para o Linux ou arquivo bin\standalone.conf.bat para o Windows.
Linux 
JAVA_OPTS="$JAVA_OPTS -Djava.security.debug=access:failure"
Windows 
JAVA_OPTS="%JAVA_OPTS% -Djava.security.debug=access:failure"
Resultado

O nível geral de informação de depuração relacionada com a segurança foi habilitada.

Reportar um erro

Capítulo 7. Realms de Segurança

7.1. Realms de Segurança

O security realm é uma série de mapeamentos entre usuários e senhas, e usuários e funções. Os security realms são um mecanismo para adição de autenticação dos aplicativos EJB e Web. O JBoss EAP 6 fornece dois security realms por default:
  • O ManagementRealm efetua o store da informação de autenticação para o API de Gerenciamento, que fornece a funcionalidade para o CLI de Gerenciamento e Console de Gerenciamento baseado na web. Ele fornece um sistema de autenticação para o próprio JBoss EAP 6. Você pode usar também o ManagementRealm caso o seu aplicativo necessitasse autenticar nas mesmas regras comerciais de uso para o API de Gerenciamento.
  • O ApplicationRealm efetua o store da informação do usuário, senha e dos Aplicativos da Web e EJBs.
Cada realm é aplicado o store em dois arquivos no filesystem:
  • O REALM-users.properties efetua o store dos nomes de usuários e senhas com hash.
  • O REALM-users.properties aplica o store ao mapeamento user-to-role.
Os arquivos de propriedades realizam o store nos diretórios domain/configuration/ e standalone/configuration/. Os arquivos são gravados simultaneamente pelo comando add-user.sh ou add-user.bat. Quando você executar o comando, a primeira decisão que você realiza é qual realm adicionar ao seu novo usuário.
Reportar um erro

7.2. Adição do Novo Realm de Segurança

  1. Execute o CLI de Gerenciamento.

    Inicie o comando jboss-cli.sh ou jboss-cli.bat e conecte-se ao servidor.

  2. Crie um novo realm de segurança.

    Execute o seguinte comando para criar um novo security realm nomeado MyDomainRealm no domain controller ou o servidor autônomo. 
    /host=master/core-service=management/security-realm=MyDomainRealm:add()

  3. Crie as referências ao arquivo de propriedade que irá aplicar o store na informação a respeito da nova função.

    Execute o seguinte comando para criar um direcionador ao arquivo nomeado myfile.properties, que terá as propriedades pertencentes à nova função.

    Nota

    O arquivo de propriedade recentemente criado não é gerenciado pelos scripts add-user.sh e add-user.bat incluídos. Ele deve ser gerenciado externamente. 
    /host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
Resultado

O seu novo realm de segurança é criado. Quando você adicionar usuários e funções a este novo realm, a informação será stored num arquivo separado aos realms de segurança default. Você pode gerenciar este novo arquivo usando os seus próprios aplicativos e procedimentos.

Reportar um erro

7.3. Adição de um usuário ao Realm de Segurança

  1. Execute o comando add-user.sh ou add-user.bat.

    Abra um terminal e altere os diretórios para o diretório EAP_HOME/bin/. Caso você esteja executando o Red Hat Enterprise Linux ou outro sistema operacional UNIX, execute o add-user.sh. Caso você execute o Microsoft Windows Server, execute o add-user.bat.

  2. Escolha entre adicionar o Usuário de Gerenciamento ou o Usuário do Aplicativo.

    Para este procedimento, digite b para adicionar o Usuário do Aplicativo.

  3. Escolha o realm que o usuário será adicionado.

    Por default, o único realm disponível é o ApplicationRealm. Caso você tenha adicionado um realm personalizado, você pode digitar o seu nome.

  4. Digite o nome do usuário, senha e funções quando solicitado.

    Digite o nome do usuário, senha e funções quando solicitado. Verifique sua escolha digitando yes ou digite no para cancelar as alterações. As alterações são gravadas a cada um dos arquivos de propriedade para o realm de segurança.
Reportar um erro

Capítulo 8. Criptografia

8.1. Criptografia

A Encryption (Criptografia) refere-se à informação de confiabilidade de ofuscação pela aplicação de algoritmos matemáticos a isto. A criptografia é uma das fundações de segurança para sua infraestrutura, com referência às violações de dados, interrupção do sistema e outros riscos.
A criptografia pode ser aplicada a dados de sequência simples, tais como senhas. Isto pode ser também aplicado aos streams de comunicação. O protocolo HTTPS, por exemplo, criptografa todos os dados antes transferi-los de uma parte à outra. Caso você conecte-se a partir de um servidor a outro usando o protocolo Secure Shell (SSH), toda a sua comunicação é enviada num tunnel criptografado.
Reportar um erro

8.2. Criptografia SSL

O Secure Sockets Layer (SSL - Camada de Sockets de Segurança) criptografa o tráfego de rede entre dois sistemas. O tráfego entre dois sistemas é criptografado usando uma chave de duas mãos, gerada durante a fase: handshake de conexão e conhecimento apenas por aqueles dois sistemas.
Para a troca de segurança de chave de criptografia de duas maneiras, o SSL faz uso do Public Key Infrastructure (PKI), o método de criptografia que utiliza um par chave . Um par chave consiste de dois separados, porém a combinação de chaves de criptografia - uma chave pública e uma chave privada. A chave pública é compartilhada com outras e é usada para criptografar dados que foram criptografados usando a chave pública.
Quando um cliente solicita uma conexão de segurança, a fase handshake assume posição antes da comunicação de segurança poder ser iniciada. O servidor passa a chave pública ao cliente na forma de certificado durante o handshake SSL. O certificado contém a identidade do servidor (seu URL), a chave pública do servidor e uma assinatura que valida o certificado. O cliente, então valida o certificado e toma uma decisão se é que o certificado é confiável ou não. Caso o certificado seja confiável, o cliente gera a chave de criptografia de duas entradas para a conexão SSL, a criptografa usando a chave pública do servidor e a envia de volta ao servidor. O servidor decripta a chave de criptografia de duas entradas usando sua chave privada e nenhuma comunicação entre as duas máquinas referentes a essa comunicação é criptografada usando a chave de criptografia de duas maneiras.
Reportar um erro

8.3. Implementação da Criptografia SSL para o JBoss EAP 6 Web Server

Introdução

Muitos aplicativos requerem uma conexão criptografada SSL entre o cliente e o servidor, também conhecida como conexão HTTPS. Você pode usar este procedimento para habilitar o HTTPS no seu servidor ou grupo do servidor.

Pré-requisitos

  • Você precisa de um conjunto de chaves criptografadas SSL. Você pode comprá-las a partir do certificado de autoridade de assinatura, ou pode gerá-las usando as utilidades da linha de comando. Para gerar chaves de criptografia usando o Red Hat Enterprise Linux, refira-se à Seção 8.4, “Criação de uma Chave de Criptografia SSL e Certificado”.
  • Você precisa saber os seguintes detalhes sobre o ambiente específico e montagem:
    • O nome e caminho completo de seus arquivos de certificado
    • A senha criptografada para suas chaves de criptografia.
  • Você precisa executar o CLI de Gerenciamento e conectá-lo ao seu controlador de domain ou servidor autônomo.

Nota

Este procedimento usa comandos apropriados para a configuração do JBoss EAP 6 que usa um management domain. Caso você use um servidor autônomo, modifique os comandos CLI de Gerenciamento pela remoção do /profile=default a partir do início de quaisquer comandos CLI de Gerenciamento.

Procedimento 8.1. Configuração do JBoss Web Server para uso dos HTTPS

  1. Adicione um novo conector HTTPS.

    Execute o seguinte comando CLI de Gerenciamento, alterando o perfil conforme apropriado. Isto cria um novo conector de segurança, chamado HTTPS, que usa o esquema https, o binding de socket https (do qual o default é 8443), e é configurado para possuir segurança.

    Exemplo 8.1. Comando CLI de Gerenciamento

    /profile=default/subsystem=web/connector=HTTPS/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)

  2. Configuração do certificado e chaves de criptografia SSL.

    Execute os seguintes comandos para configuração de seu certificado SSL, substituindo os seus próprios valores para aos da amostra. Esta amostra assume que o keystore é copiado ao diretório da configuração do servidor, que é o EAP_HOME/domain/configuration/ para o managed domain.

    Exemplo 8.2. Comando CLI de Gerenciamento

    /profile=default/subsystem=web/connector=HTTPS/ssl=configuration:add(name=https,certificate-key-file="${jboss.server.config.dir}/keystore.jks",password=SECRET, key-alias=KEY_ALIAS)
    Para uma listagem completa de parâmetros que você pode configurar para as propriedades SSL do conector, refira-se à Seção 8.5, “Referência do Conector SSL”.

  3. Implantação de um aplicativo

    A implantação de um aplicativo a um grupo do servidor que usa o perfil que você configurou. Caso você use um servidor autônomo, implante o aplicativo ao seu servidor. As solicitações HTTP solicitam que isto use a nova conexão criptografada SSL.
Reportar um erro

8.4. Criação de uma Chave de Criptografia SSL e Certificado

Você precisará de um certificado de criptografia assinado para uso de um SSL-encrypted HTTP connection (HTTPS - conexão HTTP criptografado SSL) assim como de outros tipos de comunicação SSL criptografada. Você pode comprar um certificado a partir do Certificate Authority (CA - Autoridade de Certificado), ou você pode usar um certificado autoassinado. Os certificados autoassinados não são considerados confiáveis por terceiros, mas são apropriados para propósitos de testes internos.
Este procedimento o habilita a criar o certificado autoassinado usando as utilidades que estão disponíveis no Red Hat Enterprise Linux.

Pré-requisitos

  • Você precisa da utilidade keytool, que é fornecida pela implantação do Java Development Kit. O OpenJDK no Red Hat Enterprise Linux instala este comando ao /usr/bin/keytool.
  • O entendimento da sintaxe e parâmetros do comando keytool. Este procedimento usa as instruções extremamente genéricas, uma vez que a discussão futura das especificações dos certificados ou do comando keytool estão fora do tópico desta documentação.

Procedimento 8.2. Criação de uma Chave de Criptografia SSL e Certificado

  1. Geração de um keystore com as chaves pública e privada.

    Execute o seguinte comando para gerar um keystore nomeado server.keystore com o alias jboss no seu diretório atual. 
    keytool -genkeypair -alias jboss -keyalg RSA -keystore server.keystore -storepass mykeystorepass --dname "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,S=NC,C=US"
    A seguinte tabela descreve os parâmetros usados no comando keytool:
    Parâmetro Descrição
    -genkeypair O comando keytool para gerar um par de chave contendo uma chave pública e privada.
    -alias O alias para o keystore. Este valor é arbitrário, porém o alias jboss é o default usado pelo servidor pelo servidor do JBoss Web.
    -keyalg O algoritmo de geração par da chave. Neste caso ele é o RSA.
    -keystore O nome e a localização do arquivo keystore. A localização default é o diretório atual. O nome que você escolher é arbitrário. Neste caso, o arquivo será nomeado server.keystore.
    -storepass Essa senha é usada para autenticação ao keystore de forma que a chave pode ser lida. A senha deve ter pelo menos 6 caracteres e deve ser fornecida quando o keystore é acessado. Neste caso, nós usamos o mykeystorepass. Caso você omitir este parâmetro, você será solicitado a inserir o mesmo quando você executar o comando.
    -keypass
    Esta é a senha para a chave atual.

    Nota

    Devido à limitação da implementação, ela deve ser a mesma senha à senha do store.
    --dname A sequência cotada descrevendo o nome distinguido para a chave, por exemplo: "CN=jsmith,OU=Engineering,O=mycompany.com,L=Raleigh,C=US". Essa sequência é a concatenação dos seguintes componentes:
    • CN - O nome comum ou nome do host. Caso o hostname seja "jsmith.mycompany.com", o CN será "jsmith".
    • OU - A unidade da organização, por exemplo: "Engineering"
    • O - O nome da organização, por exemplo "mycompany.com".
    • L - A localidade, por exemplo: "Raleigh" ou "London"
    • S - O estado ou província, por exemplo: "NC". Este parâmetro é opcional.
    • C - O código de suas letras do país, por exemplo: "US" ou "UK",
    Quando você executar o comando acima, você será solicitado a seguinte informação:
    • Caso não tenha usado o parâmetro -storepass na linha de comando, você será solicitado a inserir a senha keystore. Reinicie a nova senha na próxima solicitação.
    • Caso não tenha usado o parâmetro -keypass na linha de comando, você será solicitado a inserir a senha chave. Pressione Enter para configurá-la no mesmo valor ao da senha keystore.
    Quando o comando completar, o arquivo server.keystore conterá a chave única com o alias jboss.

  2. Verifique a chave.

    Verifique se a chave funciona de forma apropriada usando o seguinte comando: 
    keytool -list -keystore server.keystore
    Você será solicitado a fornecer a senha keystore. Os conteúdos do keystore são exibidos (neste caso, uma chave única chamada jboss). Perceba o tipo da chave jboss, que é keyEntry. Isto indica que o keystore contém ambas entradas privada e pública para esta chave.

  3. Geração de um certificado assinando uma solicitação.

    Execute o seguinte comando para gerar um certificado assinando solicitação usando a chave pública e privada a partir do keystore que você criou na etapa 1. 
    keytool -certreq -keyalg RSA -alias jboss -keystore server.keystore -file certreq.csr
    Você é solicitado pela a senha com o objetivo de autenticar o keystore. O comando keytool então cria um novo certificado assinando a solicitação chamada certreq.csr no seguinte diretório de trabalho.

  4. Teste a solicitação da assinatura do certificado recentemente gerado.

    Teste os conteúdos do certificado usando o seguinte comando. 
    openssl req -in certreq.csr -noout -text
    Os detalhes do certificado são apresentados.

  5. Opcional: Submeta a solicitação de assinatura de seu certificado a um Certificate Authority (CA - Autoridade de Certificado).

    O Certificate Authority (CA) pode autenticar o seu certificado de forma que isto é considerado de confiança por clientes de terceiros. O CA fornece um certificado assinado e opcionalmente um ou mais certificados intermediários.

  6. Opcional: Exporte um certificado autoassinado a partir do keystore.

    Caso você precisar disto para testes ou propósitos internos, você pode usar um certificado autoassinado. Você pode expor um do keystore que você criou na etapa 1, conforme abaixo: 
    keytool -export -alias jboss -keystore server.keystore -file server.crt
    Você será solicitado a fornecer a senha com o objetivo de autenticar o keystore. O certificado autoassinado, nomeado server.crt, é criado no diretório de trabalho atual.

  7. Importe o certificado assinado, juntamente com quaisquer certificados intermediários.

    Importe cada certificado na ordem que você está instruído pelo CA. Para cada certificado a ser importado, substitua o intermediate.ca ou server.crt pelo nome do arquivo atual. Caso os seus certificados não forem fornecidos como arquivos separados, crie um arquivo separado para cada certificado e cole os seus conteúdos no arquivo.

    Nota

    O seu certificado assinado e chaves do certificado são bens de valor. Tenha cuidado de como transportá-los entre os servidores. 
    keytool -import -keystore server.keystore -alias intermediateCA -file intermediate.ca
    keytool -import -alias jboss -keystore server.keystore -file server.crt

  8. Teste se seus certificados importaram com êxito.

    Execute o seguinte comando e insira a senha keystore quando solicitada. Os conteúdos de seu keystore são exibidos e os certificados fazem parte da lista. 
    keytool -list -keystore server.keystore
Resultado

O seu certificado assinado está agora incluído no seu keystore e está pronto para ser usado para criptografar as conexões SSL, incluindo as comunicações do servidor da web HTTPS.

Reportar um erro

8.5. Referência do Conector SSL

Os conectores podem incluir os seguintes atributos de configuração SSL. Os comandos CLI fornecidos são designados a um managed domain usando o default de perfil. Altere o nome do perfil para um que você deseje configurar, para o managed domain, ou omita a porção /profile=default do comando, para um servidor autônomo.

Tabela 8.1. Atributos do Conector SSL

Função Descrição Comando CLI
nome
O nome de exibição do conector SSL. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=name,value=https)
verify-client
Configure para true para solicitar uma corrente de certificado válido a partir do cliente antes de aceitar uma conexão. Configure para want caso deseje que a pilha SSL solicite um Certificado de cliente, mas não falhe caso não haja certificado algum. Determine para false (o default) para não requerer uma corrente de certificado a não ser que o cliente solicite um recurso protegido por uma restrição de segurança que usa a autenticação CLIENT-CERT. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-client,value=want)
verify-depth
O número máximo de emissores de certificado intermediários verificados antes de decidir que os clientes não possuem um certificado válido. O valor default é 10. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=verify-depth,value=10)
certificate-key-file
O caminho de arquivo completo e o nome do arquivo keystore onde o certificado do servidor assinado é aplicado o store. Com a criptografia JSSE, este arquivo de certificado será apenas um, enquanto o OpenSSL usa diversos arquivos. O valor default é o arquivo .keystore no diretório principal do usuário executando o JBoss EAP 6. Caso o seu keystoreType não usar um arquivo, determine o parâmetro para uma sequência vazia. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-key-file,value=../domain/configuration/server.keystore)
certificate-file
Caso você usar a criptografia OpenSSL, determine o valor deste parâmetro para o caminho do arquivo contendo o certificado do servidor. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-file,value=server.crt)
senha
A senha para ambos trustore e keystore. Na seguinte amostra, substitua PASSWORD por sua senha. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=password,value=PASSWORD)
protocolo
A versão do protocolo SSL para uso. Os valores suportados incluem SSLv2, SSLv3, TLSv1, SSLv2+SSLv3 e ALL. O default é ALL. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=protocol,value=ALL)
cipher-suite
Uma lista de vírgula separada das cifras de criptografia que são permitidas. O default JVM para o JSSE contém cifras fracas que não devem ser usadas. A amostra lista apenas duas cifras possíveis, mas as amostras atuais provavelmente usarão mais. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=cipher-suite, value="TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA")
key-alias
O alias usado para o certificado do servidor no keystore. Na seguinte amostra, substitua o KEY_ALIAS pelo seu certificado alias. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=key-alias,value=KEY_ALIAS)
truststore-type
O tipo de truststore. Os diversos tipos de keystores estão disponíveis, incluindo o PKCS12 e o default JKS do Java. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=truststore-type,value=jks)
keystore-type
O tipo do keystore. Diversos tipos de keystore estão disponíveis, incluindo o PKCS12 e o default JKS do Java. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=keystore-type,value=jks)
ca-certificate-file
O arquivo contendo os certificados CA. Isto é o truststoreFile, no caso do JSSE e usa a mesma senha ao do keystore. O arquivo ca-certificate-file é usado para validar os certificados do cliente. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=certificate-file,value=ca.crt)
ca-certificate-password
A senha do certificado para o ca-certificate-file. Na seguinte amostra, substitua o MASKED_PASSWORD por sua senha mascarada. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=ca-certificate-password,value=MASKED_PASSWORD)
ca-revocation-url
O arquivo ou URL que contém a lista de revocação. Isto refere-se ao crlFile para o JSSE ou o SSLCARevocationFile para o SSL. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=ca-revocation-url,value=ca.crl)
session-cache-size
O tamanho do SSLSession cache. Este atributo é válido para os conectores SSE apenas. O default é 0, que especifica um tamanho de cache ilimitado. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-cache-size,value=100)
session-timeout
O número de sessões antes de um SSLSession com cache expirar. Este atributo é válido apenas para conectores JSSE. O default é 86400 segundos, que é 24 horas. 
/profile=default/subsystem=web/connector=HTTPS/ssl=configuration/:write-attribute(name=session-timeout,value=43200)
Reportar um erro

8.6. FIPS 140-2 Compliant Encryption

8.6.1. Compatibilidade com o FIPS 140-2

O Federal Information Processing Standard 140-2 (FIPS 140-2) é o default de segurança de computador governamental para a referência dos módulos de software criptográficos. A compatibilidade FIPS 140-2 é normalmente uma solicitação de sistemas de software usada por agências governamentais e negócios do setor privado.
O JBoss 6 usa a criptografia de módulos externos e pode ser configurado para uso do módulo de criptografia de compatibilidade FIPS 140-2.
Reportar um erro

8.6.2. Senhas Compatíveis com o FIPS 140-2

Uma senha compatível com o FIPS deve possuir as seguintes características:
  1. Deve possuir sete (7) caracteres de comprimento.
  2. Deve incluir caracteres de pelo menos três (3) das seguintes classes de caracteres:
    • dígitos ASCII,
    • ASCII em letra minúscula,
    • ASCII em letra maiúscula,
    • ASCII não-alfanumérico e
    • não-ASCII.
Caso o primeiro caractere da senha for uma letra maiúscula ASCII, isto não será considerado como ASCII de letra maiúscula para a restrição 2.
Caso o último caractere da senha for um dígito ASCII, isto não conta como um dígito ASCII para a restrição 2.
Reportar um erro

8.6.3. Habilitação da Criptografia do FIPS 140-2 para o SSL no Red Hat Enterprise Linux 6

Esta tarefa descreve como configurar o contêiner da web (JBoss Web) do JBoss EAP 6 para a criptografia compatível com o FIPS 140-2 para o SSL. Esta tarefa descreve apenas as etapas para o Red Hat Enterprise Linux 6.
Esta tarefa usa a biblioteca Mozilla NSS no modo FIPS para este recurso.

Pré-requisitos

Procedimento 8.3. Habilitação da Criptografia Compatível FIPS 140-2 para o SSL

  1. Criação do banco de dados

    Crie o banco de dados NSS num diretório de propriedade do usuário jboss. 
    $ mkdir -p  /usr/share/jboss-as/nssdb
$ chown jboss /usr/share/jboss-as/nssdb 
$ modutil -create -dbdir /usr/share/jboss-as/nssdb

  2. Criação do arquivo de configuração NSS

    Crie um novo arquivo do texto com o mesmo nome nss_pkcsll_fips.cfg no diretório /usr/share/jboss-as com os seguintes conteúdos: 
    name = nss-fips
nssLibraryDirectory=/usr/lib64
nssSecmodDirectory=/usr/share/jboss-as/nssdb
nssModule = fips
    O arquivo de configuração NSS deve especificar:
    • um nome;
    • o diretório onde a biblioteca está localizada, e;
    • o diretório onde o banco de dados NSS foi criado, conforme na etapa 1.
    Caso você esteja executando uma versão de 64 bites do Red Hat Enterprise Linux 6, então determine o nssLibraryDirectory para /usr/lib, ao invés do /usr/lib64.

  3. Habilitação do provedor SunPKCS11

    Edite o arquivo da configuração java.security para o seu JRE ($JAVA_HOME/jre/lib/security/java.security) e adicione a seguinte linha: 
    security.provider.1=sun.security.pkcs11.SunPKCS11  /usr/share/jboss-as/nss_pkcsll_fips.cfg
    Perceba que o arquivo de configuração especificado nesta linha é o arquivo criado na etapa 2.
    Quaisquer outras linhas security.provider.X neste arquivo devem possuir o valor do X aumentado para um, com o objetivo de garantir que este provedor possui prioridade.

  4. Habilitação do modo FIPS para a biblioteca NSS

    Execute o comando modutil conforme apresentado para habilitar o modo FIPS: 
    modutil -fips true -dbdir /usr/share/jboss-as/nssdb
    Perceba que o diretório especificado aqui é o mesmo criado na etapa 1.
    Você pode obter um erro da biblioteca de segurança no ponto

  5. Altere a senha no token FIPS

    Determine a senha no token FIPS usando o seguinte comando. Perceba que o nome do token deve ser NSS FIPS 140-2 Certificate DB. 
    modutil -changepw "NSS FIPS 140-2 Certificate DB" -dbdir /usr/share/jboss-as/nssdb
    A senha usada para o token FIPS deve ser uma senha compatível com o FIPS.

  6. Crie um certificado usando as ferramentas NSS

    Insira o seguinte comando para criar um certificado usando as ferramentas NSS. 
    certutil -S -k rsa -n jbossweb  -t "u,u,u" -x -s "CN=localhost, OU=MYOU, O=MYORG, L=MYCITY, ST=MYSTATE, C=MY" -d /usr/share/jboss-as/nssdb

  7. Configure o conector HTTPS para o uso do PKCS11 keystore

    Adicione o conector usando o seguinte comando no JBoss CLI Tool: 
    /subsystem=web/connector=https/:add(socket-binding=https,scheme=https,protocol=HTTP/1.1,secure=true)
    Adicione a configuração SSL com o seguinte comando, substituindo a SENHA pela senha compatível com o FIPS da etapa 5. 
    /subsystem=web/connector=https/ssl=configuration:add(name=https,password=PASSWORD,keystore-type=PCKS11,
cipher-suite="SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA,
TLS_ECDH_anon_WITH_AES_256_CBC_SHA")

  8. Verificação

    Verifique se o JVM pode ler a chave privada a partir do PKCS11 pela execução do seguinte comando: 
    keytool -list -storetype pkcs11

Exemplo 8.3. A configuração XMl para o conector HTTPS usando o FIPS compatível

<connector name="https" protocol="HTTP/1.1" scheme="https" socket-binding="https" secure="true">
  <ssl name="https" password="****" 
      cipher-suite="SSL_RSA_WITH_3DES_EDE_CBC_SHA,SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
         TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA,
         TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,
         TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
         TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
         TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
         TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,
         TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,
         TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
         TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
         TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,TLS_ECDH_anon_WITH_AES_128_CBC_SHA,
         TLS_ECDH_anon_WITH_AES_256_CBC_SHA"
      keystore-type="PKCS11"/>
</connector>
Perceba que o atributo cipher-suite possui quebras de linha inseridas para facilitar a leitura.
Reportar um erro

Capítulo 9. Segurança de Rede

9.1. Segurança das Interfaces de Gerenciamento

Sumário

Num ambiente de teste, é típico executar o JBoss EAP 6 sem camada de segurança nas interfaces de gerenciamento, compostas do Console de Gerenciamento, CLI de Gerenciamento e qualquer outra implementação do API. Isto permite alterações rápidas de configuração e desenvolvimento .

Além disso, o modo de autenticação silenciosa está presente por default, permitindo um cliente local na máquina do host conectar-se ao CLI de Gerenciamento sem a solicitação de um nome do usuário ou senha. Este comportamento é conveniente aos usuários locais e scripts do CLI de Gerenciamento, porém isto pode ser desabilitado caso seja requerido. Este procedimento está descrito no tópico da Seção 10.5, “Remoção da Autenticação Silenciosa do Realm de Segurança Default”.
Quando você iniciar o teste e a preparação de seu ambiente para mover à produção, é muito importante que você aplique a segurança nas interfaces de gerenciamento usando os seguintes métodos:
Reportar um erro

9.2. Especificação de qual Interface da Rede o JBoss EAP 6 usa

Visão Geral

Efetuando a isolação de serviços de forma que eles sejam disponibilizados apenas aos clientes que necessitam dos mesmos para aumentar a segurança de sua rede. O JBoss EAP 6 inclui duas interfaces em suas configurações default, ambas pelas quais efetuam o bind ao endereço IP 127.0.0.1 ou localhost por default. Uma das interfaces é chamada management, e é usada pelo Management Console, CLI e API. A outra é chamada public e é usada para implantar aplicativos. Essas interfaces não são especiais ou significantes, mas são fornecidas como um ponto de iniciação.

A interface management usa as portas 9990 e 9999 por default e a interface public usa a porta 8080 ou porta 8443 caso você use o HTTPS.
Você pode alterar o endereço IP da interface de gerenciamento, interface pública ou ambas.

Atenção

Caso você exponha as interfaces de gerenciamento às outras interfaces que estão acessíveis a partir dos hosts remotos, certifique-se das implicações de segurança. Na maioria das vezes, não é recomendado fornecer acesso remoto às interfaces de gerenciamento.

  1. Interrompa o JBoss EAP 6.

    Interrompa o JBoss EAP 6 pelo envio de uma interrupção de maneira apropriada ao seu sistema operacional. Caso você estiver executando o JBoss EAP 6 como um aplicativo em primeiro plano, a maneira típica de realizar isto é pressionar Ctrl+C.

  2. Reinicie o JBoss EAP 6, especificando o endereço bind.

    Use a opção da linha de comando -b para iniciar o JBoss EAP 6 numa interface específica.

    Exemplo 9.1. Especifique a interface pública.

    EAP_HOME/bin/domain.sh -b 10.1.1.1

    Exemplo 9.2. Especifique a interface de gerenciamento.

    EAP_HOME/bin/domain.sh -bmanagement=10.1.1.1

    Exemplo 9.3. Especifique os diferentes endereços para cada interface.

    EAP_HOME/bin/domain.sh -bmanagement=127.0.0.1 -b 10.1.1.1

    Exemplo 9.4. Efetue a interface pública a todas as interfaces da rede.

    EAP_HOME/bin/domain.sh -b 0.0.0.0
É possível editar o seu arquivo de configuração XML diretamente para alterar os endereços bind default. No entanto, caso você realize isto, você não estará apto a usar a opção da linha de comando -b para especificar o endereço IP no período de execução, portanto isto não é recomendado. Caso você decida realizar isto, certifique-se de encerrar o JBoss EAP 6 completamente antes de editar o arquivo XML.
Reportar um erro

9.3. Configuração dos Firewalls de Rede para Trabalho com o JBoss EAP 6

Sumário

A maioria dos ambientes de produção usa firewalls como parte de uma estratégia de segurança de rede. Caso você precise de instâncias do servidor múltiplas para comunicarem-se entre si ou serviços externos, tal como os servidores da web ou fonte de dados, o seu firewall precisará levar isto em consideração. Um firewall bem gerenciado apenas abre as portas que são necessárias e os protocolos de rede.

A descrição completa sobre os firewalls não faz parte desta documentação.

Pré-requisitos

  • Determine as portas que você precisa abrir.
  • É necessário um entendimento sobre o software do firewall. Este procedimento usa o comando system-config-firewall no Red Hat Enterprise Linux 6. O Servidor do Microsoft Windows inclui um firewall interno e diversas soluções de firewall de terceiros estão disponíveis para cada plataforma.
Pressuposições

Este procedimento configura um firewall num ambiente com as seguintes pressuposições:

  • O sistema operacional é Red Hat Enterprise Linux 6.
  • O JBoss EAP 6 executa no host 10.1.1.2. Opcionalmente, o servidor possui o próprio firewall.
  • O servidor do firewall da rede é executado no host 10.1.1.1 do eth0 da interface e possui um eth1 de interface externa.
  • Você desejará um tráfego na porta 5445 (uma porta usada pelo JMS) enviado ao JBoss EAP 6. Nenhum outro tráfego deve ser permitido através do firewall da rede.

Procedimento 9.1. Gerencie os Firewalls da Rede e o JBoss EAP 6 para trabalhararem juntos

  1. Efetue o log ao Console de Gerenciamento.

    Efetue o log ao Consolde de Gerenciamento. Por default, ele executa no http://localhost:9990/console/.

  2. Determine os bindings do socket usados pelo grupo binging do socket.

    Clique no rótulo Profiles no canto superior do Console de Gerenciamento. No canto esquerdo da tela uma série de menus é apresentada. O cabeçalho do menu inferior é General Configuration. Clique no item Socket Binding abaixo deste cabeçalho. A tela Socket Binding Declarations irá aparecer. Inicialmente, o grupo standard-sockets é apresentado. Você pode escolher um grupo diferente selecionando-o a partir da caixa de combinação no lado direito.

    Nota

    Caso você use um servidor autônomo, isto possui apenas um grupo binding de socket.
    A lista dos nomes do socket e portas são apresentados, oito valores por página. Você pode avançar nas páginas pelo uso da flecha de navegação na parte inferior da tela.

  3. Determine as portas que você precisa abrir.

    Dependendo da função de uma porta em particular e dos requerimentos de seu ambiente, algumas portas podem precisar serem abertas em seu firewall.

  4. Configure seu firewall para envio de tráfego ao JBoss EAP 6.

    Execute essas etapas para configurar o seu firewall de rede para permitir tráfego na porta desejada.
    1. Efetue o log em sua máquina de firewall e acesse a solicitação de comando como usuário root.
    2. Insira o comando system-config-firewall para lançar a utilidade de configuração do firewall. Um GUI ou a utilidade da linha de comando é lançada, dependendo da maneira em que você está registrado no sistema firewall. Essa tarefa assume que você está registrado através do SSH e usando a interface da linha de comando.
    3. Use a chave TAB em seu teclado para navegar ao botão Customize e pressione a chave ENTER. A tela Trusted Services aparecerá.
    4. Não altere qualquer valor, porém use a chave TAB para navegar ao botão Forward e pressione ENTER para avançar à próxima tela. A tela Other Ports aparecerá.
    5. Use a chave TAB para navegar ao seu botão <Add> e pressione ENTER. A tela Port and Protocol aparecerá.
    6. Insira 5445 no campo Port / Port Range e use a chave TAB para mover ao campo Protocol e insira tcp. Use a chave TAB para navegar ao botão OK e pressione ENTER.
    7. Use a chave TAB para navegar ao botão Forward até que você encontre a tela Port Forwarding.
    8. Use a chave TAB para navegar ao seu botão <Add> e pressione ENTER.
    9. Preencha os valores seguintes para determinar a porta de envio para a porta 5445.
      • Interface de fonte: eth1
      • Protocolo: tcp
      • Porta / Intervalo de Porta: 5445
      • Destinação do endereço IP: 10.1.1.2
      • Porta / Intervalo de Porta: 5445
      Use a chave TAB para navegar ao botão OK e pressione ENTER.
    10. Use a chave TAB para navegar ao botão Close e pressione ENTER.
    11. Use a chave TAB para navegar ao botão OK e pressione ENTER. Leia o aviso e clique Yes para que as alterações tenham efeito.

  5. Configure um firewall em seu host do JBoss EAP 6.

    Algumas organizações escolhem em configurar no servidor do JBoss EAP 6, e encerram todas as portas que não necessárias para esta operação. Consulte a Seção 9.4, “Portas de rede usadas pela Plataforma do Aplicativo JBoss EAP 6” e determine quais portas devem ser abertas, e encerre o resto. A configuração default do Red Hat Enterprise Linux 6 encerra todas as portas com exceção da 22 (usada para Secure Shell (SSH) e 5353 (usada para multicast DNS). Enquanto você configura as portas, certifique-se de ter acesso físico ao seu servidor de forma que você não bloqueie-se acidentalmente.
Resultado

O seu firewall está configurado para envio de tráfego ao seu servidor do JBoss EAP 6 em sua configuração do firewall. Caso você escolha em ativar um firewall no seu servidor, todas as portas são encerradas com exceção daquelas necessárias para execução em seus aplicativos.

Reportar um erro

9.4. Portas de rede usadas pela Plataforma do Aplicativo JBoss EAP 6

As portas usadas pela configuração default da Plataforma do Aplicativo JBoss EAP 6 dependem de diversos fatores:
  • Se é que os seus grupos de servidores usam um dos grupos binding do socket default, ou um grupo personalizado.
  • Solicitações de suas implantações individuais.

Nota

O deslocamento da porta numérica pode ser configurado para aliviar os conflitos da porta quando você executar servidores múltiplos no mesmo servidor físico. Caso o seu servidor use um deslocamento de porta numérica, adicione o deslocamento ao número da porta default para este grupo binding do grupo do servidor. Por exemplo, caso a porta HTTP do grupo binding do socket é 8080 e seu servidor usa um deslocamento de porta de 100, sua porta HTTP será 8180.
As portas usam o protocolo TCP a não ser que isto seja determinado de forma diferente.

Grupos Binding de Socket default

  • full-ha-sockets
  • full-sockets
  • ha-sockets
  • standard-sockets

Tabela 9.1. Referência aos bindings de socket default

Nome Porta Porta Multicast Descrição full-ha-sockets full-sockets ha-socket standard-socket
ajp 8009 Protocolo Apache JServ. Usado para o balanceamento de carga e para aplicar o cluster HTTP. Sim Sim Sim Sim
http 8080 A porta default para os aplicativos da web implantados. Sim Sim Sim Sim
https 8443 A conexão criptografada SSL entre os aplicativos da web implantados e os clientes. Sim Sim Sim Sim
jacorb 3528 Serviços CORBA para transações JTS e outros serviços dependentes ORB. Sim Sim Não Não
jacorb-ssl 3529 Os serviços CORBA criptografados SSL. Sim Sim Não Não
jgroups-diagnostics 7500 Multicast. Usado para a descoberta de pares nos HA clusters. Isto não é configurável usando as Interfaces de Gerenciamento. Sim Não Sim Não
jgroups-mping 45700 Multicast. Usado para descobrir o associado inicial num clusters HA. Sim Não Sim Não
jgroups-tcp 7600 Descoberta de pares unicast nos clusters HA usando TCP. Sim Não Sim Não
jgroups-tcp-fd 57600 Usado para detecção de falha HA sobre o TCP. Sim Não Sim Não
jgroups-udp 55200 45688 Descoberta de pares unicast nos clusters HA usando UDP. Sim Não Sim Não
jgroups-udp-fd 54200 Usado para detecção de falha HA sobre o UDP. Sim Não Sim Não
messaging 5445 Serviço JMS. Sim Sim Não Não
messaging-group Referenciado pela difusão HornetQ JMS e grupos de descoberta. Sim Sim Não Não
messaging-throughput 5455 Usado pelo JMS Remoto. Sim Sim Não Não
mod_cluster 23364 A porta multicast de comunicação entre a Plataforma do Aplicativo JBoss EAP 6 e o balanceador de carga HTTP. Sim Não Sim Não
osgi-http 8090 Usado pelos componentes internos que usam o subsistema OSGi. Não é configurável usando as Interfaces de Gerenciamento. Sim Sim Sim Sim
remoting 4447 Usado para invocação remota EJB. Sim Sim Sim Sim
txn-recovery-environment 4712 O gerenciador de recuperação da transação JTA. Sim Sim Sim Sim
txn-status-manager 4713 Gerenciador da Transação JTA / JTS. Sim Sim Sim Sim
Portas Gerenciadas

Adicionado aos grupos binding do socket, cada controlador de host abre duas portas para propósitos de gerenciamento:

  • 9990 - A porta do Console de Gerenciamento da Web
  • 9999 - A porta usada pelo Console de Gerenciamento e API de Gerenciamento
Reportar um erro

Capítulo 10. Segurança da Interface de Gerenciamento

10.1. Segurança das Interfaces de Gerenciamento

Sumário

Num ambiente de teste, é típico executar o JBoss EAP 6 sem camada de segurança nas interfaces de gerenciamento, compostas do Console de Gerenciamento, CLI de Gerenciamento e qualquer outra implementação do API. Isto permite alterações rápidas de configuração e desenvolvimento .

Além disso, o modo de autenticação silenciosa está presente por default, permitindo um cliente local na máquina do host conectar-se ao CLI de Gerenciamento sem a solicitação de um nome do usuário ou senha. Este comportamento é conveniente aos usuários locais e scripts do CLI de Gerenciamento, porém isto pode ser desabilitado caso seja requerido. Este procedimento está descrito no tópico da Seção 10.5, “Remoção da Autenticação Silenciosa do Realm de Segurança Default”.
Quando você iniciar o teste e a preparação de seu ambiente para mover à produção, é muito importante que você aplique a segurança nas interfaces de gerenciamento usando os seguintes métodos:
Reportar um erro

10.2. Configuração de Segurança do Usuário Default

Introdução

Todas as interfaces de gerenciamento da Plataforma do Aplicativo JBoss EAP 6 são asseguradas por default. Esta segurança leva duas formas diferentes:

  • As interfaces locais são asseguradas pelo contrato SASL entre os clientes locais e o servidor que eles conectam. Esse mecanismo de segurança é baseado na habilidade do cliente acessar o filesystem local. Isto é devido uma vez que o acesso ao filesystem local permitiria o cliente adicionar um usuário ou, do contrário, alterar a configuração para impedir outros mecanismos de segurança. Isto adere o princípio de que se um acesso físico ao filesystem for atingido, outros mecanismos de segurança serão supérfluos. O mecanismo acontece em quatro etapas:

    Nota

    O acesso HTTP é considerado remoto, mesmo que você conecte ao localhost usando o HTTP.
    1. O cliente envia uma mensagem ao servidor que inclui uma solicitação para autenticar ao mecanismo SASL local.
    2. O servidor gera o token de uma vez, o grava a um arquivo único e envia uma mensagem ao cliente com o caminho completo ao do arquivo.
    3. O cliente lê o token a partir do arquivo e o envia ao servidor, verificando se isto possui acesso local ao filesystem.
    4. O servidor verifica o token e exclui o arquivo.
  • Os clientes remotos, incluindo os clientes HTTP locais, usam a segurança baseado no realm. O ManagementRealm é o realm default com permissões para configurar o JBoss EAP 6 remotamente usando interfaces de gerenciamento. O script é fornecido que o permite adicionar usuários a este realm (ou realms que você criou). Para maiores informações sobre a adição de usuários, refira-se ao capítulo Getting Started do JBoss EAP 6 Installation Guide. Para cada usuário, o nome de usuário, a senha hash e o realm são stored num arquivo.
    Managed domain
    EAP_HOME/domain/configuration/mgmt-users.properties
    Servidor Autônomo
    EAP_HOME/standalone/configuration/mgmt-users.properties
    Mesmo que os conteúdos do mgmt-users.properties estiverem mascarados, o arquivo deve continuar a ser tratado como um arquivo confidencial. Recomenda-se que isto seja configurado para o modo do arquivo de 600, que apenas fornece o acesso de leitura e gravação pelo proprietário do arquivo.
Reportar um erro

10.3. Visão Geral da Configuração da Interface de Gerenciamento Avançada

A configuração da interface de gerenciamento no EAP_HOME/domain/configuration/host.xml ou EAP_HOME/standalone/configuration/standalone.xml controla quais interfaces de rede o processo do controlador do host efetua o bind, quais os tipos de sistema de autenticação estão disponíveis e qual o tipo de sistema de autenticação é usado para autenticar os usuários em cada interface. Este tópico descreve como configurar as Interfaces de Gerenciamento para melhor acomodar o seu ambiente.
O subsistema de Gerenciamento consiste de um elemento <management> que inclui diversos atributos configuráveis e os três seguintes elementos filho configuráveis. Os realms de segurança e as conexões outbound são primeiramente definidos e então aplicados às interfaces de gerenciamento como atributos.
  • <security-realms>
  • <outbound-connections>
  • <management-interfaces>
Realms de Segurança

O security realm é responsável pela autenticação e autorização dos usuários permitidos a administrar o JBoss EAP 6 através do API de Gerenciamento, CLI de Gerenciamento ou Console de Gerenciamento baseado na web.

Dois realms de segurança baseados no arquivo estão incluídos na instalação default: ManagementRealm e ApplicationRealm. Cada um desses realms de segurança usa um arquivo -users.properties para realizar o store nos usuários e senha com hash e um -roles.properties para aplicar o store nos mapeamentos entre usuários e funções. O suporte é também incluído no realm de segurança habilitado LDAP.

Nota

Os realms de segurança podem também ser usados nos seus aplicativos. Os realms de segurança descritos aqui são específicos às interfaces de gerenciamento.
Conexões Outbound

Alguns realms de segurança conectam às interfaces externas tais como o servidor LDAP. Uma conexão outbound define como realizar esta conexão. Um tipo de conexão pré-definido, ldap-connection, configura todos os atributos requeridos e opcionais para conexão ao servidor LDAP e verificação do credencial.

Interfaces de Gerenciamento

A interface de gerenciamento inclui propriedades sobre como conectar e como configurar o JBoss EAP. Tal informação inclui a interface de rede nomeada, porta, realm de segurança e outras informações configuráveis sobre a interface. As duas interfaces estão incluídas numa instalação default:

  • O http-interface é uma configuração para o Console de Gerenciamento baseado na web.
  • O native-interface é a configuração para o CLI de Gerenciamento da linha de comando e API de Gerenciamento como o REST.
Cada um dos três elementos principais configuráveis do subsistema de gerenciamento do host estão inter-relacionados. O realm de segurança refere-se à conexão outbound e a interface de gerenciamento refere-se ao realm de segurança.
Maiores informações podem ser encontradas na Seção 10.1, “Segurança das Interfaces de Gerenciamento”.
Reportar um erro

10.4. Desabilitação da Interface de Gerenciamento HTTP

Num managed domain, você precisa apenas acessar a interface HTTP no controlador do domain, ao invés dos servidores do associado domain. Além disso, no servidor de produção, você pode decidir desabilitar o Console de Gerenciamento baseado na web.

Nota

Outros clientes, tais como o JBoss Operations Network, também operam usando a interface HTTP. Caso você deseje usar esses serviços e simplesmente desabilitar o próprio Management Console, você pode determinar o atributo console-enabled da interface HTTP para false, ao invés de desabilitar a interface completamente. 
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=console-enabled,value=false)
Para desabilitar o acesso à interface HTTP, que também desabilita o acesso ao Console de Gerenciamento baseado na web, você pode excluir a interface HTTP.
O seguinte comando do JBoss CLI permite que você leia os conteúdos atuais de sua interface HTTP, caso você decida adicioná-la novamente.

Exemplo 10.1. Leitura da Configuração da Interface HTTP

/host=master/core-service=management/management-interface=http-interface/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
    "outcome" => "success",
    "result" => {
        "console-enabled" => true,
        "interface" => "management",
        "port" => expression "${jboss.management.http.port:9990}",
        "secure-port" => undefined,
        "security-realm" => "ManagementRealm"
    }
}
Com o objetivo de remover a interface HTTP, imprima o seguinte comando:

Exemplo 10.2. Remoção da Interface HTTP

/host=master/core-service=management/management-interface=http-interface/:remove
Para reabilitar o acesso, imprima os seguintes comandos para recriar a Interface HTTP com os valores default.

Exemplo 10.3. Recriação da Interface HTTP

/host=master/core-service=management/management-interface=http-interface:add(console-enabled=true,interface=management,port="${jboss.management.http.port:9990}",security-realm=ManagementRealm)
Reportar um erro

10.5. Remoção da Autenticação Silenciosa do Realm de Segurança Default

Sumário

A instalação default do JBoss EAP 6 contém um método de autenticação silenciosa para o usuário CLI de Gerenciamento. Isto permite o usuário local a habilidade de acessar o CLI de Gerenciamento sem a autenticação do nome de usuário e senha. Esta funcionalidade é habilitada como conveniência e assiste usuários locais executando os scripts CLI de Gerenciamento sem o requerimento de autenticação. Ela é considerada um recurso útil permitindo o acesso à configuração local e também fornece ao usuário a habilidade de adicionar seus próprios detalhes ou desabilitar as checagens de segurança.

A conveniência da autenticação silenciosa para usuários locais é que ela pode ser desabilitada onde o grande controle de segurança é requerido. Isto pode ser atingido pela remoção do elemento local sem a seção security-realm do arquivo de configuração. Isto é aplicado a ambos standalone.xml para instância do Servidor Autônomo ou host.xml para o Managed Domain. Você deve considerar apenas a remoção do elemento local caso você entenda o impacto que isto tem em sua configuração do servidor em particular.
O método preferido de remoção da autenticação silenciosa é o uso do CLI de Gerenciamento, que remove diretamente o elemento local visível na seguinte amostra.

Exemplo 10.4. Amostra do elemento local no security-realm.

<security-realms>
    <security-realm name="ManagementRealm">
        <authentication>
            <local default-user="$local"/>
            <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
        </authentication>
    </security-realm>
    <security-realm name="ApplicationRealm">
        <authentication>
            <local default-user="$local" allowed-users="*"/>
            <properties path="application-users.properties" relative-to="jboss.server.config.dir"/>
        </authentication>
        <authorization>
            <properties path="application-roles.properties" relative-to="jboss.server.config.dir"/>
        </authorization>
    </security-realm>
</security-realms>

Pré-requisitos

  • Inicie a instância do JBoss EAP 6.
  • Inicie o CLI de Gerenciamento.

Procedimento 10.1. Remoção da Autenticação Silenciosa do Realm de Segurança Default

  • Remova a autenticação silenciosa com o CLI de Gerenciamento

    Remova o elemento local a partir do Realm de Gerenciamento e Realm do Aplicativo conforme solicitado.
    1. Remova o elemento local a partir do Realm de Gerenciamento.

      • Servidores Autônomos

        /core-service=management/security-realm=ManagementRealm/authentication=local:remove

      • Managed Domains

        /host=HOST_NAME/core-service=management/security-realm=ManagementRealm/authentication=local:remove
    2. Remova o elemento local a partir do Realm do Aplicativo.

      • Servidores Autônomos

        /core-service=management/security-realm=ApplicationRealm/authentication=local:remove

      • Managed Domains

        /host=HOST_NAME/core-service=management/security-realm=ApplicationRealm/authentication=local:remove
Resultado

O modo de autenticação silenciosa é removido do ManagementRealm e ApplicationRealm.

Reportar um erro

10.6. Desabilitação do Acesso Remoto ao Subsistema JMX

A conectividade JMX remota permite você aplicar o trigger no JDK e operações de gerenciamento do aplicativo. Com o objetivo de aplicar a segurança numa instalação, desabilite esta função. Você pode realizar isto tanto pela remoção da configuração da conexão remota ou remoção do subsistena JMX. Os comandos do JBoss CLI referenciam o perfil default numa configuração de managed domain. Para modificar um perfil diferente, modifique a parte /profile=default do comando. Para o servidor autônomo, remova aquela porção do comando completamente.

Nota

Num managed domain, o conector remoto é removido do subsistema JMX por default. Este comando é fornecido para sua informação, caso deseje adicioná-lo durante o desenvolvimento.

Exemplo 10.5. Remoção do Conector Remoto do Subsistema JMX

/profile=default/subsystem=jmx/remoting-connector=jmx/:remove

Exemplo 10.6. Remova o subsistema JMX

Execute este comando para cada perfil que você usar, caso use um managed domain. 
/profile=default/subsystem=jmx/:remove
Reportar um erro

10.7. Configuração dos Security Realms para as Interfaces de Gerenciamento

As Interfaces de Gerenciamento usam security realms para controlar a autenticação e acesso aos mecanismos de configuração do JBoss EAP 6. Este tópico apresenta como ler e configurar os security realms. Esses comandos usam o CLI de Gerenciamento.
Leia a Configuração do Realm de Segurança

Esta amostra apresenta a configuração default para o realm de segurança ManagementRealm. Isto usa um arquivo chamado mgmt-users.properties para efetuar o store em sua própria informação de configuração.

Exemplo 10.7. ManagementRealm Default

	/host=master/core-service=management/security-realm=ManagementRealm/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
{
    "outcome" => "success",
    "result" => {
        "authorization" => undefined,
        "server-identity" => undefined,
        "authentication" => {"properties" => {
            "path" => "mgmt-users.properties",
            "plain-text" => false,
            "relative-to" => "jboss.domain.config.dir"
        }}
    }
}
Gravação de um Realm de Segurança

Os seguintes comandos criam um novo security realm chamado TestRealm e configuram o diretório para o arquivo de propriedades relevantes.

Exemplo 10.8. Gravação de um Realm de Segurança

/host=master/core-service=management/security-realm=TestRealm/:add/host=master/core-service=management/security-realm=TestRealm/authentication=properties/:add(path=TestUsers.properties, relative-to=jboss.domain.config.dir)
Aplicação do Realm de Segurança à Interface de Gerenciamento

Após adicionar um security realm, forneça-o como referência à Interface de Segurança.

Exemplo 10.9. Adição de um Realm de Segurança a uma Interface de Gerenciamento

/host=master/core-service=management/management-interface=http-interface/:write-attribute(security-realm=TestRealm)
Reportar um erro

10.8. Configuração do Console de Gerenciamento para o HTTPS no modo Autônomo

Procedimento 10.2. 

  1. Certifique-se de que o console de gerenciamento efetua o bind ao HTTPS para sua própria interface pela adição da configuração management-https e remoção da configuração management-http.
    Isto pode ser realizado pela edição do arquivo standalone.xml (que não é recomendado) ou pelo uso dos seguintes comandos de interface CLI: 
    /core-service=management/management-interface=http-interface:write-attribute(name=secure-socket-binding, value=management-https)
    /core-service=management/management-interface=http-interface:undefine-attribute(name=socket-binding)

  2. Opcional:

    Caso você esteja usando um grupo socket-binding personalizado, certifique-se de que o binding management-https está definido (isto está presente por default, limitado pela porta 9443). 
     <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
        <socket-binding name="management-native" interface="management" port="${jboss.management.native.port:9999}"/>
        <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
        <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9443}"/>
  3. Gere um par de chaves conforme Seção 8.4, “Criação de uma Chave de Criptografia SSL e Certificado”.
  4. Adicione um elemento server-identities à seção security-realm do arquivo de configuração standalone.xml de sua instalação.
    Você pode definir o protocolo, o caminho keystore, a senha keystore e o alias para o par de chaves com este elemento.
    Execute o seguinte comando CLI, substituindo o seus próprios valores pelos valores de amostra. Esta amostra assume que o keystore é copiado ao diretório de configuração do servidor, do qual é EAP_HOME/standalone/configuration/ para um servidor autônomo. 
    /core-service=management/security-realm=ManagementRealm/server-identity=ssl:add(keystore-path=server.keystore,keystore-relative-to=jboss.server.config.dir, keystore-password=SECRET, alias=KEY_ALIAS)
  5. Reinicie o seu servidor autônomo.
Reportar um erro

10.9. Configuração do Console de Gerenciamento para o HTTPS no modo Domain

Procedimento 10.3. 

  1. Gere um par de chaves conforme Seção 8.4, “Criação de uma Chave de Criptografia SSL e Certificado”.
  2. Adicione um elemento server-identities ao bloco security-realm em suas instalações host.xml..
    Você pode definir o protocolo, o caminho keystore, a senha keystore e o alias para o par de chaves com este elemento.
    Execute o seguinte comando CLI, substituindo o seus próprios valores pelos valores de amostra. Esta amostra assume que o keystore é copiado ao diretório de configuração do servidor, do qual é EAP_HOME/domain/configuration/ para um managed domain. 
    /host=master/core-service=management/security-realm=ManagementRealm/server-identity=ssl:add(protocol=TLSv1, keystore-path=server.keystore,keystore-relative-to=jboss.domain.config.dir, keystore-password=SECRET, alias=KEY_ALIAS)
  3. Altere o elemento do socket com a seção management-interface adicionando o secure-port e removendo a configuração da porta.
    Use os seguintes comandos: 
    /host=master/core-service=management/management-interface=http-interface:write-attribute(name=secure-port,value=9443) 
    /host=master/core-service=management/management-interface=http-interface:undefine-attribute(name=port)
  4. Reinicie o seu domain.
Reportar um erro

10.10. Uso de 2-maneiras para a interface de Gerenciamento e do CLI

Neste tópico as seguintes convenções são usadas:

HOST1
O hostname dos servidor JBoss. Por exemplo: jboss.redhat.com
HOST2
Um nome apropriado ao cliente. Por exemplo: myclient. Perceba que isto não é necessariamente um hostname atual.
CA_HOST1
O DN (distinguished name - nome distinguido) para uso do certificado HOST1. Por exemplo: cn=jboss,dc=redhat,dc=com.
CA_HOST2
O DN para uso do certificado HOST2. Por exemplo: cn=myclient,dc=redhat,dc=com.

Procedimento 10.4. 

  1. Gere os stores: 
    keytool -genkeypair -alias HOST1_alias -keyalg RSA -keysize 1024 -validity 365 -keystore host1.keystore.jks -dname "CA_HOST1" -keypass secret -storepass secret
    keytool -genkeypair -alias HOST2_alias -keyalg RSA -keysize 1024 -validity 365 -keystore host2.keystore.jks -dname "CA_HOST2" -keypass secret -storepass secret
  2. Exporte os certificados: 
    keytool -exportcert  -keystore HOST1.keystore.jks -alias HOST1_alias -keypass secret -storepass secret -file HOST1.cer

    keytool -exportcert  -keystore HOST2.keystore.jks -alias HOST2_alias -keypass secret -storepass secret -file HOST2.cer
  3. Importe os certificados aos trust store opostos: 
    keytool -importcert -keystore HOST1.truststore.jks -storepass secret -alias HOST2_alias -trustcacerts -file HOST2.cer

    keytool -importcert -keystore HOST2.truststore.jks -storepass secret -alias HOST1_alias -trustcacerts -file HOST1.cer
  4. Defina o CertificateRealm na configuração para a sua instalação (host.xml ou standalone.xml) e aponte a interface a isto:
    Isto pode ser realizado pela edição manual do arquivo de configuração (não recomendado) ou pelo uso dos seguintes comandos: 
    /core-service=management/security-realm=CertificateRealm:add()
    /core-service=management/security-realm=CertificateRealm:add/server-identity=ssl:add(keystore-path=/path/to/HOST1.keystore.jks,keystore-password=secret, alias=HOST1_alias)
    /core-service=management/security-realm=CertificateRealm/authentication=truststore:add(keystore-path=/path/to/HOST1.truststore.jks,keystore-password=secret)
  5. Edite o JBOSS_HOME/bin/jboss-cli.xml e adicione a configuração SSL (usando os valore apropriados às variáveis): 
    <ssl>
  <alias>$HOST2alias</alias>
  <key-store>/path/to/HOST2.keystore.jks</key-store>
  <key-store-password>secret</key-store-password>
  <trust-store>/path/to/HOST2.truststore.jks</trust-store>
  <trust-store-password>secret</trust-store-password>
  <modify-trust-store>true</modify-trust-store>
</ssl>
Reportar um erro

10.11. Vaults da Senha para Sequências Confidenciais

10.11.1. Sequências Confidenciais de Segurança nos Arquivos de texto limpo

Os aplicativos da web e outras implantações sempre incluem arquivos de texto limpo, tal como os descritores de implantação XML, que incluem a informação confidencial tal como senhas e outras sequências confidenciais. O JBoss EAP 6 inclui uma senha de mecanismo vault que o habilita criptografar as sequências confidenciais e as store num keystore criptografado. O mecanismo vault gerencia a criptografia das sequências para uso com os security domains, security realms e outros sistemas de verificação. O mecanismo baseia-se nas ferramentas que estão inclusas em todas as implementações do Java Development Kit (JDK).

Atenção

Alguns problemas foram encontrados quando usando o recurso de segurança Vault com o JBoss EAP 6. Foi comprovado que o vault.keystore que gerava o Sun/Oracle keytool não é um keystore válido quando usado com um IBM JDK. Isto é devido ao fato de que as implementações JCEKS keystore implementations diferencem-se entre os fornecedores do Java.
Este problema ocorre quando o keystore gerado pelo Oracle Java é usado numa instância JBoss EAP na instalação IBM Java. Nestes casos, o servidor não irá iniciar e lançará a seguinte exceção: 
java.io.IOException: com.sun.crypto.provider.SealedObjectForKeyProtector
No momento, a única alternativa é evitar a tentativa de uso do keystore gerado com um Oracle keystool em um ambiente usando a implementação IBM Java.
Reportar um erro

10.11.2. Criação do Java Keystore para Sequências Confidenciais do Store

Pré-requisitos

  • O comando keytool deve estar disponível para uso. Ele é fornecido pelo Java Runtime Environment (JRE). Localize o caminho para o arquivo. No Red Hat Enterprise Linux, isto é instalado no /usr/bin/keytool.

Procedimento 10.5. Configuração do Java Keystore

  1. Crie um diretório para realizar o store de seu keystore e outras informações criptografadas.

    Crie um diretório para manter o seu keystore e outras informações importantes. O resto deste procedimento assume que o diretório é o /home/USER/vault/.

  2. Determine os parâmetros para uso com o keytool.

    Determinação dos parâmetros da operação
    alias
    O alias é um identificador único para o vault e outros dados stored no keystore. O alias no comando de amostra no final deste procedimento é o vault. Os Aliases são sensíveis à letra maiúscula e minúscula.
    keyalg
    O algoritmo de uso na criptografia. A amostra neste procedimento usa o RSA. Use a documentação para seu JRE e sistema operacional para verificar quais das chances estão disponíveis.
    keysize
    O tamanho da chave de criptografia impacta em como é difícil descriptografar a partir de força bruta. A amostra deste procedimento usa 2048. Consulte a documentação distribuída com o keytool para maiores informações sobre os valores apropriados.
    keystore
    O keystore é um banco de dados que mantém a informação criptografada e a informação de como criptografá-la. Caso você não deseje especificar o keystore, o default de uso do keystore é um arquivo chamado .keystore no seu diretório principal. A primeira vez que você adicionar dados ao keystore, ele será criado. A amostra neste procedimento usa o vault.keystore keystore.
    O comando keytool possui muitas outras opções. Refira-se à documentação para maiores informações sobre o seu JRE ou o seu sistema operacional.

  3. Determine as respostas às questões que o comando keystore irá perguntá-lo.

    O keystore precisa da seguinte informação com o objetivo de povoar a entrada keystore.
    Senha Keystore
    Quando você criar um keystore, você deve determinar uma senha. Com o objetivo de trabalhar com o keystore no futuro, você precisará de uma senha. Crie uma senha forte que você lembre-se. O keystore é apenas seguro conforme sua senha e a segurança do sistema de arquivo e sistema operacional que isto reside.
    Senha chave (opcional)
    Além da senha keystore, você pode especificar uma senha para cada chave que isto mantém. Com objetivo de usar uma chave, a senha precisa ser fornecida cada vez que ela é usada. Normalmente, esta facilidade não é usada.
    Primeiro nome e sobrenome
    Esta informação, e o resto da informação na lista, o orienta a identificar unicamente a chave e a posiciona numa hierarquia de outras chaves. Não é necessário nomeação, porém isto deve ser duas palavras e deve ser único ao da chave. A amostra neste procedimento usa o Accounting Administrator. Nos termos do diretório, isto torna-se common name do certificado.
    Unidade organizacional
    Isto é uma única palavra que identifica quem usa o certificado. Isto pode ser o aplicativo ou a unidade comercial. A amostra neste procedimento usa o AccountingServices. Normalmente, todos os keystores usados por um grupo ou aplicativo usam a mesma unidade organizacional.
    Organização
    Isto é normalmente uma representação de palavra única de seu nome de organização. Isto normalmente permanece o mesmo por todos os certificados usados por uma organização. Esta amostra usa o MyOrganization.
    Cidade ou municipalidade
    A sua cidade.
    Estado ou província.
    O seu estado ou província, ou o equivalente para sua localidade.
    País
    Um código de duas letras de seu país.
    Todas essas informações juntas criarão uma hierarquia para os seus keystores e certificados, garantindo que eles usam uma estrutura de nomeação consistente, porém são únicas.

  4. Execute o comando keytool, fornecendo a informação que você obteve.

    Exemplo 10.10. Entrada e saída da amostra do comando keystore.

    $ keytool -genseckey -alias vault -storetype jceks -keyalg AES -keysize 128 -storepass vault22 -keypass vault22 -keystore /home/USER/vault/vault.keystore
Enter keystore password: vault22 
Re-enter new password:vault22 
What is your first and last name?
  [Unknown]:  Accounting Administrator
What is the name of your organizational unit?
  [Unknown]:  AccountingServices
What is the name of your organization?
  [Unknown]:  MyOrganization
What is the name of your City or Locality?
  [Unknown]:  Raleigh
What is the name of your State or Province?
  [Unknown]:  NC
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=Accounting Administrator, OU=AccountingServices, O=MyOrganization, L=Raleigh, ST=NC, C=US correct?
  [no]:  yes

Enter key password for <vault>
        (RETURN if same as keystore password):
Resultado

O arquivo nomeado vault.keystore é criado no diretório /home/USER/vault/. Ele realiza o store numa chave única chamada vault, que será usada para efetuar o store nas sequências criptografadas, tais como senhas, para o JBoss EAP 6.

Reportar um erro

10.11.3. Mascarando a Senha Keystore e Inicialização do Vault da Senha

Pré-requisitos

  1. Execute o comando vault.sh.

    Execute o EAP_HOME/bin/vault.sh. Inicie a sessão interativa digitando 0.

  2. Insira o diretório onde os arquivos criptografados serão stored.

    Este diretório deve ser bastante seguro, mas o JBoss EAP 6 precisa estar apto a acessá-lo. Caso você tenha seguido a Seção 10.11.2, “Criação do Java Keystore para Sequências Confidenciais do Store”, o seu keystore está num diretório chamado vault/ no seu diretório principal. Esta amostra usa o /home/USER/vault/ do diretório.

    Nota

    Não se esqueça de incluir a barra à direita no nome do diretório. Tanto use / ou \, dependendo de seu sistema operacional.

  3. Insira o caminho ao keystore.

    Insira o caminho completo ao arquivo keystore. Esta amostra usa o /home/USER/vault/vault.keystore.

  4. Criptografe a senha keystore.

    As seguintes etapas criptografam a senha keystore, de forma que você pode usá-la nos arquivos de configuração e aplicativos de forma segura.

    1. Insira a senha keystore.

      Quando solicitado, insira a senha keystore.

    2. Insira o valor salt.

      Insira o valor salt de 8 caracteres. O valor salt, juntamente com a contagem de interação (abaixo), são usados para criar o valor hash.

    3. Insira a contagem de interação.

      Insira o número para contagem de interagem.

    4. Anote a informação de senha mascarada.

      A senha mascarada, o salt, e a contagem de interação são emitidas para a saída default. Anote-os numa localização segura. Um atacante poderia usá-los para criptografar a senha.

    5. Insira o alias do vault.

      Quando solicitado, insira o alias do vault. Caso você tenha seguido a Seção 10.11.2, “Criação do Java Keystore para Sequências Confidenciais do Store” para criar o seu vault, o alias é vault.

  5. Saia do console interativo.

    Digite 2 para sair do console interativo.
Resultado

A sua senha keystore foi mascarada para uso nos arquivos de configuração e implantações. Além disso, o seu vault é inteiramente configurado e está pronto para uso.

Reportar um erro

10.11.4. Configuração do JBoss EAP para Uso do Vault de Senha

Visão Geral

Antes de você poder mascarar as senhas e outros atributos confidenciais nos arquivos de configuração, você precisa fazer com que o JBoss EAP 6 esteja ciente da senha do vault que os aplica o store e os descriptografa. Siga este procedimento para habilitar esta funcionalidade.

Pré-requisitos

Procedimento 10.6. Criação do Vault da Senha

  1. Determine os valores corretos para o comando.

    Determine os valores para os seguintes parâmetros, que são determinadas pelos comandos usados para criar o próprio keystore. Para maiores informações sobre a criação do keystore, refira-se aos seguintes tópicos Seção 10.11.2, “Criação do Java Keystore para Sequências Confidenciais do Store” e Seção 10.11.3, “Mascarando a Senha Keystore e Inicialização do Vault da Senha”.
    Parâmetro Descrição
    KEYSTORE_URL
    O caminho do sistema do arquivo ou URI do arquivo keystore normalmente chamado vault.keystore
    KEYSTORE_PASSWORD
    A senha usada para acessar o keystore. Esse valor deve ser mascarado.
    KEYSTORE_ALIAS
    O nome do keystore.
    SALT
    O salt usado para criptografar e descriptografar os valores keystore.
    ITERATION_COUNT
    O número de vezes que o algoritmo criptografar está sendo executado.
    ENC_FILE_DIR
    O caminho ao diretório a partir dos comandos keystore que estão sendo executados. Normalmente o diretório contendo o vault da senha.
    host (managed domain apenas)
    O nome do host que você está configurando.

  2. Use o CLI de Gerenciamento para habilitar do vault da senha.

    Execute os seguintes comandos, dependendo se é que você usa o managed domain ou configuração do servidor autônomo. Substitua os valores no comando pelos valores da primeira etapa deste procedimento.

    Nota

    Caso você use o Microsoft Windows Server, substitua cada caractere / num filename ou caminho do diretório com quatro caracteres \. Isto é devido a necessidade de ter dois caracteres \, cada entre espaços. Isto não precisa ser feito para outros caracteres /.

    • Managed Domain

      /host=YOUR_HOST/core-service=vault:add(vault-options=[("KEYSTORE_URL" => "PATH_TO_KEYSTORE"), ("KEYSTORE_PASSWORD" => "MASKED_PASSWORD"), ("KEYSTORE_ALIAS" => "ALIAS"), ("SALT" => "SALT"),("ITERATION_COUNT" => "ITERATION_COUNT"), ("ENC_FILE_DIR" => "ENC_FILE_DIR")])

    • Servidor Autônomo

      /core-service=vault:add(vault-options=[("KEYSTORE_URL" => "PATH_TO_KEYSTORE"), ("KEYSTORE_PASSWORD" => "MASKED_PASSWORD"), ("KEYSTORE_ALIAS" => "ALIAS"), ("SALT" => "SALT"),("ITERATION_COUNT" => "ITERATION_COUNT"), ("ENC_FILE_DIR" => "ENC_FILE_DIR")])
    Segue abaixo uma amostra do comando com os seguintes valores hipotéticos: 
    /core-service=vault:add(vault-options=[("KEYSTORE_URL" => "/home/user/vault/vault.keystore"), ("KEYSTORE_PASSWORD" => "MASK-3y28rCZlcKR"), ("KEYSTORE_ALIAS" => "vault"), ("SALT" => "12438567"),("ITERATION_COUNT" => "50"), ("ENC_FILE_DIR" => "/home/user/vault/")])
Resultado

O JBoss EAP 6 é configurado para as sequências mascaradas e descriptografadas usando a senha do vault. Para adicionar as sequências ao vault e usá-las na sua configuração, refira-se ao seguinte tópico: Seção 10.11.5, “Store e Recuperação das Sequências Confidenciais Criptografas do Java Keystore”.

Reportar um erro

10.11.5. Store e Recuperação das Sequências Confidenciais Criptografas do Java Keystore

Sumário

A inclusão de senhas e outras sequências confidenciais nos arquivos de configuração em texto plano não está segurado. O JBoss EAP 6 inclui a habilidade de aplicar o store e mascarar essas sequências confidenciais num keystore criptografado e usa valores mascarados nos arquivos de configuração.

Pré-requisitos

Procedimento 10.7. Configuração do Java Keystore

  1. Execute o comando vault.sh.

    Execute o EAP_HOME/bin/vault.sh. Inicie a sessão interativa digitando 0.

  2. Insira o diretório onde os arquivos criptografados serão stored.

    Caso você tenha seguido a Seção 10.11.2, “Criação do Java Keystore para Sequências Confidenciais do Store”, o seu keystore está num diretório chamado vault/ no seu diretório principal. Na maioria das vezes, faz sentido aplicar o store em todas as suas informações criptografadas no mesmo local ao do store da chave. Essa amostra usa o diretório /home/USER/vault/.

    Nota

    Não se esqueça de incluir a barra à direita no nome do diretório. Tanto use / ou \, dependendo de seu sistema operacional.

  3. Insira o caminho ao keystore.

    Insira o caminho completo ao arquivo keystore. Esta amostra usa o /home/USER/vault/vault.keystore.

  4. Insira a senha keystore, o nome do vault, o salt, e a contagem de interação.

    Quando solicitado, insira a senha keystore, o nome do vault, o salt, e a contagem de interação. Um acordo é executado.

  5. Selecione a opção para realizar o store na senha.

    Selecione a opção 0 para realizar o store na senha ou outra sequência confidencial.

  6. Insira o valor.

    Quando solicitado, insira duas vezes o valor. Caso os valores não coincidam, você será solicitado a tentar novamente.

  7. Insira o bloco vault.

    Insira o bloco vault, que é um contêiner para atributos que pertencem ao mesmo recurso. Uma amostra deste nome do atributo seria ds_ExampleDS. Isto fará parte de uma referência à sequência criptografada, na sua fonte de dados ou outra definição do serviço.

  8. Insira o nome do atributo.

    Insira o nome do atributo que você está aplicando o store. Uma amostra do nome do atributo seria password.
    Resultado

    Uma mensagem parecida com a abaixo demonstra que o atributo foi salvo. 

    Valor do Atributo para (ds_ExampleDS, password) salvos

  9. Anote a informação sobre a sequência criptografada.

    A mensagem imprime para o resultado default, apresentando o bloco vault, nome do atributo, chave compartilhada e recomendação sobre o uso da sequência em sua configuração. Anote esta informação numa localização segura. O resultado da amostra é exibido abaixo: 
    ********************************************
Vault Block:ds_ExampleDS
Attribute Name:password
Configuration should be done as follows:
VAULT::ds_ExampleDS::password::1
********************************************

  10. Uso da sequência criptografada na sua configuração.

    Use a sequência a partir da sequência em sua configuração, no local de uma sequência de texto plano. A fonte de dados usando a senha criptografia é apresentada abaixo. 
    ...
  <subsystem xmlns="urn:jboss:domain:datasources:1.0">
    <datasources>
      <datasource jndi-name="java:jboss/datasources/ExampleDS" enabled="true" use-java-context="true" pool-name="H2DS">
        <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
        <driver>h2</driver>
        <pool></pool>
        <security>
          <user-name>sa</user-name>
          <password>${VAULT::ds_ExampleDS::password::1}</password>
        </security>
      </datasource>
      <drivers>
         <driver name="h2" module="com.h2database.h2">
            <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
         </driver>
      </drivers>
    </datasources>
  </subsystem>
...
    Você pode usar a sequência criptografada em qualquer local de seu domain ou arquivo de configuração autônomo onde as expressões são permitidas.

    Nota

    Para verificar se as expressões são permitidas com um subsistema em particular, execute o seguinte comando CLI em relação ao subsistema: 
    /host=master/core-service=management/security-realm=TestRealm:read-resource-description(recursive=true)
    A partir de um resultado de execução deste comando, busque pelo valor para o parâmetro expressions-allowed. Caso isto seja verdadeiro, você pode usar expressões com a configuração do subsistema particular.
    Após você aplicar o store na sua sequência do keystore, use a seguinte sintaxe para substituir qualquer sequência de texto limpo por uma criptografada. 
    ${VAULT::<replaceable>VAULT_BLOCK</replaceable>::<replaceable>ATTRIBUTE_NAME</replaceable>::<replaceable>ENCRYPTED_VALUE</replaceable>}
    Segue abaixo uma amostra do valor de mundo real, onde o bloco vault é ds_ExampleDS e o atributo é password. 
    <password>${VAULT::ds_ExampleDS::password::1}</password>
Reportar um erro

10.11.6. Store e Sequência Confidencial à Resolução em seus Aplicativos

Visão Geral

Os elementos de configuração do JBoss EAP 6 suportam a habilidade de resolver as sequências criptografadas em relação aos valores stored no Java Keystore através do mecanismo Security Vault. Você pode adicionar suporte deste recurso aos seus próprios aplicativos.

Primeiro, adicione a senha ao vault. Segundo, substitua a senha do texto limpo pela stored no vault. Você pode usar este método para obscurecer qualquer sequência confidencial em seu aplicativo.
Pré-requisitos

Antes de executar este procedimento, certifique-se de que o diretório para realizar o storing em seus arquivos vault existe. Não importa onde você os posiciona, contanto que o usuário que executa o JBoss EAP 6 possua permissão para leitura e escrita dos arquivos. Essa amostra posiciona o diretório vault/ no diretório /home/USER/vault/. O próprio vault é um arquivo chamado vault.keystore dentro do diretório vault/.

Exemplo 10.11. Adição da Sequência da Senha ao Vault

Adicione a sequência ao vault usando o comando EAP_HOME/bin/vault.sh. As séries completas de comandos e respostas estão incluídos no seguinte resultado da tela. Os valores inseridos pelo usuário são enfatizados. Alguns resultados são removidos para formatação. No Microsoft Windows, o nome do comando é vault.bat. Perceba que no Microsoft Windows, os caminhos de arquivo usam o caractere \ como um separador de diretório ao invés do caractere /. 
[user@host bin]$ ./vault.sh 
**********************************
****  JBoss Vault ********
**********************************
Please enter a Digit::   0: Start Interactive Session  1: Remove Interactive Session  2: Exit
0
Starting an interactive session
Enter directory to store encrypted files:/home/user/vault/
Enter Keystore URL:/home/user/vault/vault.keystore
Enter Keystore password: ...
Enter Keystore password again: ...
Values match
Enter 8 character salt:12345678
Enter iteration count as a number (Eg: 44):25

Enter Keystore Alias:vault
Vault is initialized and ready for use
Handshake with Vault complete
Please enter a Digit::   0: Store a password  1: Check whether password exists  2: Exit
0
Task:  Store a password
Please enter attribute value: sa
Please enter attribute value again: sa
Values match
Enter Vault Block:DS
Enter Attribute Name:thePass
Attribute Value for (DS, thePass) saved

Please make note of the following:
********************************************
Vault Block:DS
Attribute Name:thePass
Configuration should be done as follows:
VAULT::DS::thePass::1
********************************************

Please enter a Digit::   0: Store a password  1: Check whether password exists  2: Exit
2
A sequência que será adicionada ao código Java é o último valor do resultado, a linha iniciando com VAULT.
O seguinte servlet usa a sequência com vault ao invés de uma senha de texto limpo. A versão de texto limpo é comentado de forma que você pode verificar a diferença.

Exemplo 10.12. Servlet usando uma Senha com Vault

package vaulterror.web;
 
import java.io.IOException;
import java.io.Writer;
 
import javax.annotation.Resource;
import javax.annotation.sql.DataSourceDefinition;
import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import javax.sql.DataSource;
 
 
/*@DataSourceDefinition(
        name = "java:jboss/datasources/LoginDS",
        user = "sa",
        password = "sa",
        className = "org.h2.jdbcx.JdbcDataSource",
        url = "jdbc:h2:tcp://localhost/mem:test"
)*/
@DataSourceDefinition(
        name = "java:jboss/datasources/LoginDS",
        user = "sa",
        password = "VAULT::DS::thePass::1",
        className = "org.h2.jdbcx.JdbcDataSource",
        url = "jdbc:h2:tcp://localhost/mem:test"
)
@WebServlet(name = "MyTestServlet", urlPatterns = { "/my/" }, loadOnStartup = 1)
public class MyTestServlet  extends HttpServlet {
 
    private static final long serialVersionUID = 1L;
 
 
    @Resource(lookup = "java:jboss/datasources/LoginDS")
    private DataSource ds;
 
    @Override
    protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
        Writer writer = resp.getWriter();
        writer.write((ds != null) + "");
    }
}
O seu servlet está apto a resolver a sequência com vault.
Reportar um erro

10.12. LDAP

10.12.1. LDAP

O Lightweight Directory Access Protocol (LDAP) é um protocolo para aplicação do store e distribuição da informação do diretório pela rede. Esta informação do diretório inclui a informação sobre os usuários, dispositivos de hardware, funções de acesso e restrições, além de outras informações.
Algumas implementações comuns do LDAP incluem o OpenLDAP, Microsoft Active Directory, IBM Tivoli Directory Server, Oracle Internet Directory, entre outros.
O JBoss EAP 6 inclui diversos módulos de autorização e autenticação que permitem você usar um servidor LDAP como autoridade de autorização e autenticação para os seus aplicativos EJB e da Web.
Reportar um erro

10.12.2. Uso do LDAP para Autenticação das Interfaces de Gerenciamento

Para uso do servidor do diretório LDAP como fonte de autenticação para o Console de Gerenciamento, CLI de Gerenciamento ou API de Gerenciamento, você precisa executar os seguinte procedimentos:
  1. Criação de uma conexão outbound para o servidor LDAP.
  2. Crie um realm de segurança habilitado LDAP.
  3. Referencie o novo security domain na Interface de Gerenciamento.
Criação da Conexão Outbound a um Servidor LDAP

A conexão outbound LDAP permite os seguintes atributos:

Tabela 10.1. Atributos de uma Conexão Outbound LDAP

Função Solicitado Descrição
url sim
O endereço URL do servidor do diretório.
search-dn sim
O distinguished name (DN - nome distinguido) do usuário autorizado a executar as buscas.
search-credentials sim
A senha do usuário autorizado a executar as buscas.
initial-context-factory não
A criação do contexto inicial para uso quando estabelecendo a conexão. O default é com.sun.jndi.ldap.LdapCtxFactory.
security-realm não
O security realm de referência para obter um SSLContext configurado para uso quando estabelecendo a conexão.

Exemplo 10.13. Adição de uma Conexão Outbound LDAP

Esta amostra adiciona uma conexão outbound com o seguinte conjunto de propriedades:
  • DN de busca: cn=search,dc=acme,dc=com
  • Credencial de busca: myPass
  • URL: ldap://127.0.0.1:389
O primeiro comando adiciona o security realm. 
/host=master/core-service=management/security-realm=ldap_security_realm:add
O segundo comando adiciona a conexão LDAP. 
/host=master/core-service=management/ldap-connection=ldap_connection/:add(search-credential=myPass,url=ldap://127.0.0.1:389,search-dn="cn=search,dc=acme,dc=com")
Criação de um Realm de Segurança Habilitado LDAP

As Interfaces de Gerenciamento podem autenticar em relação ao servidor LDAP ao invés do arquivo de propriedade baseado nos realms de segurança configurados por default. O autenticador LDAP opera primeiramente estabelecendo uma conexão ao servidor do diretório remoto. Ele então executa uma busca usando o nome do usuário que o usuário passou ao sistema de autenticação, com o objetivo de encontrar o distinguished name (DN - nome distinguido) inteiramente qualificado. Uma nova conexão é estabelecida usando o DN do usuário como credencial e senha suprida pelo usuário. Caso esta autenticação ao servidor LDAP for bem sucedida, o DN é confirmado como válido.

O realm de segurança LDAP precisa dos seguintes atributos de configuração e elementos com o objetivo de executar suas funções.
conexão
O nome da conexão definido no <outbound-connections> para uso da conexão ao diretório LDAP.
base-dn
O nome distinguido do contexto para iniciar a busca pelo usuário.
recursivo
Se é que a busca deve ser recursiva através da árvore do diretório LDAP ou apenas buscar o contexto especificado. O default é false.
user-dn
O atributo do usuário que mantém o nome distinguido. Isto é subsequentemente usado para testar a autenticação assim que usuário puder completar. O default é dn.
Um dos username-filter ou advanced-filter como um elemento filho
O username-filter leva um atributo único chamado attribute, cujo valor é o nome do atributo LDAP que mantém o nome do usuário, tal como o userName ou sambaAccountName.
O advanced-filter leva um único atributo chamado filter. Este atributo contém uma fila de filtro na sintaxe do LDAP default. Recomendamos cuidado ao sair de qualquer caractere & alterando-os pelo &amp;. Segue abaixo uma amostra de um filtro: 
(&(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))
Após sair do caractere ampersand, o filtro aparece como: 
(&amp;(sAMAccountName={0})(memberOf=cn=admin,cn=users,dc=acme,dc=com))

Exemplo 10.14. Representação XML de um Realm de Segurança habilitado LDAP

Essa amostra usa os seguintes parâmetros:
  • connection - ldap_connection
  • base-dn - cn=users,dc=acme,dc=com.
  • username-filter - attribute="sambaAccountName" 
<security-realm name="ldap_security_realm">
   <authentication>
      <ldap connection="ldap_connection" base-dn="cn=users,dc=acme,dc=com">
         <username-filter attribute="sambaAccountName" />
      </ldap>
  </authentication>
</security-realm>

Atenção

É importante certificar-se de que você não permita as senhas LDAP vazias (a não ser que você as deseje especificamente no seu ambiente, uma vez que elas implicam em sérios critérios de segurança).
O EAP 6.1 inclui um caminho para o CVE-2012-5629, que determina a opção allowEmptyPasswords para os módulos de login LDAP para falso, caso esta opção já não esteja configurada. Para as versões antigas, esta opção deve ser configurada manualmente.

Exemplo 10.15. Adição de um Realm de Segurança LDAP

O comando adiciona o realm de segurança e determina seus atributos para o servidor autônomo. 
/host=master/core-service=management/security-realm=ldap_security_realm/authentication=ldap:add(base-dn="DC=mycompany,DC=org", recursive=true, username-attribute="MyAccountName", connection="ldap_connection")
Aplicação do Novo Realm de Segurança à Interface de Gerenciamento

Após você criar um realm de segurança, você precisa referenciá-lo na configuração de sua interface de gerenciamento. A interface de gerenciamento usará o realm de segurança para a autenticação de resumo HTTP.

Exemplo 10.16. Aplicação do Realm de Segurança à Interface HTTP

Após esta configuração estiver pronta e você restaurar o controlador do host, o Console de Gerenciamento baseado na web usará o LDAP para autenticação de seus usuários. 
/host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ldap-security-realm)
Configuração de um Managed Domain Associado para Autenticação usando o Microsoft Active Directory

Com o objetivo de configurar um managed domain para autenticação ao Microsoft Active Directory, siga este procedimento, que cria um security domain e mapeia as funções aos grupos Active Directory usando a autenticação JAAS. Este procedimento Microsoft Active Directory permite o binding com uma senha vazia. Este procedimento previne que uma senha vazia seja usada com uma plataforma do aplicativo.

Antes de executar este procedimento, você precisa saber o nome de seu host controller. Esta amostra assume que o host controller é nomeado master.

  1. Adicione um <security-realm> nomeado ldap_security_realm e configure-o para uso do JAAS.

    Os seguintes comandos do CLI de Gerenciamento adicionam um novo realm de segurança e determinam o mecanismo de autenticação. Altere o nome do host conforme solicitado. 
    /host=master/core-service=management/security-realm=ldap_security_realm/:add
    /host=master/core-service=management/security-realm=ldap_security_realm/authentication=jaas/:add(name=managementLDAPDomain)

  2. Configuração do <http-interface> para uso do novo realm de segurança.

    O seguinte comando do CLI de Gerenciamento configura a interface HTTP. 
    /host=master/core-service=management/management-interface=http-interface/:write-attribute(name=security-realm,value=ldap_security_realm)

  3. Configuração do JBoss Enterprise Application Platform para adição da configuração JAAS personalizada aos seus parâmetros de inicialização.

    Edite o arquivo EAP_HOME/bin/domain.conf. Busque pela variával HOST_CONTROLLER_JAVA_OPTS. Isto é aonde você adiciona as diretivas para o JVM que são necessárias antes do JBoss Enterprise Application Platform iniciar. Segue abaixo uma amostra dos conteúdos default deste parâmetro: 
    HOST_CONTROLLER_JAVA_OPTS="$JAVA_OPTS"
    Adicione a seguinte diretiva à linha: -Djava.security.auth.login.config=/opt/jboss-eap-6.0/domain/configuration/jaas.conf"
    A linha editada é parecida ao seguinte: 
    -Djava.security.auth.login.config=/opt/jboss-eap-6.0/domain/configuration/jaas.conf"

  4. Adicione o módulo de login às opções do módulo.

    No mesmo arquivo, encontre a linha contendo o seguinte: 
    JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman"
    Altere a linha para leitura conforme abaixo. Certifique-se de não inserir quaisquer espaços extra. 
    JBOSS_MODULES_SYSTEM_PKGS="org.jboss.byteman,com.sun.security.auth.login"
    Salve e encerre o arquivo domain.conf.

  5. Crie a configuração JAAS que será adicionada ao classpath.

    Crie um novo arquivo na seguinte localização: EAP_HOME/domain/configuration/jaas.conf
    O arquivo deve conter os seguintes conteúdos. Edite os parâmetros para coincidirem com o seu ambiente. 
    managementLDAPDomain {
    org.jboss.security.auth.spi.LdapExtLoginModule required
        java.naming.factory.initial="com.sun.jndi.ldap.LdapCtxFactory"
        java.naming.provider.url="ldap://your_active_directory_host:389"
        java.naming.security.authentication="simple"
        bindDN="cn=Administrator,cn=users,dc=domain,dc=your_company,dc=com"
        bindCredential="password"
        baseCtxDN="cn=users,dc=domain,dc=redhat,dc=com"
        baseFilter="(&(sAMAccountName={0})(|(memberOf=cn=Domain Guests,cn=Users,dc=domain,dc=acme,dc=com)(memberOf=cn=Domain Admins,cn=Users,dc=domain,dc=acme,dc=com)))"
        allowEmptyPasswords="false"
        rolesCtxDN="cn=users,dc=domain,dc=acme,dc=com"
        roleFilter="(cn=no such group)"
        searchScope="SUBTREE_SCOPE";
};
  6. Reinicie o JBoss Enterprise Application Platform e sua interface HTTP usará o seu servidor LDAP para autenticação.
Reportar um erro

Capítulo 11. Segurança das Interfaces de Gerenciamento com o Controle de Acesso baseado na Função

11.1. Role-Based Access Control (RBAC - Controle de Acesso baseado na Função)

O Role-Based Access Control (RBAC) é um mecanismo de especificação de um conjunto de permissões para os usuários de gerenciamento. Ele permite que os usuários múltiplos compartilhem a responsabilidade de gerenciamento dos servidores do JBoss EAP 6.2, sem que cada um solicite acesso sem restrição. O JBoss EAP 6.2 facilita à organização a divisão de responsabilidade entre indivíduos e grupos em fornecer privilégios desnecessários, pelo fornecimento de "separação de tarefas" para gerenciamento de usuários. Isto garante a segurança máxima possível de seus servidores e dados enquanto fornecendo flexibilidade de configuração, implantação e gerenciamento.

O Role-Based Access Control no JBoss EAP 6.2 funciona através de uma combinação de permissões de funções e restrições.

Sete funções predefinidas são fornecidas, sendo que cada uma possui permissões fixas diferentes. As funções predefinidas são: Monitorar, Operador, Mantedor, Implantador, Auditor, Administrador e Super Usuário. Cada usuário de gerenciamento é determinado uma ou mais funções, sendo que a permissão do usuário do que realizar quando gerenciando o servidor é especificada por suas funções determinadas.
Reportar um erro

11.2. Controle de Acesso baseado na Função no GUI e CLI

Quando o Role-Based Access Control(RBAC) estiver ativado, alguns dos usuários não estarão aptos a executar certas operações, ler alguns recursos ou até mesmo estarem aptos a verem partes do modelo de gerenciamento, de acordo com as funções determinadas aos mesmos.
Console de Gerenciamento

No console de gerenciamento alguns controles e visualizações são desativados (acinzentados) ou não são visíveis dependendo das permissões de sua função determinada.

Caso você não tenha permissões de leitura a um atributo de recursos, este atributo aparecerá em branco no console. Por exemplo: a maioria das funções não pode ler os campos do nome de usuário e senha para as fontes de dados.

Caso você não possua permissões de gravação a um atributo do recurso, este recurso será desativado (acinzentado) na forma editar para o recurso. Caso você não possua permissões de gravação ao recurso, então o botão editar do recurso não irá aparecer.

Caso você não possua permissões de acesso ao recurso ou atributo (isto é "não endereçável" a sua função), então isto não aparecerá no console. Uma amostra disto é que o próprio sistema de controle de acesso, do qual é apenas visível a poucas funções por default.
API de Gerenciamento

Os usuários que usam a ferramenta jboss-cli.sh ou usam o API verão uma pequena diferença de comportamento no API quando o RBAC for habilitado.

Os recursos e atributos que não podem ser lidos, são filtrados dos resultados. Caso os itens filtrados forem endereçados pela função, os seus nomes serão listados como filtered-attributes na seção response-headers do resultado. Caso um recurso ou atributo não forem endereçados pela função, eles não são listados.

A tentativa de acessar um recurso que não é endereçável resultará num erro de "recurso não encontrado".

Caso um usuário tentar escrever ou ler um recurso que ele pode endereçar mas não possui as permissões apropriadas de gravação e leitura, um erro de "Permissão Negada" será retornado.
Reportar um erro

11.3. Esquemas de Autenticação Suportados

O Controle de Acesso baseado na Função funciona com os provedores de autenticação que estão incluídos no JBoss EAP 6.2. Os provedores de autenticação default são: username/password, client certificate e local user.
Nome do Usuário/Senha

Os usuários são autenticados usando uma combinação de nome do usuário e senha, que é verificada tanto no arquivo mgmt-users.properties ou no servidor LDAP.
Certificado do Cliente

Uso do Trust Store.
Usuário Local

O jboss-cli.sh autentica automaticamente como um Usuário Local caso o servidor que está sendo executado na mesma máquina. Por default, o Usuário Local é um membro do grupo SuperUser.
Independente de qual provedor esteja sendo usado, o JBoss EAP é responsável pela determinação de funções aos usuários. No entanto, quando autenticando com o arquivo mgmt-users.properties ou um servidor LDAP, aqueles sistemas podem fornecer informação do grupo do usuário. Esta informação pode ser usada pelo JBoss EAP para determinar funções aos usuários.
Reportar um erro

11.4. Funções Padrões

O JBoss EAP 6 fornece sete funções de usuários pré-definidas: Monitorador, Mantedor, Implantador, Auditor, Administrador e Super Usuário. Cada uma dessas funções possui um conjunto diferente de permissões e foram feitas para casos de uso específico. Cada função de Monitor, Operador, Mantedor, Administrador e Super Usuário constrói sobre a outra, sendo que cada uma possui mais permissões que a anterior. As funções de Auditor e Implantador são similares às funções de Monitorador e Mantedor respectivamente, porém possuem algumas permissões e restrições especiais.
Monitor

Os usuários da função Monitor possui poucas permissões e podem apenas ler a configuração atual e o estado do servidor. Esta função é direcionada aos usuários que precisam rastrear e relatar o desempenho do servidor.

Os monitores não podem modificar a configuração do servidor, muito menos acessar os dados confidenciais ou operações.
Operador

A função de Operador estende a função de Monitor pela adição da habilidade de modificar o estado do período de execução do servidor. Isto significa que os Operadores podem recarregar e desligar o servidor, assim como interromper e concluir os destinos JMS. A função do Operador é ideal para usuários responsáveis por hosts físicos e virtuais do servidor do aplicativo, de forma que eles podem certificar que os servidores podem ser desligados e reiniciados corretamente quando necessário.

Os operadores não podem modificar a configuração do servidor ou acessar os dados confidenciais ou operações.
Mantedor

A função do Mantedor possui acesso à visualização e modificação do estado do período de execução e todas as configurações com exceção das operações e dados confidenciais. A função do Mantedor é a função do propósito geral que não possui acesso aos dados confidenciais e à operação. A função do Mantedor permite que usuários tenham quase que acesso total ao administrador do servidor sem que os usuários acessem senhas e outras informações confidenciais.

Os Mantedores não podem acessar os dados confidenciais ou operações.
Administrador

A função do Administrador possui acesso sem restrição a todos os recursos e operações no servidor, com exceção do sistema de logging de auditoria. O Administrador é a única função (com exceção do Super Usuário) que possui acesso aos dados confidenciais e operações. Esta função pode ser também configurar o sistema do controle de acesso. A função de Administrador é apenas solicitada quando manuseando os dados confidenciais ou configurando usuários e funções.

Os administradores não podem acessar o sistema de logging de auditoria e não podem alterar a função de Auditor e Super Usuário.
Super Usuário

A função de Super Usuário não possui restrições e não possui acesso completo a todos os recursos e operações do servidor, incluindo o sistema de logging de auditoria. Esta função é equivalente aos usuários administrativos de versões anteriores do JBoss EAP 6 (6.0 e 6.1). Caso o RBAC for desativado, todos os usuários de gerenciamento possuíram permissões equivalentes à função de Super Usuário.
Implantador

A função de Implantador possui as mesmas permissões da função de Monitor, mas podem modificar a configuração e o estado para implantações e outros tipos de recursos como um recurso do aplicativo.
Auditor

A função de Auditor possui todas as permissões da função de Monitor e pode também visualizar (mas não modificar) os dados confidenciais, além de possuir acesso integral ao sistema de logging de auditoria. A função de Auditor é apenas a função de Super Usuário que pode acessar o sistema de logging de auditoria.

Os auditores não podem modificar os dados confidenciais ou recursos. Apenas o acesso de leitura é permitido.
Reportar um erro

11.5. Permissões de Função

O que cada função é permitida a realizar é definida por quais permissões isto possui. Nem toda função possui todas permissões. O Super Usuário possui todas as permissões e a função Monitor possui o número menor de permissões.
Cada permissão pode conceder acesso de leitura e/ou de gravação para uma categoria única de recursos.
As categorias são: estado do período de execução, configuração do servidor, dados confidenciais, log de auditoria e o sistema de controle de acesso.
A Tabela 11.1, “Permissões de Função Matriz” resume as permissões de cada função.

Tabela 11.1. Permissões de Função Matriz

Monitor

Operador

Mantedor

Implantador

Auditor

Administrador

Super Usuário

Configuração de Leitura e Estado

X

X

X

X

X

X

X

Ler Dados Confidenciais [2]

X

X

X

Modificar Dados Confidenciais [2]

X

X

Ler/Modificar Log de Auditoria

X

X

Modificar o Estado do Período de Execução

X

X

X[1]

X

X

Modificar a Configuração de Persistência

X

X[1]

X

X

Ler/Modificar o Controle de Acesso

X

X
[1] as permissões são restringidas aos recursos do aplicativo.
[2] Os recursos são considerados "dados confidenciais" são configurados usando as Restrições Confidenciais.
Reportar um erro

11.6. Restrições

As restrições são conjuntos nomeados da configuração de controle de acesso para uma lista especificada de recursos. O sistema RBAC usa uma combinação de restrições e permissões de função para determinar se qualquer usuário em específico pode desempenhar uma ação de gerenciamento.

As restrições são divididas em duas classificações: aplicativo e confiabilidade.
Restrições do Aplicativo

As Restrições de Aplicativo definem conjuntos de recursos e atributos que podem ser acessados por usuários da função Implantador. Por default, a única Restrição de Aplicativo é core que inclui implantações, sobreposições de implantações. As Restrições do Aplicativo são também incluídas (mas não são habilitadas por default= para fontes de dados, logging, correio, mensagem, nomeação, adaptadores de recurso e segurança. Essas restrições permitem que usuários Implantadores não apenas implantem aplicativos, mas também configurem e mantenham os recursos que são solicitados por aqueles aplicativos.

Uma configuração confidencial do aplicativo está no API de Gerenciamento no /core-service=management/access=authorization/constraint=application-classification.
Restrições Confidenciais

As Restrições Confidenciais definem conjuntos de recursos que são considerados "confidenciais". Um recurso confidencial é normalmente um que é tanto secreto, como uma senha ou um que terá impactos sérios na operação do servidor, como rede, configuração JVM ou propriedades de sistema. O próprio sistema de controle de acesso é considerado também confidencial.

As únicas funções permitidas a gravar recursos confidenciais são o Administrador e Super Usuário. A função de Auditor está apenas disponível para leitura de recursos confidenciais. Nenhuma outra função possui acesso.

A configuração de restrição confidencial está no API de Gerenciamento no /core-service=management/access=authorization/constraint=sensitivity-classification.
Restrição de Expressão Vault

A Expressão Vault define se a leitura ou gravação das expressões vault são consideradas uma operação confidencial. Por default, ambas expressões vault de leitura e gravação são uma operação confidencial.

A configuração de restrição da Expressão Vault está no API de Gerenciamento no /core-service=management/access=authorization/constraint=vault-expression.

As restrições não podem ser configuradas no Console de Gerenciamento neste momento.
Reportar um erro

11.7. JMX e Controle de Acesso Baseado na Função

O Controle de Acesso baseado na Função é aplicado ao JMX em três maneiras:

  1. O API de Gerenciamento do JBoss EAP 6 é exposto como JMX Management Beans. Esses Beans de Gerenciamento são referenciados como "core mbeans" e o acesso aos mesmos é controlado e filtrado exatamente da mesma maneira do próprio API de Gerenciamento subjacente.

  2. O subsistema JMX é configurado com permissões de gravação "confidenciais". Isto significa que apenas usuário com funções de Administrador de Super Usuário podem realizar alterações ao subsistema. Os usuários com função de Auditor também lêem.

  3. Por default, os Beans de Gerenciamento são registrados pelos aplicativos e serviços (beans que não são cores) sendo acessados por todos os usuários de gerenciamento, no entanto apenas os usuários com funções de Mantedor, Operador, Administrador, Super Usuário podem gravar nos mesmos.
Reportar um erro

11.8. Configuração do Controle de Acesso baseado na função

11.8.1. Visão Geral das Tarefas de Configuração RBAC

Quando o RBAC é habilitado apenas usuários com a função de Administração e Super Usuários podem visualizar e realizar modificações ao sistema de Controle de Acesso.
O Console de Gerenciamento fornece uma interface para as seguintes tarefas comuns do RBAC:
  • Visualização e configuração das funções determinadas (ou excluídas) a cada usuário
  • Visualização e configuração das funções determinadas (ou excluídas) de cada grupo
  • Visualização da associação de grupo e usuário por função.
  • Configuração da sociedade default por função.
  • Criação da função com escopo
O CLI fornece acesso para conclusão do sistema de controle de acesso. Isto significa que tudo o que pode ser realizado no console de gerenciamento pode ser realizado aqui, mas também um número adicional de tarefas pode ser executado com o CLI que não pode ser realizado com o sistema de controle de acesso.
As seguintes tarefas adicionais podem ser executadas no CLI:
  • Habilitação e Desabilitação do RBAC
  • Alteração da política de combinação de permissão
  • Configuração das Restrições de Confidencialidade do Recurso e Recurso do Aplicativo
Reportar um erro

11.8.2. Habilitação do Role-Based Access Control

O sistema Role-Based Access Control (RABC - Controle de Acesso baseado na Função) é desabilitado por default. Ele é habilitado pela alteração do atributo do provedor de simple para rbac. Isto pode ser realizado usando a ferramenta jboss-cli.sh ou pela edição do arquivo XML de configuração caso o servidor esteja desativado. Quando o RBAC é desabilitado ou habilitado num servidor em execução, a configuração do servidor deve ser recarregada antes de ser efetiva.
Uma vez habilitado, isto pode apenas ser desabilitado por um usuário de funções de Administrador ou Super Usuário. O jboss-cli.sh executa com a função de Super Usuário por default na mesma máquina do servidor.

Procedimento 11.1. Habilitação do RBAC

  • Para habilitar o RBAC com jboss-cli.sh use a operação write-attribute de recurso de autorização de acesso para determinar o atributo do provedor ao rbac. 
    /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
    [standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider, value=rbac)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
[standalone@localhost:9999 /] /:reload
{
    "outcome" => "success",
    "result" => undefined
}
[standalone@localhost:9999 /]

Procedimento 11.2. Desabilitação do RBAC

  • Para desabilitar o RBAC do jboss-cli.sh use a operação write-attribute de recurso de autorização de acesso para determinar o atributo do provedor ao simple. 
    /core-service=management/access=authorization:write-attribute(name=provider, value=simple)
    [standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=provider, value=simple)
{
    "outcome" => "success",
    "response-headers" => {
        "operation-requires-reload" => true,
        "process-state" => "reload-required"
    }
}
[standalone@localhost:9999 /] /:reload
{
    "outcome" => "success",
    "result" => undefined
}
[standalone@localhost:9999 /]
Caso o servidor estiver desativado, a configuração XML pode ser editada para habilitar ou desabilitar o RBAC. Para isto, edite o atributo provider do elemento de controle de acesso. Determine o valor para rbac para habilitar e simple para desabilitar. 
<management>

        <access-control provider="rbac">
            <role-mapping>
                <role name="SuperUser">
                    <include>
                        <user name="$local"/>
                    </include>
                </role>
            </role-mapping>
        </access-control>

    </management>
Reportar um erro

11.8.3. Alteração da Política de Combinação de Permissão

A Política da Combinação da Permissão determina como as permissões são determinadas caso um usuário é determinado mais de uma função. Isto pode ser determinado para permissive ou rejecting. O default é permissive.
Quando permissive, caso qualquer função for determinada ao usuário que permite uma ação, então a ação é permitida.
Quando determinado para rejecting, caso múltiplas funções forem determinadas a um usuário que permite uma ação, então a ação não é permitida.
Quando a política é determinada a rejeitar, cada usuário deve apenas ser determinado uma função. Os usuários com múltiplas funções não estarão aptos a usar o console de gerenciamento ou a ferramenta jboss-cli.sh quando a política é determinada para rejecting.
A Política de Combinação de Permissão é configurada pela configuração do atributo permission-combination-policy para tanto permissive ou rejecting. Isto pode ser determinado usando a ferramenta jboss-cli.sh ou pela edição do arquivo XML de configuração do servidor caso o servidor estiver desativado.

Procedimento 11.3. Determinação a Política de Combinação de Permissão

  • Use a operação write-attribute do recurso de autorização de acesso para determinar o atributo permission-combination-policy ao nome da política requerida. 
    /core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=POLICYNAME)
    Os nomes da política válidas estão rejeitando e permissivos. 
    [standalone@localhost:9999 /] /core-service=management/access=authorization:write-attribute(name=permission-combination-policy, value=rejecting)
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]
Caso o servidor estiver inoperante, a configuração XML pode ser editada para alterar o valor da política de combinação da permissão. Para isto, edite o atributo permission-combination-policy do elemento de controle de acesso. 
<access-control provider="rbac" permission-combination-policy="rejecting">
  <role-mapping>
    <role name="SuperUser">
      <include>
        <user name="$local"/>
      </include>
    </role>
  </role-mapping>
</access-control>
Reportar um erro

11.9. Gerenciando Funções

11.9.1. Membro da Função

Quando o Role-Based Access Control (RBAC - Controle do Acesso baseado pela função) for habilitado, você determina o que o usuário de gerenciamento é permitido a realizar pelas funções do usuário. O JBoss EAP 6.2 usa um sistema que inclui e exclui baseado em ambos usuário e membros do grupo para determinar qual função o usuário pertence.

Um usuário é considerado a estar determinado a uma função se:

  1. O usuário for:

    • listado como usuário a ser incluído na função, ou

    • um membro de um grupo que é listado a ser incluído na função.

  2. O usuário não está:

    • listado como um usuário para excluir a função, ou

    • um membro de um grupo que é listado a ser excluído da função.

As exclusões tem prioridade sobre as inclusões.

A função inclui e exclui configurações para usuários e grupos podem ser configurados usando ambos Console de Gerenciamento e a ferramenta jboss-cli.sh.

Apenas os usuários das funções Super Usuário ou Administrador podem executar esta configuração.
Reportar um erro

11.9.2. Configuração do Trabalho da Função do Grupo com o jboss-cli.sh

As funções de um usuário a serem incluídas e excluídas podem ser configuradas no Console de Gerenciamento e a ferramenta jboss-cli.sh. Este tópico apenas apresenta o uso do Gerenciamento do Console.
Apenas usuários com as funções de Super Usuário e Administrador podem executar esta configuração.

Estas funções podem ficar disponíveis seguindo estes passos:

  1. Efetue o login ao Console de Gerenciamento.

  2. Clique em Administrar

  3. Expanda o item do menu Server Configurations na parte esquerda do console e selecione o servidor relevante da lista.

  4. Selecione a tab USUÁRIOS.
Logon ao Console de Gerenciamento

Figura 11.1. Gerenciamento da Função do Usuário no Console de Gerenciamento

Procedimento 11.4. Criar uma Nova Função

  1. Realize o login ao console de gerenciamento.
  2. Navegue à tab dos Usuários da seção do Trabalho da Função.
  3. Clique no botão Adicionar no topo direito da página da lista de usuário. O diálogo Adicionar Usuários irá aparecer.
    Diálogo Adicionar e Remover

    Figura 11.2. Diálogo Adicionar e Remover

  4. Você deve especificar um nome de usuário.
  5. Selecione o menu de tipo para inclusão ou exclusão.
  6. Clique na opção das funções para inclusão ou exclusão. Você pode usar a tecla Control (tecla de Comando no OSX) para verificar os item múltiplos.
  7. Clique em salvar.
    Quando o procedimento ocorrer com êxito, o diálogo Adicionar Usuário encerrará e a lista de usuários será atualizada para que as alterações tenham efeito. Caso não haja êxito, uma mensagem "Falha ao salvar o trabalho da função" será exibida.

Procedimento 11.5. Criar uma Nova Função

  1. Realize o login ao console de gerenciamento.
  2. Navegue à tab dos Usuários da seção do Trabalho da Função.
  3. Selecione o contato da sua lista de contatos.
  4. Clique aqui para editar o Método
    Filtrar caixa de seleção na Visualização do Filtro

    Figura 11.3. Filtrar caixa de seleção na Visualização do Filtro

    Aqui você pode adicionar e remover funções determinadas e excluídas do usuário.

    1. Selecione uma função onde você deseja atribuir um grupo de LDAP de ou para uma lista de funções existentes.

    2. Selecione uma função onde você deseja atribuir um grupo de LDAP de ou para uma lista de funções existentes.

    3. Selecione uma função onde você deseja atribuir um grupo de LDAP de ou para uma lista de funções existentes.

    4. Com o objetivo de excluir uma função, selecione a função solicitada da lista das funções excluídas no canto direito e clique no botão com a flecha indicando para a esquerda, próxima à lista de funções excluídas.
  5. Clique em salvar.
    Quando houver êxito, a visualização editar encerra e a lista de usuários é atualizada para refletir as alterações realizadas. Caso não ocorra êxito, uma mensagem "Falha ao salvar o trabalho da função" será exibida.

Procedimento 11.6. Remover o trabalho da função para o usuário

  1. Realize o login ao console de gerenciamento.
  2. Navegue à tab dos Usuários da seção do Trabalho da Função.
  3. Selecione um usuário da lista.
  4. Clique no botão Remover. A confirmação da Remoção do Trabalho da Função irá aparecer.
  5. Clique no botão Confirmar.
    Quando o procedimento ocorrer com êxito, o usuário não irá mais aparecer na lista de trabalhos da função do usuário.

Importante

A remoção do usuário da lista de trabalhos da função não remove o usuário do sistema e também não garante que as funções serão determinadas ao usuário. As funções podem continuar a serem determinadas a partir da associação do grupo.
Reportar um erro

11.9.3. Configuração da Determinação da Função do Usuário com o jboss-cli.sh

Funções do usuário a serem incluídas ou excluídas podem ser configuradas num Console de Gerenciamento e a ferramenta jboss-cli.sh. Este tópico apresenta apenas o uso da ferramenta jboss-cli.sh.
A configuração de grupos e usuários de mapeamento às funções está localizada no API de gerenciamento no: /core-service=management/access=authorization como elementos role-mapping.
Apenas os usuários das funções Super Usuário ou Administrador podem executar esta configuração.

Procedimento 11.7. Visualização da Configuração da Determinação da Função do Grupo

  1. Use a operação read-children-names para obter uma lista das funções configuradas: 
    /core-service=management/access=authorization:read-children-names(child-type=role-mapping)
    [standalone@localhost:9999 access=authorization] :read-children-names(child-type=role-mapping)
{
    "outcome" => "success",
    "result" => [
        "ADMINISTRATOR",
        "DEPLOYER",
        "MAINTAINER",
        "MONITOR",
        "OPERATOR",
        "SuperUser"
    ]
}
  2. Use a operação read-resource de um role-mapping especificado para obter detalhes completos de uma função específica: 
    /core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
    [standalone@localhost:9999 access=authorization] ./role-mapping=ADMINISTRATOR:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "include-all" => false,
        "exclude" => undefined,
        "include" => {
            "user-theboss" => {
                "name" => "theboss",
                "realm" => undefined,
                "type" => "USER"
            },
            "user-harold" => {
                "name" => "harold",
                "realm" => undefined,
                "type" => "USER"
            },
            "group-SysOps" => {
                "name" => "SysOps",
                "realm" => undefined,
                "type" => "GROUP"
            }
        }
    }
}
[standalone@localhost:9999 access=authorization]

Procedimento 11.8. Adição de uma nova função

Este procedimento apresenta como adicionar uma entrada role-mapping para a função. Isto deve ser feito antes da função poder ser configurada.
  • Use a operação add para adicionar uma nova configuração da função. 
    /core-service=management/access=authorization/role-mapping=ROLENAME:add
    O ROLENAME é o nome da função que o novo mapeamento é destinado. 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR:add             
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]

Procedimento 11.9. Adição de um usuário conforme incluído na função

Este procedimento apresenta como adicionar um usuário a ser incluído na lista de uma função.
Caso nenhuma configuração para a função for realizada, uma entrada role-mapping para isto deve ser realizada primeiramente.
  • Use a operação add para adicionar a entrada do usuário para lista de inclusão da função. 
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=USERNAME, type=USER)
    O ROLENAME é o nome da função a ser configurado.
    O ALIAS é um nome único para este mapeamento. A Red Hat recomenda que você use a convenção de nomeação para seus aliases tais como user-USERNAME.
    O USERNAME é o nome do usuário sendo adicionado à lista de inclusão. 
     [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=user-max:add(name=max, type=USER)
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]

Procedimento 11.10. Adição de um usuário conforme excluído na função

Este procedimento apresenta como adicionar um usuário a ser excluído na lista de uma função.
Caso nenhuma configuração para a função for realizada, uma entrada role-mapping para isto deve ser realizada primeiramente.
  • Use a operação add para adicionar a entrada do usuário para lista de exclusão da função. 
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=USERNAME, type=USER)
    O ROLENAME é o nome da função a ser configurado.
    O USERNAME é o nome do usuário sendo adicionado à lista de exclusão.
    O ALIAS é um nome único para este mapeamento. A Red Hat recomenda que você use a convenção de nomeação para seus aliases tais como user-USERNAME. 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=user-max:add(name=max, type=USER)
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]

Procedimento 11.11. Remoção da configuração de inclusão da função do usuário

Este procedimento apresenta como remover a entrada de inclusão de um usuário a partir do mapeamento da função.
  • Use a operação remove para remover a entrada. 
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
    O ROLENAME é o nome da função sendo configurada.
    O ALIAS é um nome único para este mapeamento. A Red Hat recomenda que você use a convenção de nomeação para seus aliases tais como user-USERNAME. 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=user-max:remove
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]
    A remoção do usuário a partir da lista de inclusões não remove o usuário do sistema e não garante que a função não será determinada ao usuário. A função pode ser determinada baseada na associação do grupo.

Procedimento 11.12. Remoção da configuração de exclusão da função do usuário

Este procedimento apresenta como remover um usuário de exclusão de um mapeamento de função.
  • Use a operação remove para remover a entrada. 
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
    O ROLENAME é o nome da função a ser configurado.
    O ALIAS é um nome único para este mapeamento. A Red Hat recomenda que você use a convenção de nomeação para seus aliases tais como user-USERNAME. 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=user-max:remove
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]
    A remoção do usuário a partir da lista de exclusões não remove o usuário do sistema e não garante que a função será determinada ao usuário. A função pode ser excluída baseada na associação do grupo.
Reportar um erro

11.9.4. Funções e Grupos de Usuários

Os usuários autenticados usando tanto o arquivo mgmt-users.properties ou um servidor LDAP podem ser membros dos grupos do usuário. Um grupo de usuário é um rótulo arbitrário que pode ser determinado a um ou mais usuários.
O sistema RBAC pode ser configurado automaticamente à determinar funções aos usuários dependendo de quais grupos eles pertencem. Ele pode excluir também usuários de funções baseadas na associação do grupo.
Quando usando um grupo mgmt-users.properties, a informação do grupo é stored no arquivo mgmt-groups.properties. Quando usando o LDAP, a informação do grupo é stored no servidor LDAP e mantida pelo servidor LDAP.
Reportar um erro

11.9.5. Configuração da Determinação da Função do Grupo

As funções podem ser determinadas a um usuário baseado na associação do usuário de um grupo de usuário.
Os grupos a serem incluídos ou excluídos da função podem ser configurados num Console de Gerenciamento e a ferramenta jboss-cli.sh. Este tópico apresenta apenas o uso do Console de Gerenciamento.
Apenas usuários nas funções Super Usuário ou Administrador podem executar esta configuração.
Estas funções de Grupo podem ficar disponíveis seguindo estes passos:
  1. Efetue o Login ao Console de Gerenciamento.
  2. Clique na tab Administração.
  3. Expanda o item do Controle de Acesso no canto esquerdo e selecione o Trabalho da Função.
  4. Selecione a tab GRUPOS.
Captura da Tela do Gerenciamento da Função do Grupo no Console de Gerenciamento

Figura 11.4. Gerenciamento da Função do Grupo no Console de Gerenciamento

Procedimento 11.13. Crie uma novo trabalho à função para um grupo

  1. Realize o login ao console de Gerenciamento
  2. Navegue à tab GRUPOS da seção do Trabalho de Função.
  3. Clique no botão Adicionar no canto direito superior da lista de usuários. O diálogo Adicionar Grupo irá aparecer.
    Screenshot do diálogo Adicionar Grupo

    Figura 11.5. Diálogo Adicionar Grupo

  4. Especifique o nome do grupo e opcionalmente o realm.
  5. Determine o tipo de menu de inclusão ou exclusão.
  6. Clique nas opções das funções para inclusão ou exclusão. Você pode usar a tecla Control (Tecla de Comando no OSX) para verificar itens múltiplos.
  7. Clique em salvar.
    Quando concluído com êxito, o diálogo Adicionar Grupo encerrará e a lista de grupos é atualizada para que as mudanças realizadas sejam refletidas. Caso a não ocorra êxito, uma mensagem "Falha ao salvar o trabalho da função" será exibida.

Procedimento 11.14. Atualize o trabalho da função para um grupo

  1. Realize o login ao console de gerenciamento.
  2. Navegue à tab GRUPOS da seção do Trabalho de Função.
  3. Selecione o grupo da lista.
  4. Clique em editar. A visualização da seleção insere o modo Editar.
    Screenshot da Visualização da Seleção no Modo Editar

    Figura 11.6. Selecione o Modo Editar de Visualização

    Aqui você pode adicionar e remover funções excluídas e determinadas a partir de um grupo:
    • Selecione uma função onde você deseja atribuir um grupo de LDAP de ou para uma lista de funções existentes.
    • Selecione uma função onde você deseja atribuir um grupo de LDAP de ou para uma lista de funções existentes.
    • Com o objetivo de excluir uma função, selecione a função solicitada a partir da lista de funções disponíveis no canto esquerdo e clique no botão com de flecha indicando o lado direito para a lista de funções excluídas.
    • Com o objetivo de excluir uma função, selecione a função solicitada a partir da lista das funções excluídas no canto direito e clique no botão com uma flecha indicando o lado esquerdo próxima à lista de funções excluídas. A função muda da lista excluída à lista disponível.
  5. Clique em salvar.
    Quando houver êxito, a visualização editar encerra e a lista de grupos é atualizada para refletir as alterações realizadas. Caso não ocorra êxito, uma mensagem "Falha ao salvar o trabalho da função" será exibida.

Procedimento 11.15. Remova o trabalho da função para um grupo.

  1. Realize o login ao console de gerenciamento.
  2. Navegue à tab GRUPOS da seção do Trabalho de Função.
  3. Selecione o grupo da lista.
  4. Clique no botão Remover. A confirmação da Remoção do Trabalho da Função irá aparecer.
  5. Clique no botão confirmar.
    Quando com êxito, a função não irá mais aparecer na lista dos trabalhos da função do usuário
    A remoção do grupo da lista dos trabalhos de função não remove o grupo de usuários do sistema, nem garante que nenhuma função será determinada aos membros daquele grupo. Cada membro do grupo pode ter uma função determinada diretamente.
Reportar um erro

11.9.6. Configuração da Determinação da Função do Grupo com jboss-cli.sh

Os grupos a serem incluídos ou excluídos da função podem ser configurados num Console de Gerenciamento e a ferramenta jboss-cli.sh. Este tópico apresenta apenas o uso da ferramenta jboss-cli.sh.
A configuração de grupos e usuários de mapeamento às funções está localizada no API de gerenciamento no: /core-service=management/access=authorization como elementos role-mapping.
Apenas usuários com funções de Administrador ou Super Usuários podem executar esta configuração.

Procedimento 11.16. Visualização da Configuração da Determinação da Função do Grupo

  1. Use a operação read-children-names para obter uma lista das funções configuradas: 
    /core-service=management/access=authorization:read-children-names(child-type=role-mapping)
    [standalone@localhost:9999 access=authorization] :read-children-names(child-type=role-mapping)
{
    "outcome" => "success",
    "result" => [
        "ADMINISTRATOR",
        "DEPLOYER",
        "MAINTAINER",
        "MONITOR",
        "OPERATOR",
        "SuperUser"
    ]
}
  2. Use a operação read-resource de um role-mapping especificado para obter detalhes completos de uma função específica: 
    /core-service=management/access=authorization/role-mapping=ROLENAME:read-resource(recursive=true)
    [standalone@localhost:9999 access=authorization] ./role-mapping=ADMINISTRATOR:read-resource(recursive=true)
{
    "outcome" => "success",
    "result" => {
        "include-all" => false,
        "exclude" => undefined,
        "include" => {
            "user-theboss" => {
                "name" => "theboss",
                "realm" => undefined,
                "type" => "USER"
            },
            "user-harold" => {
                "name" => "harold",
                "realm" => undefined,
                "type" => "USER"
            },
            "group-SysOps" => {
                "name" => "SysOps",
                "realm" => undefined,
                "type" => "GROUP"
            }
        }
    }
}
[standalone@localhost:9999 access=authorization]

Procedimento 11.17. Adição de uma nova função

Este procedimento apresenta como adicionar uma entrada role-mapping para a função. Isto deve ser feito antes da função poder ser configurada.
  • Use a operação add para adicionar uma nova configuração da função. 
    /core-service=management/access=authorization/role-mapping=ROLENAME:add
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR:add             
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]

Procedimento 11.18. Adição de um Grupo conforme incluído na função

Este procedimento apresenta como adicionar um Grupo a ser incluído na lista de uma função.
Caso nenhuma configuração para a função for realizada, uma entrada role-mapping para isto deve ser realizada primeiramente.
  • Use a operação add para adicionar a entrada do Grupo para incluir uma lista da função. 
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:add(name=GROUPNAME, type=GROUP)
    O ROLENAME é o nome da função a ser configurado.
    O GROUPNAME é o nome do grupo sendo adicionado à lista de inclusão.
    O ALIAS é um nome único para este mapeamento. A Red Hat recomenda que você use a convenção de nomeação para seus aliases tais como group-GROUPNAME. 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=group-investigators:add(name=investigators, type=GROUP)
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]

Procedimento 11.19. Adição de um grupo como excluído à função

Este procedimento apresenta como adicionar um grupo à lista excluída de uma função.
Caso nenhuma configuração para a função tenha sido realizada, a entrada do role-mapping deve ser criada primeiramente.
  • Use a operação add para adicionar a entrada do grupo que exclui a lista da função. 
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:add(name=GROUPNAME, type=GROUP)
    O ROLENAME é o nome da função sendo configurada.
    O GROUPNAME é o nome do grupo sendo adicionado à lista de inclusão
    O ALIAS é um nome único para este mapeamento. A Red Hat recomenda que você use a convenção de nomeação para seus aliases tais como group-GROUPNAME. 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=group-supervisors:add(name=supervisors, type=USER)
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]

Procedimento 11.20. Remoção da configuração de inclusão da função do grupo

Este procedimento apresenta como remover a entrada de inclusão de um grupo a partir do mapeamento da função.
  • Use a operação remove para remover a entrada. 
    /core-service=management/access=authorization/role-mapping=ROLENAME/include=ALIAS:remove
    O ROLENAME é o nome da função sendo configurada.
    O ALIAS é um nome único para este mapeamento. A Red Hat recomenda que você use a convenção de nomeação para seus aliases tais como group-GROUPNAME. 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/include=group-investigators:remove
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]
    A remoção do grupo a partir da lista de inclusões não remove o grupo do sistema e não garante que a função não será determinada aos usuários deste grupo. A função pode ser determinada aos usuários no grupo individualmente.

Procedimento 11.21. Remoção de uma entrada de exclusão do grupo de usuário

Este procedimento apresenta como remover uma entrada de exclusão de grupo a partir de um mapeamento da função.
  • Use a operação remove para remover a entrada. 
    /core-service=management/access=authorization/role-mapping=ROLENAME/exclude=ALIAS:remove
    O ROLENAME é o nome da função a ser configurado.
    O ALIAS é um nome único para este mapeamento. A Red Hat recomenda que você use a convenção de nomeação para seus aliases tais como group-GROUPNAME. 
    [standalone@localhost:9999 access=authorization] ./role-mapping=AUDITOR/exclude=group-supervisors:remove
{"outcome" => "success"}
[standalone@localhost:9999 access=authorization]
    A remoção do grupo da lista de exclusões não remove o grupo do sistema. Além disso, isto não garante que a função será determinada aos membros do grupo. As funções podem ser excluídas baseadas na associação do grupo.
Reportar um erro

11.9.7. Autorização e Carregamento de Grupo com o LDAP

Espera-se que existam entradas para contas de usuários com o diretório LDAP e que existam entradas para grupos, que são então multi referenciados pelo uso dos atributos. Os atributos usados para a referenciação múltipla entre os dois pode ser uma referência da conta do usuário sobre a entrada do grupo ou um atributo na referenciação do grupo dos usuários, dos quais são membros do grupo. Em alguns servidores, ambas as formas de multi referência existem.

É comum também que um usuário seja autenticado em relação ao servidor usando um nome de usuário simples, quando acontece uma busca pela informação dos membros do grupo, dependendo do servidor do diretório em uso, as buscas podem ser executadas usando um nome simples ou podem ser executadas usando o nome distinto que os usuários inserem no diretório.

A etapa de autenticação de um usuário conectando ao servidor sempre acontece primeiro e, apenas quando isto decide que o usuário foi autenticado com sucesso, o servidor inicia o carregamento dos grupos de usuários. Uma vez que as etapas de autenticação e autorização usam uma conexão ao servidor LDAP, o realm contém uma otimização que qualquer conexão usada para autenticação será reusada para a etapa de carregamento de grupo. Conforme será apresentado com as etapas de configuração abaixo, é possível definir as regras com a seção da autorização para converter o nome do usuário de usuários simples para seus nomes distintos. Isto é, duplicando intensamente uma busca que ocorreria durante a etapa de autenticação, portanto caso um nome de usuário para a busca de nome distinto já tenha sido executada, o resultado daquela busca sofre o cache sem solicitar uma repetição. 
<authorization>
    <ldap connection="...">
       <username-to-dn> <!-- OPTIONAL -->
           <!-- Only one of the following. -->
           <username-is-dn />
           <username-filter base-dn="..." recursive="..." user-dn-attribute="..." attribute="..." />
           <advanced-filter base-dn="..." recursive="..." user-dn-attribute="..." filter="..." />
        </username-to-dn>
       <group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." >
           <!-- One of the following -->
           <group-to-principal base-dn="..." recursive="..." search-by="...">
               <membership-filter principal-attribute="..." />
           </group-to-principal>
           <principal-to-group group-attribute="..." />
       </group-search>
    </ldap>
</authorization>

Importante

Algumas destas amostras especificam que atributos estão usando os valores default. Elas são demonstradas para maior clareza. Os atributos que contém os valores default são removidos da configuração quando ela é persistida pelo servidor.

username-to-dn

Conforme mencionado acima, às vezes será necessário definir a configuração da autorização como mapear a partir do nome de usuário fornecido pelo usuário sendo autenticado ao nome distinto de sua entrada no diretório LDAP. O elemento username-to-dn é como isto é definido, este elemento é apenas requerido caso ambos abaixo forem verdadeiros:

  • A etapa de autenticação não ocorreu em relação ao LDAP.

  • A busca em grupo está usando nome distinto durante a busca.

Tente e mantenha o primeiro ponto de marcação em mente, quando você ler as amostras abaixo você perceberá que a configuração da autenticação está sendo duplicada (e na realidade ela está duplicada). Caso esteja apenas usando o LDAP para autenticação, este procedimento não é necessário uma vez que o nome distinto será obtido durante a autenticação.
1:1 username-to-dn

Está é a forma mais básica de configuração e é usada para especificar que o nome do usuário inserido pelo usuário remoto é na realidade nome distinto de usuários. 
<username-to-dn>
   <username-is-dn />
</username-to-dn>

Uma vez que isto está definindo um mapeamento 1:1, não há configuração adicional possível.
username-filter

A próxima opção é bastante parecida à opção simples descrita acima para a etapa de autenticação. É necessário apenas que um atributo especificado seja pesquisado pela combinação do nome do usuário fornecido. 
<username-to-dn>
    <username-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" attribute="sn" user-dn-attribute="dn" />
</username-to-dn>

Os atributos que podem ser configurados:

  • base-dn: O nome distinto do contexto para início da busca.

  • recursive: Se é que a busca será estendida aos sub contextos. O default é false.

  • attribute: O atributo da entrada dos usuários para tentar e combinar em relação ao nome do usuário fornecido. O default é uid.

  • user-dn-attribute: O atributo de leitura para obter nome distinto de usuários. O default é dn.
advanced-filter

A opção final é especificar um filtro avançado, assim como na seção de autenticação, esta é uma oportunidade de uso de um filtro personalizado para localizar o nome distinto de usuários. 
<username-to-dn>
    <advanced-filter base-dn="dc=people,dc=harold,dc=example,dc=com" recursive="false" filter="sAMAccountName={0}" user-dn-attribute="dn" />
</username-to-dn>

Para atributos que coincidem com aqueles no username-filter, o significado e os valores default são os mesmos de forma que você não precisará listá-los novamente. Isto leva a um novo atributo:

  • filter: O filtro personalizado usado para buscar por usuários quando o nome do usuário será substituído no place holder {0}.

Importante

O XML deve permanecer válido após o filtro ser definido de forma que quaisquer caracteres especiais são usados como & garantindo que uma forma apropriada seja usada. Por exemplo, &amp; para o caratere &.

Busca do Grupo

Conforme descrito acima, existem dois estilos diferentes que podem ser usados quando buscando para a informação do membro do grupo. O primeiro estilo é onde a entrada do usuário contém um atributo que referência os grupos do usuário que ele pertence. O segundo estilo onde o grupo é o que contém um atributo referenciado a entrada dos usuários.

Onde existe uma escolha do estilo para uso, a Red Hat recomenda que a configuração para a entrada do usuário referenciando o grupo seja usada. Isto é devido à informação do grupo do método pode ser carregada pelos atributos de leitura de nomes distintos conhecidos sem a necessidade de quaisquer buscas. As demais abordagens requerem buscas para identificar os grupos que referenciam o usuário.

Antes de descrever a configuração, por favor observe duas amostras LDIF para ilustração.

Exemplo 11.1. Principal ao Grupo - amostra LDIF.

Esta amostra ilustra onde nós temos um usuário TestUserOne que é um membro do GroupOne. O GroupOne é, então, em retorno um membro do GroupFive. A afiliação do grupo é apresentada pelo uso de um atributo memberOf que é configurado ao nome distinto do grupo que o usuário (ou grupo) pertence.

Embora não seja demonstrado aqui, um usuário poderia ter potencialmente um conjunto de atributos memberOf, um para cada grupo que o usuário pertence. 
dn: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
objectClass: extensibleObject
objectClass: top
objectClass: groupMember
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: person
objectClass: organizationalPerson
cn: Test User One
sn: Test User One
uid: TestUserOne
distinguishedName: uid=TestUserOne,ou=users,dc=principal-to-group,dc=example,dc=org
memberOf: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
memberOf: uid=Slashy/Group,ou=groups,dc=principal-to-group,dc=example,dc=org
userPassword:: e1NTSEF9WFpURzhLVjc4WVZBQUJNbEI3Ym96UVAva0RTNlFNWUpLOTdTMUE9PQ==

dn: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
objectClass: extensibleObject
objectClass: top
objectClass: groupMember
objectClass: group
objectClass: uidObject
uid: GroupOne
distinguishedName: uid=GroupOne,ou=groups,dc=principal-to-group,dc=example,dc=org
memberOf: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org

dn: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org
objectClass: extensibleObject
objectClass: top
objectClass: groupMember
objectClass: group
objectClass: uidObject
uid: GroupFive
distinguishedName: uid=GroupFive,ou=subgroups,ou=groups,dc=principal-to-group,dc=example,dc=org

Exemplo 11.2. Grupo ao Principal - Amostra LDIF

Esta amostra apresenta o mesmo usuário TestUserOne que é um membro do GroupOne que é em troca um membro do GroupFive. No entanto, neste caso isto é um atributo uniqueMember a partir do grupo do usuário sendo usado para a referência múltipla.

O atributo usado pela referência múltipla do membro do grupo pode ser repetido. Quando observando o GroupFive, existe também uma referência a outro membro TestUserFive que não é apresentada aqui. 
dn: uid=TestUserOne,ou=users,dc=group-to-principal,dc=example,dc=org
objectClass: top
objectClass: inetOrgPerson
objectClass: uidObject
objectClass: person
objectClass: organizationalPerson
cn: Test User One
sn: Test User One
uid: TestUserOne
userPassword:: e1NTSEF9SjR0OTRDR1ltaHc1VVZQOEJvbXhUYjl1dkFVd1lQTmRLSEdzaWc9PQ==

dn: uid=GroupOne,ou=groups,dc=group-to-principal,dc=example,dc=org
objectClass: top
objectClass: groupOfUniqueNames
objectClass: uidObject
cn: Group One
uid: GroupOne
uniqueMember: uid=TestUserOne,ou=users,dc=group-to-principal,dc=example,dc=org

dn: uid=GroupFive,ou=subgroups,ou=groups,dc=group-to-principal,dc=example,dc=org
objectClass: top
objectClass: groupOfUniqueNames
objectClass: uidObject
cn: Group Five
uid: GroupFive
uniqueMember: uid=TestUserFive,ou=users,dc=group-to-principal,dc=example,dc=org
uniqueMember: uid=GroupOne,ou=groups,dc=group-to-principal,dc=example,dc=org

Busca Geral de Grupo

Antes de observar as amostras para as duas abordagens, nós precisamos primeiro definir os atributos comuns entre eles. 
<group-search group-name="..." iterative="..." group-dn-attribute="..." group-name-attribute="..." >
    ...
</group-search>

  • group-name: Este atributo é usado para especificar a forma de uso pelo nome de grupo retornado uma vez que a lista de grupos do usuário é um membro. Isto pode ser simplesmente pelo nome do usuário ou nome distinto de grupos, caso o nome distinto solicitar seja solicitado, este atributo pode ser configurado para DISTINGUISHED_NAME. O default é SIMPLE.

  • iterative: Este atributo é usado para indicar se após a identificação de grupos que o usuário pertence, nós devemos também buscar iterativamente baseando-se em grupos para identificar quais grupos dos grupos um membro pertence. Caso a busca iterativa for habilitada, nós damos continuidade até alcançarmos um grupo que não é membro, caso quaisquer outros grupos ou um ciclo seja detectado. O default é false.

A afiliação do grupo cíclico não é um problema. Um registro de cada busca é mantido para prevenir que os grupos que já tiveram buscas realizadas, novamente sejam procurados.

Importante

Com o objetivo de que a busca iterativa funcione, as entradas do grupo precisam parecer as mesmas às entradas do usuário, sendo que a mesma abordagem usada para identificar os grupos que um usuário pertence é usada para identificar os grupos que o grupo pertence. Isto não seria possível quando falando do grupo para o membro do grupo e o nome do atributo usado para referência múltipla alterar ou caso a direção da referência alterar.

  • group-dn-attribute: Numa entrada a um grupo que o atributo encontra-se para um nome distinto. O default é dn.

  • group-name-attribute: Numa entrada a um grupo que o atributo encontra-se for um nome simples. O default é uid.

Exemplo 11.3. Principal à Configuração da Amostra do Grupo

Baseada na amostra LDIF, segue abaixo uma configuração de amostra iterativamente carregando grupos de usuários onde o atributo usado para referência múltipla é o atributo memberOf do usuário. 
<authorization>
    <ldap connection="LocalLdap">
        <username-to-dn>
            <username-filter base-dn="ou=users,dc=principal-to-group,dc=example,dc=org" recursive="false" attribute="uid" user-dn-attribute="dn" />
        </username-to-dn>
        <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid">
            <principal-to-group group-attribute="memberOf" />
        </group-search>
    </ldap>
</authorization>

O aspecto mais importante desta configuração é que o elemento principal-to-group já foi adicionado com um atributo único.

  • group-attribute: O nome do atributo na entrada do usuário que coincide com o nome distinto que o grupo do usuário pertence. O default é memberOf.

Exemplo 11.4. Grupo à Configuração da Amostra Principal

Esta amostra apresenta uma busca iterativa do grupo à amostra LDIF principal demonstrada acima. 
<authorization>
      <ldap connection="LocalLdap">
          <username-to-dn>
              <username-filter base-dn="ou=users,dc=group-to-principal,dc=example,dc=org" recursive="false" attribute="uid" user-dn-attribute="dn" />
          </username-to-dn>
          <group-search group-name="SIMPLE" iterative="true" group-dn-attribute="dn" group-name-attribute="uid">
              <group-to-principal base-dn="ou=groups,dc=group-to-principal,dc=example,dc=org" recursive="true" search-by="DISTINGUISHED_NAME">
                  <membership-filter principal-attribute="uniqueMember" />
              </group-to-principal>
          </group-search>
      </ldap>
  </authorization>

Este é um elemento group-to-principal adicionado. Este elemento é usado para definir como as buscas pelos grupos que referenciam a entrada do usuário serão desempenhadas. Os seguintes atributos são determinados:

  • base-dn: O nome distinto do contexto em uso para iniciar a busca.

  • recursive: Se é que os subcontextos também são pesquisados. O default é false.

  • search-by: A forma do nome de função usado nas buscas. Os válidos são SIMPLE e DISTINGUISHED_NAME. O default é DISTINGUISHED_NAME.

Junto ao elemento group-to-principal existe um elemento membership-filter para definir a referência múltipla.

  • principal-attribute: O nome do atributo na entrada do grupo que referência a entrada do usuário. O default é member.
Reportar um erro

11.9.8. Funções com Escopo

As Funções com Escopo são funções definidas do usuário que permitem as permissões de uma das funções padrões, mas apenas para um ou mais grupos de servidores específicos. As funções com escopo permitem que o gerenciamento de usuários sejam permissões concedidas que são limitadas apenas aos grupos do servidor ou hosts que são solicitados.

As funções com escopo podem ser criadas pelos usuários determinados funções de Administrador e Super Usuário.

Elas são definidas por 5 características:

  1. Um nome único.

  2. Quais das funções padrões isto está baseado.

  3. Caso seja aplicada aos Grupos do Servidor ou Hosts

  4. A lista dos grupos de servidor ou hosts que está restrita.

  5. Caso todos os usuários estiverem automaticamente incluídos. O default é falso.

Uma vez criada, uma função com escopo pode ser determinada aos usuários e grupos de mesma maneira que as funções default são.

A criação de uma função com escopo não permite que você defina novas permissões. As funções com escopo podem apenas serem usadas para a aplicação das permissões de uma função existente num escopo limitado. Por exemplo, você pode criar uma função com escopo baseada na função Implantador que é restrita a um grupo de servidor único.

Existem apenas dois escopos em que as funções podem ser limitadas, o grupo de servidor e host.
Funções com escopo host

A função com escopo host restringe as permissões daquela função a um ou mais hosts. Isto significa que o acesso é fornecido às árvores do recurso /host=*/ relevante, mas os recursos que são específicos aos demais hosts estão ocultos.
Funções do Grupo do Servidor com escopo

A função que é grupo do servidor com escopo restringe as permissões daquela função a um ou mais grupos. Além disso, as permissões da função será aplicada ao perfil, grupo binding de socket, configuração do servidor e recursos do servidor que estão associados com os grupos do servidor específico. Quaisquer sub-recursos com qualquer um daqueles que não estão logicamente relatados ao grupo do servidor, não serão visíveis aos usuários.

Ambas as funções com escopo do grupo do servidor possuem permissões da função do Monitor para o restante da configuração managed domain.
Reportar um erro

11.9.9. Criação de Funções com Escopo

As Funções com Escopo são funções user-defined que permitem as permissões de uma das funções default, mas apenas para um ou mais grupos de servidores específicos. Este tópico apresenta como criar funções com escopo.

Apenas usuários com funções de Super Usuário ou Administrador podem executar esta configuração.

A configuração da Função com Escopo pode ficar disponível seguindo as seguintes etapas:

  1. Realize o login ao Console de Gerenciamento

  2. Clique na tab Administração

  3. Expanda o item do Controle de Acesso no canto esquerdo e selecione Trabalho da Função

  4. Selecione a tab FUNÇÕES e a tab das Funções com Escopo.
Scoped Role Configuration in the Management Console

Figura 11.7. Configuração da Função com Escopo no Console de Gerenciamento

A seção das Funções com Escopo do Console de Gerenciamento consiste em duas áreas principais, uma tabela contendo uma lista de funções com escopo configuradas e um painel de Seleção que exibe a função atual selecionada na tabela.
Os seguintes procedimentos apresentam como executar as tarefas de execução para as Funções com Escopo.

Procedimento 11.22. Adição de uma Nova Função com Escopo

  1. Realize o login ao Console de Gerenciamento
  2. Navegue à área de Funções com Escopo da tab Funções.
  3. Clique no botão Adicionar. O diálogo Adição da Função com Escopo irá aparecer.
    Add Scoped Role Dialog

    Figura 11.8. Adição do Diálogo com a Função com Escopo

  4. Especifique os seguintes detalhes:

    • Name, o nome único para a nova função com escopo.

    • Base Role, a função que será baseada suas permissões.

    • Type, se é que a função será restringida aos hosts ou grupos do servidor.

    • Scope, a lista dos hosts ou grupos do servidor que a função é restringida. Entradas múltiplas podem ser selecionadas.

    • Include All, esta função inclui todos os usuários. O default é não.
  5. Clique no botão Salvar e o diálogo irá encerrar e a função recentemente criada aparecerá na tabela.

Procedimento 11.23. Edição da Função com Escopo

  1. Realize o login ao Console de Gerenciamento
  2. Navegue à área das Funções com Escopo da tab Funções.
  3. Clique na função com escopo que você deseja editar na tabela. Os detalhes daquela função aparecerá no painel de seleção abaixo da tabela.
    Role Selected

    Figura 11.9. Função selecionada

  4. Clique no link Editar no painel de Seleção. O painel de Seleção insere o modo editar.
    Selection Panel in Edit Mode

    Figura 11.10. Seleção do Painel no Modo Editar

  5. Atualize os detalhes que você precisa para a alteração e clique no botão salvar. O painel de Seleção retorna ao seu estado anterior. Ambos painel e tabela de Seleção apresentam os detalhes recentemente atualizados.

Procedimento 11.24. Visualização dos Membros da Função com Escopo

  1. Realize o login ao Console de Gerenciamento
  2. Navegue à área das Funções com Escopo da tab Funções.
  3. Clique na função com escopo na tabela que você deseja visualizar os Membros e clique no botão Membros. Os Membros do diálogo da função irão aparecer. Isto apresenta os usuários e os grupos que são incluídos e excluídos a partir da função.
    Role Membership Dialog

    Figura 11.11. Diálogo da Associação da Função

  4. Clique no botão Concluído quando você tiver realizado a revisão desta informação.

Procedimento 11.25. Exclua a Função com Escopo

Importante

A Função com Escopo não pode ser excluída caso os usuários ou grupos estiverem determinados a isto. Remova os trabalhos da função primeiro e então os exclua.
  1. Realize o login ao Console de Gerenciamento
  2. Navegue à área das Funções com Escopo da tab Funções.
  3. Selecione a função com escopo a ser removida na tabela.
  4. Clique no botão Remover. O diálogo Remover da Função com Escopo irá aparecer.
  5. Clique no botão Confirmar. O diálogo encerra e a função é removida.
Reportar um erro

11.10. Configuração das Restrições

11.10.1. Configuração de Security Constraints (Restrições de Segurança)

Cada Sensitivity Constraint (Restrição de Segurança) define um conjunto de recursos que são considerados "confidenciais". Um recurso confidencial é normalmente um recurso que deve ser secreto, como senhas, ou um que terá impactos sérios no servidor, como rede, configuração JVM ou propriedades de sistema. O próprio sistema de controle é também considerado confidencial. A confidencialidade do recurso limita quais funções estão disponíveis para leitura, gravação ou endereço a um recurso específico.

A configuração de restrição confidencial está no API de Gerenciamento no /core-service=management/access=authorization/constraint=sensitivity-classification.

Cada Sensitivity Constraint (Restrição de Segurança) com o modelo de gerenciamento é identificado como um classification. As classificações são agrupadas em types. Existem 39 classificações que são organizadas em 13 tipos.

Com o objetivo de configurar uma restrição de confidencialidade, use a operação write-attribute para configurar o atributo configured-requires-read, configured-requires-write ou configured-requires-addressable. Com o objetivo de tornar o tipo de operação confidencial, configure o valor para true. Do contrário, para torná-la não confidencial, configure isto para false. Por default, esses atributos não são configurados e os valores de default-requires-read, default-requires-write e default-requires-addressable são usados. Uma vez que o atributo é configurado, o valor será usado ao invés do default. Os valores default não podem ser alterados.

Exemplo 11.5. Tornando as propriedades do sistema de leitura uma operação confidencial

[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=sensitivity-classification/type=core/classification=system-property
[domain@localhost:9999 classification=system-property] :write-attribute(name=configured-requires-read, value=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {"outcome" => "success"}},
        "server-two" => {"response" => {"outcome" => "success"}}
    }}}}
}
[domain@localhost:9999 classification=system-property] :read-resource
{
    "outcome" => "success",
    "result" => {
        "configured-requires-addressable" => undefined,
        "configured-requires-read" => true,
        "configured-requires-write" => undefined,
        "default-requires-addressable" => false,
        "default-requires-read" => false,
        "default-requires-write" => true,
        "applies-to" => {
            "/host=master/system-property=*" => undefined,
            "/host=master/core-service=platform-mbean/type=runtime" => undefined,
            "/server-group=*/system-property=*" => undefined,
            "/host=master/server-config=*/system-property=*" => undefined,
            "/host=master" => undefined,
            "/system-property=*" => undefined,
            "/" => undefined
        }
    }
}
[domain@localhost:9999 classification=system-property]

Quais funções estarão aptas a executar determinadas operações dependerá da configuração desses atributos resumidos na Tabela 11.2, “Resultados da Configuração Sensitivity Constraint (Restrição Confidencial)”.

Tabela 11.2. Resultados da Configuração Sensitivity Constraint (Restrição Confidencial)

Valor requires-read requires-write requires-addressable

true

A leitura é confidencial.

Apenas o Auditor, Administrador e Super Usuário podem ler.

A gravação é confidencial.

Apenas o Administrador e Super Usuário podem gravar.

O endereçamento é confidencial.

Apenas o Auditor, Administrador e Super Usuário podem endereçar.

false

A leitura não é confidencial.

Qualquer usuário de gerenciamento pode ler.

A gravação não é confidencial.

Apenas o Mantedor, Administrador e Super Usuário podem gravar. Os implantadores podem também gravar o recurso num recurso do aplicativo.

O endereçamento não é confidencial.

Qualquer usuário de gerenciamento pode endereçar.
Reportar um erro

11.10.2. Configuração do Application Resource Constraints (Restrições do Recurso do Aplicativo)

Cada Application Resource Constraint (Restrições do Recurso do Aplicativo) define um conjunto de recursos, atributos e operações que são normalmente associados com a implantação dos aplicativos e serviços. Quando a restrição do recurso do aplicativo é habilitada, o acesso aos recursos que isto é aplicado é fornecido aos usuários do gerenciamento de função Implantador.

A configuração de restrição do aplicativo encontra-se no Modelo de Gerenciamento no /core-service=management/access=authorization/constraint=application-classification/.

Cada Application Resource Constraint (Restrições do Recurso do Aplicativo) com o modelo de gerenciamento é identificado como um classification. As classificações são agrupadas em types. Existem 14 classificações incluídas que são agrupadas em 8 typos. Cada classificação possui um elemento applies-to que é uma lista de default do caminho do recurso pelos quais a configuração das classificações são aplicadas.

Por default, a única classificação do Recurso do Aplicativo que é habilitada é o core. O core inclui implantações, sobreposições e as operações de implantação.

Use a operação write-attribute para habilitar o Recurso do Aplicativo para configuração do configured-application attribute da classificação para true. Configure este atributo para false para desabilitação do Recurso do Aplicativo. Por default, esses atributos não são determinados e o valor do default-application attribute é usado. O valor default não pode ser alterado.

Exemplo 11.6. A habilitação da classificação do recurso do aplicativo de perfil do agente de log.

[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=application-classification/type=logging/classification=logging-profile
[domain@localhost:9999 classification=logging-profile] :write-attribute(name=configured-application, value=true)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {"outcome" => "success"}},
        "server-two" => {"response" => {"outcome" => "success"}}
    }}}}
}
[domain@localhost:9999 classification=logging-profile] :read-resource 
{
    "outcome" => "success",
    "result" => {
        "configured-application" => true,
        "default-application" => false,
        "applies-to" => {"/profile=*/subsystem=logging/logging-profile=*" => undefined}
    }
}
[domain@localhost:9999 classification=logging-profile]

Importante

O Application Resource Constraints é válido a todos os recursos que coincidem com a própria configuração. Por exemplo, é possível conceder acesso ao usuário Implantador a um recurso da fonte de dados, porém a nenhum outro. Caso este nível de separação seja solicitado, recomenda-se a configuração dos recursos em grupos de servidores diferentes e criar funções diferentes do Implantador com escopo para cada grupo.
Reportar um erro

11.10.3. Configuração do Vault Expression Constraint (Restrição da Expressão Vault)

Por default, as expressões vault de leitura e escrita são operações confidenciais. A configuração do Vault Expression Constraint (Restrição da Expressão Vault) permite você determinar cada operação ou ambas para não serem confidenciais. A alteração desta restrição permite um número maior de funções às expressões vault de leitura e escrita.

A restrição da expressão vault é encontrada no modelo de gerenciamento /core-service=management/access=authorization/constraint=vault-expression.

Com o objetivo de configurar a restrição da expressão vault, use a operação write-attribute para determinar os atributos do configured-requires-write e configured-requires-read para true ou false. Por default, eles não são determinados e os valores default-requires-read default-requires-write são usados. Os valores default não podem ser alterados.

Exemplo 11.7. Gravação às expressões vault numa operação não confidencial

[domain@localhost:9999 /] cd /core-service=management/access=authorization/constraint=vault-expression
[domain@localhost:9999 constraint=vault-expression] :write-attribute(name=configured-requires-write, value=false)
{
    "outcome" => "success",
    "result" => undefined,
    "server-groups" => {"main-server-group" => {"host" => {"master" => {
        "server-one" => {"response" => {"outcome" => "success"}},
        "server-two" => {"response" => {"outcome" => "success"}}
    }}}}
}
[domain@localhost:9999 constraint=vault-expression] :read-resource
{
    "outcome" => "success",
    "result" => {
        "configured-requires-read" => undefined,
        "configured-requires-write" => false,
        "default-requires-read" => true,
        "default-requires-write" => true
    }
}
[domain@localhost:9999 constraint=vault-expression]

As funções que poderão ler e gravar as expressões vault dependerão da configuração resumida na Tabela 11.3, “Resultados da Configuração Vault Expression Constraint (Restrição da Expressão Vault)”.

Tabela 11.3. Resultados da Configuração Vault Expression Constraint (Restrição da Expressão Vault)

Valor requires-read requires-write

true

A operação de leitura é confidencial.

Apenas o Auditor, Administrador e Super Usuário podem ler.

A operação de gravação é confidencial.

Apenas o Administrador e Super Usuário podem gravar.

false

A operação de leitura não é confidencial.

Todos os usuários de gerenciamento podem ler.

A operação de gravação não é confidencial.

O Monitor, Administrador e Super Usuário podem gravar. Os implantadores podem gravar também caso a expressão vault estiver num Recurso do Aplicativo.
Reportar um erro

11.11. Referência de Restrições

11.11.1. Referência do Application Resource Constraint (Restrição do Recurso do Aplicativo)

Tipo: core

Classificação: deployment-overlay

  • default: verdadeiro
    CAMINHO Atributos Operações

    /deployment-overlay=*

    /deployment=*

    /

    upload-deployment-stream, full-replace-deployment, upload-deployment-url, upload-deployment-bytes

Tipo: fonte de dados

Classificação: fonte de dados

  • default: falso
    CAMINHO Atributos Operações

    /deployment=*/subdeployment=*/subsystem=datasources/data-source=*

    /subsystem=datasources/data-source=*

    /subsystem=datasources/data-source=ExampleDS

    /deployment=*/subsystem=datasources/data-source=*
Classificação: jdbc-driver

  • default: falso
    CAMINHO Atributos Operações

    /subsystem=datasources/jdbc-driver=*
Classificação: xa-data-source

  • default: falso
    CAMINHO Atributos Operações

    /subsystem=datasources/xa-data-source=*

    /deployment=*/subsystem=datasources/xa-data-source=*

    /deployment=*/subdeployment=*/subsystem=datasources/xa-data-source=*

Tipo: logging

Classificação: agente de log

  • default: falso
    CAMINHO Atributos Operações

    /subsystem=logging/logger=*

    /subsystem=logging/logging-profile=*/logger=*
Classificação: logging-profile

  • default: falso
    CAMINHO Atributos Operações

    /subsystem=logging/logging-profile=*

Tipo: mail

Classificação: mail-session

  • default: falso
    CAMINHO Atributos Operações

    /subsystem=mail/mail-session=*

Tipo: nomeação

Classificação: binding

  • default: falso
    CAMINHO Atributos Operações

    /subsystem=naming/binding=*

Tipo: resource-adapters

Classificação: resource-adapters

  • default: falso
    CAMINHO Atributos Operações

    /subsystem=resource-adapters/resource-adapter=*

Tipo: segurança

Classificação: security-domain

  • default: falso
    CAMINHO Atributos Operações

    /subsystem=security/security-domain=*
Reportar um erro

11.11.2. Referência Sensitivity Constraints (Restrições Confidenciais)

Tipo: core

Classificação: access-control

  • requires-addressable: verdadeiro

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /core-service=management/access=authorization

    /subsystem=jmx

    non-core-mbean-sensitivity
Classificação: credencial

  • requires-addressable: falso

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=mail/mail-session=*/server=pop3

    username , password

    /subsystem=mail/mail-session=*/server=imap

    username, password

    /subsystem=datasources/xa-data-source=*

    user-name, recovery-username, password, recovery-password

    /subsystem=mail/mail-session=*/custom=*

    username, password

    /subsystem=datasources/data-source=*"

    user-name, password

    /subsystem=remoting/remote-outbound-connection=*"

    nome do usuário

    /subsystem=mail/mail-session=*/server=smtp

    username , password

    /subsystem=web/connector=*/configuration=ssl

    key-alias, password

    /subsystem=resource-adapters/resource-adapter=*/connection-definitions=*"

    recovery-username, recovery-password
Classificação: domain-controller

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações
Classificação: domain-names

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações
Classificação: extensões

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /extension=*
Classificação: jvm

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /core-service=platform-mbean/type=runtime

    input-arguments, boot-class-path, class-path, boot-class-path-supported, library-path
Classificação: management-interfaces

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /core-service=management/management-interface=native-interface

    /core-service=management/management-interface=http-interface
Classificação: module-loading

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /core-service=module-loading
Classificação: patching

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /core-service=patching/addon=*

    /core-service=patching/layer=*"

    /core-service=patching
Classificação: read-whole-config

  • requires-addressable: falso

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /

    read-config-as-xml
Classificação: security-domain

  • requires-addressable: verdadeiro

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=security/security-domain=*
Classificação: security-domain-ref

  • requires-addressable: verdadeiro

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=datasources/xa-data-source=*

    security-domain

    /subsystem=datasources/data-source=*

    security-domain

    /subsystem=ejb3

    default-security-domain

    /subsystem=resource-adapters/resource-adapter=*/connection-definitions=*

    security-domain, recovery-security-domain, security-application, security-domain-and-application
Classificação: security-realm

  • requires-addressable: verdadeiro

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /core-service=management/security-realm=*
Classificação: security-realm-ref

  • requires-addressable: verdadeiro

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=remoting/connector=*

    security-realm

    /core-service=management/management-interface=native-interface

    security-realm

    /core-service=management/management-interface=http-interface

    security-realm

    /subsystem=remoting/remote-outbound-connection=*

    security-realm
Classificação: security-vault

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /core-service=vault
Classificação: service-container

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /core-service=service-container
Classificação: snapshots

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: falso
    CAMINHO atributos operações

    /

    take-snapshot, list-snapshots, delete-snapshot
Classificação: socket-binding-ref

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: falso
    CAMINHO atributos operações

    /subsystem=mail/mail-session=*/server=pop3

    outbound-socket-binding-ref

    /subsystem=mail/mail-session=*/server=imap

    outbound-socket-binding-ref

    /subsystem=remoting/connector=*

    socket-binding

    /subsystem=web/connector=*

    socket-binding

    /subsystem=remoting/local-outbound-connection=*

    outbound-socket-binding-ref

    /socket-binding-group=*/local-destination-outbound-socket-binding=*

    socket-binding-ref

    /subsystem=remoting/remote-outbound-connection=*

    outbound-socket-binding-ref

    /subsystem=mail/mail-session=*/server=smtp

    outbound-socket-binding-ref

    /subsystem=transactions

    process-id-socket-binding, status-socket-binding, socket-binding
Classificação: socket-config

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /interface=*

    resolve-internet-address

    /core-service=management/management-interface=native-interface

    port, interface, socket-binding

    /socket-binding-group=*

    /core-service=management/management-interface=http-interface

    port, secure-port, interface, secure-socket-binding, socket-binding

    /

    resolve-internet-address

    /subsystem=transactions

    process-id-socket-max-ports
Classificação: system-property

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /core-service=platform-mbean/type=runtime

    system-properties

    /system-property=*

    /

    resolve-expression

Tipo: datasources

Classificação: data-source-security

  • requires-addressable: falso

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=datasources/xa-data-source=*

    user-name, security-domain, password

    /subsystem=datasources/data-source=*

    user-name, security-domain, password

Tipo: jdr

Classificação: jdr

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=jdr

    generate-jdr-report

Tipo: jmx

Classificação: jmx

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=jmx

Tipo: mail

Classificação: mail-server-security

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=mail/mail-session=*/server=pop3

    username, tls, ssl, password

    /subsystem=mail/mail-session=*/server=imap

    username, tls, ssl, password

    /subsystem=mail/mail-session=*/custom=*

    username, tls, ssl, password

    /subsystem=mail/mail-session=*/server=smtp

    username, tls, ssl, password

Tipo: naming

Classificação: jndi-view

  • requires-addressable: falso

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=naming

    jndi-view
Classificação: naming-binding

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: falso
    CAMINHO atributos operações

    /subsystem=naming/binding=*

Tipo: remoting

Classificação: remoting-security

  • requires-addressable: falso

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=remoting/connector=*

    authentication-provider, security-realm

    /subsystem=remoting/remote-outbound-connection=*

    username, security-realm

    /subsystem=remoting/connector=*/security=sasl

Tipo: resource-adapters

Classificação: resource-adapter-security

  • requires-addressable: falso

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=resource-adapters/resource-adapter=*/connection-definitions=*

    security-domain, recovery-username, recovery-security-domain, security-application, security-domain-and-application, recovery-password

Tipo: security

Classificação: misc-security

  • requires-addressable: falso

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=security

    deep-copy-subject-mode

Tipo: web

Classificação: web-access-log

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: falso
    CAMINHO atributos operações

    /subsystem=web/virtual-server=*/configuration=access-log
Classificação: web-connector

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: falso
    CAMINHO atributos operações

    /subsystem=web/connector=*
Classificação: web-ssl

  • requires-addressable: falso

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=web/connector=*/configuration=ssl
Classificação: web-sso

  • requires-addressable: falso

  • requires-read: verdadeiro

  • requires-write: verdadeiro
    CAMINHO atributos operações

    /subsystem=web/virtual-server=*/configuration=sso
Classificação: web-valve

  • requires-addressable: falso

  • requires-read: falso

  • requires-write: falso
    CAMINHO atributos operações

    /subsystem=web/valve=*
Reportar um erro

Capítulo 12. Configuração do Subsistema da Transação

12.1. Transações JTS

12.1.1. Configuração do ORB para as Transações JTS

Numa instalação default do JBoss EAP 6, o ORB está desabilitado. Você pode habilitar o ORB usando o CLI de Gerenciamento da linha de comando.

Nota

Num managed domain, o subsistema JacORB está disponível nos perfis full e full-ha apenas. Num servidor autônomo ele está disponível quando você usa as configurações standalone-full.xml ou standalone-full-ha.xml.

Procedimento 12.1. Configuração do ORB usando o Console de Gerenciamento

  1. Visualização das configurações do perfil.

    Selecione Profiles (managed domain) ou Profile (servidor autônomo) a partir da parte superior direita do console de gerenciamento. Caso você use um managed domain, selecione tanto o perfil full ou full-ha a partir da caixa de seleção no topo esquerdo superior.

  2. Modifique as Configurações Initializers

    Expanda o menu Subsystems na parte esquerda, se necessário. Expanda o submenu Container e clique em JacORB.
    Selecione a tab Initializers e clique no botão Edit da mesma forma que aparece na tela principal.
    Habilite os interceptores pela configuração do valor Security para on.
    Para habilitar o ORB para JTS, configure o valor Transaction Interceptors para on ao invés do spec default.
    Refira-se ao link Need Help? no formulário de explicações detalhadas sobre esses valores. Clique em Save quando você tiver finalizado a edição dos valores.

  3. Configuração ORB Avançada

    Refira-se às demais seções do formulário para opções de configuração avançada. Cada seção inclui um link Need Help? com a informação detalhada sobre os parâmetros.
Configuração do ORB usando o CLI de Gerenciamento

Você pode configurar cada aspecto do ORB usando o CLI de Gerenciamento. Os seguintes comandos configuram os inicializadores aos mesmos valores conforme o procedimento acima, para o Console de Gerenciamento. Esta é a configuração mínima para o ORB a ser usado com o JTS.

Esses comandos são configurados para o managed domain usando o perfil full. Caso necessário, altere o perfil para servir ao que você precisa configurar. Caso você use um servidor autônomo, omita a porção /profile=full de comandos.

Exemplo 12.1. Habilite os Interceptores de Segurança

/profile=full/subsystem=jacorb/:write-attribute(name=security,value=on)

Exemplo 12.2. Habilite o ORB para o JTS

/profile=full/subsystem=jacorb/:write-attribute(name=transactions,value=on)

Exemplo 12.3. Habilite Transações no Subsistema JacORB

/profile=full/subsystem=jacorb/:write-attribute(name=transactions,value=on)

Exemplo 12.4. Habilite JTS no Subsistema de Transação

/subsystem=transactions:write-attribute(name=jts,value=true)
Reportar um erro

12.1.2. Configuração JMS.

12.1.2.1. Referência aos Atributos de Configuração HornetQ

A implementação do JBoss EAP 6 do HornetQ expõem os seguintes atributos para configuração. Você pode usar um CLI de Gerenciamento em particular para exposição dos atributos configuráveis ou visíveis com a operação read-resource.

Exemplo 12.5. Amostra

[standalone@localhost:9999 /] /subsystem=messaging/hornetq-server=default:read-resource

Tabela 12.1. Atributos HornetQ

Função Valor de Amostra Tipo
allow-failback verdadeiro BOOLEANO
async-connection-execution-enabled verdadeiro BOOLEANO
backup falso BOOLEANO
cluster-password somethingsecure SEQUÊNCIA
mask-password verdadeiro BOOLEANO
cluster-user HORNETQ.CLUSTER.ADMIN.USER SEQUÊNCIA
clustered falso BOOLEANO
connection-ttl-override -1 LONGO
create-bindings-dir verdadeiro BOOLEANO
create-journal-dir verdadeiro BOOLEANO
failback-delay 5000 LONGO
failover-on-shutdown falso BOOLEANO
id-cache-size 2000 INT
jmx-domain org.hornetq SEQUÊNCIA
jmx-management-enabled falso BOOLEANO
journal-buffer-size 100 LONGO
journal-buffer-timeout 100 LONGO
journal-compact-min-files 10 INT
journal-compact-percentage 30 INT
journal-file-size 102400 LONGO
journal-max-io 1 INT
journal-min-files 2 INT
journal-sync-non-transactional verdadeiro BOOLEANO
journal-sync-transactional verdadeiro BOOLEANO
journal-type ASYNCIO SEQUÊNCIA
live-connector-ref referência SEQUÊNCIA
log-journal-write-rate falso BOOLEANO
management-address jms.queue.hornetq.management SEQUÊNCIA
management-notification-address hornetq.notifications SEQUÊNCIA
memory-measure-interval -1 LONGO
memory-warning-threshold 25 INT
message-counter-enabled falso BOOLEANO
message-counter-max-day-history 10 INT
message-counter-sample-period 10000 LONGO
message-expiry-scan-period 30000 LONGO
message-expiry-thread-priority 3 INT
page-max-concurrent-io 5 INT
perf-blast-pages -1 INT
persist-delivery-count-before-delivery falso BOOLEANO
persist-id-cache verdadeiro BOOLEANO
persistence-enabled verdadeiro BOOLEANO
remoting-interceptors indefinido LISTA
run-sync-speed-test falso BOOLEANO
scheduled-thread-pool-max-size 5 INT
security-domain outros SEQUÊNCIA
security-enabled verdadeiro BOOLEANO
security-invalidation-interval 10000 LONGO
server-dump-interval -1 LONGO
shared-store verdadeiro BOOLEANO
started verdadeiro BOOLEANO
thread-pool-max-size 30 INT
transaction-timeout 300000 LONGO
transaction-timeout-scan-period 1000 LONGO
version 2.2.16.Final (HQ_2_2_16_FINAL, 122) SEQUÊNCIA
wild-card-routing-enabled verdadeiro BOOLEANO

Atenção

O valor do journal-file-size deve ser maior que o tamanho da mensagem enviada ao servidor ou o servidor não estará apto a armazenar a mensagem.
Reportar um erro

Capítulo 13. Web, Conectores HTTP e Clustering HTTP

13.1. Configuração de um Nó Trabalhador mod_cluster

Sumário

O nó trabalhador mod_cluster consiste do servidor do JBoss EAP. Este servidor pode fazer parte de um grupo do servidor num Managed Domain, ou servidor autônomo. O processo separado executando com o JBoss Enterprise Application Plataform, que gerencia todos os nós do cluster é chamado do mestre. Para uma informação conceitual sobre os nós dos trabalhadores, refira-se ao Worker Node no Red Hat JBoss Enterprise Application Platform 6.1 Administration and Configuration Guide. Para uma visão geral da carga de balanceamento HTTPD, refira-se ao Overview of HTTP Connectors no Administration and Configuration Guide.

O mestre é apenas uma vez configurado através do subsistema mod_cluster. Para configurar o subsistema mod_cluster, refira-se ao Configure the mod_cluster Subsystem no Administration and Configuration Guide. Cada nó trabalhador é configurado separadamente, portanto repita este procedimento para cada nó caso você deseje adicioná-lo ao cluster.
Caso você use um managed domain, cada servidor num grupo de servidor é um nó trabalhador que compartilha uma configuração idêntica. Portanto, a configuração é realizada a uma instância do JBoss EAP 6 única. Do contrário, as etapas da configuração são idênticas.

Configuração do Nó Trabalhador

  • Caso você use um servidor autônomo, ele deve ser iniciado com o perfil standalone-ha.
  • Caso você use o managed domain, o seu grupo do servidor deve ser o perfil ha ou full-ha e o grupo socket binding ha-sockets ou full-ha-sockets. O JBoss EAP 6 lança o grupo do servidor habilitado com cluster, chamado other-server-group, que encontra esses requerimentos.

Nota

Os comandos CLI de Gerenciamento assumem que você usa um managed domain onde eles são gerados. Caso você use o seu servidor autônomo, remova a porção /profile=full-ha dos comandos.

Procedimento 13.1. Configuração do Nó Trabalhador

  1. Configuração das interfaces da rede.

    Por default, as interfaces da rede são default ao 127.0.0.1. Cada host físico que realiza o host tanto no servidor autônomo, ou um ou mais servidores num grupo de servidor, necessita que suas interfaces sejam consideradas para uso do próprio endereço IP público, do qual outros servidores podem ver.
    Para a alteração do endereço IP do host do JBoss EAP 6, você precisa desligar e editar seus arquivos de configuração diretamente. Isto é devido ao API de Gerenciamento que direciona o Console de Gerenciamento e CLI de Gerenciamento basear-se no endereço de gerenciamento estável.
    Siga as seguintes etapas para alteração do endereço IP de cada servidor do seu cluster ao endereço IP público mestre.
    1. Desligue o servidor completamente.
    2. Edite o host.xml, que está no EAP_HOME/domain/configuration/ para o managed domain ou o arquivo standalone-ha.xml, que está no EAP_HOME/standalone/configuration/ para o servidor autônomo.
    3. Localize o elemento <interfaces>. Três interfaces são configuradas, management, public e unsecured. Para cada uma delas, altere o valor 127.0.0.1 para o endereço IP externo do host.
    4. Para os hosts que participam num managed domain mas não são o mestre, localize o elemento <host. Perceba que isto não possui o símbolo >, uma vez que isto contém os atributos. Altere o valor de seu atributo de nome a partir do master a um nome único (um nome diferente por escravo). Este nome será usado também pelo escravo para identificar o cluster, portanto faça uma anotação sobre isto.
    5. Para os hosts recém configurados que precisam unir-se ao managed domain, encontre o elemento <domain-controller>. Comente ou remova o elemento <local /> e adicione a linha de comando, alterando o endereço IP (X.X.X.X) ao endereço do controlador de domain. Esta etapa não é válida ao servidor autônomo. 
      <remote host="X.X.X.X" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm"/>
    6. Salve o arquivo e saia.

  2. Configuração da autenticação para o servidor escravo.

    Cada servidor escravo precisa de um nome de usuário e senha criados no ManagementRealm mestre autônomo ou domain controller. No domain controller ou mestre autônomo, execute o comando EAP_HOME/bin/add-user.sh. Adicione um usuário com o mesmo nome do usuário ao do escravo para o ManagementRealm. Quando você for solicitado se este usuário precisará autenticar à uma instância JBoss AS, por favor responda yes. Segue abaixo uma amostra de uma entrada e saída do comando abaixo, para o escravo chamado slave1 com a senha changeme. 
    user:bin user$ ./add-user.sh

What type of user do you wish to add? 
 a) Management User (mgmt-users.properties) 
 b) Application User (application-users.properties)
(a): a

Enter the details of the new user to add.
Realm (ManagementRealm) : 
Username : slave1
Password : changeme
Re-enter Password : changeme
About to add user 'slave1' for realm 'ManagementRealm'
Is this correct yes/no? yes
Added user 'slave1' to file '/home/user/jboss-eap-6.0/standalone/configuration/mgmt-users.properties'
Added user 'slave1' to file '/home/user/jboss-eap-6.0/domain/configuration/mgmt-users.properties'
Is this new user going to be used for one AS process to connect to another AS process e.g. slave domain controller?
yes/no? yes
To represent the user add the following to the server-identities definition <secret value="Y2hhbmdlbWU=" />

  3. Copie o elemento Base64-encoded <secret> a partir da saída add-user.sh

    Caso você deseje especificar o valor de senha codificada Base64 para a autenticação, copie o valor do elemento <secret> a partir da última linha do resultado add-user.sh uma vez que você precisará disto na etapa abaixo.

  4. Modifique o realm de segurança do host escravo para uso da nova autenticação.

    1. Abra novamente o arquivo host.xml ou standalone-ha.xml do host escravo.
    2. Localize o elemento <security-realms>. Isto é onde você configura o realm de segurança.
    3. Você pode especificar o valor secreto em uma das seguintes maneiras:

      • Especifique o valor de senha codificada Based64 no arquivo da configuração.

        1. Adicione o seguinte bloco do código XML diretamente abaixo da linha <security-realm name="ManagementRealm">, 
          <server-identities>
    <secret value="Y2hhbmdlbWU="/>
</server-identities>
        2. Substitua"Y2hhbmdlbWU=" pelo valor secreto retornado a partir do resultado add-user.sh na etapa anterior.

      • Configure o host para obter a senha a partir do vault.

        1. Use o script vault.sh para gerar a senha mascarada. Ele gerará uma sequência como a seguinte: VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0.
          Você pode encontrar maiores informações sobre o vault nos Vaults da Senha para a seção das Sequências Confidenciais deste guia iniciando aqui: Seção 10.11.1, “Sequências Confidenciais de Segurança nos Arquivos de texto limpo”.
        2. Adicione o seguinte bloco do código XML diretamente abaixo da linha <security-realm name="ManagementRealm">. 
          <server-identities>
    <secret value="${VAULT::secret::password::ODVmYmJjNGMtZDU2ZC00YmNlLWE4ODMtZjQ1NWNmNDU4ZDc1TElORV9CUkVBS3ZhdWx0}"/>
</server-identities>
          Certifique-se de substituir o valor secreto pela senha mascarada na etapa anterior.

          Nota

          Quando criando um vault da senha, ela deve ser especificada num texto plano, e não no Based64 codificado.

      • Especifique a senha como uma propriedade do sistema.

        1. Adicione o seguinte bloco do código XML diretamente abaixo da linha <security-realm name="ManagementRealm"> 
          <server-identities>
    <secret value="${server.identity.password}"/>
</server-identities>
        2. Quando você especificar a senha como uma propriedade de sistema, você pode configurar o host nas seguintes maneiras:
          • Inicie o servidor inserindo a senha num texto plano como o argumento da linha de comando, por exemplo: 
            -Dserver.identity.password=changeme

            Nota

            A senha deve ser inserida num texto plano e será visível a qualquer um que emite um comando ps -ef.
          • Posicione a senha num arquivo de propriedades e passe o URL do arquivo das propriedades como um argumento da linha de comando.
            1. Adicione o par chave/valor a um arquivo de propriedades. Por exemplo: 
              server.identity.password=changeme
            2. Inicie o servidor como os argumentos da linha de comando 
              --properties=URL_TO_PROPERTIES_FILE
              .
    4. Salve e saia do arquivo.

  5. Reinicie o servidor.

    O escravo será agora autenticado ao mestre usando o seu nome do host como o nome de usuário e a sequência criptografada como sua senha.
Resultado

O seu servidor autônomo ou servidores com um grupo do servidor de um managed domain, são configurados como nós dos trabalhadores mod_cluster. Caso você implantar um aplicativo clustered, suas sessões são replicadas a todos os nós para a falha, e isto pode aceitar solicitações a partir de um servidor HTTD externo ou balanceador de carga. Cada nó do cluster descobre outros nós usando a descoberta automática, por default. Para configuração da descoberta automática e outras configurações específicas do subsistema mod_cluster, refira-se ao Configure the mod_cluster Subsystem no Administration and Configuration Guide. Para configurar o servidor HTTPD Apache, refira-se ao Use an External HTTPD as the Web Front-end for JBoss Enterprise Application Platform Applications no Administration and Configuration Guide.

Reportar um erro

Capítulo 14. Instalação de Patch

14.1. Patches e Atualizações

O mecanismo patching no JBoss EAP aplica atualizações que são disponibilizadas a uma versão 'menor' específica do JBoss EAP 6, por exemplo: JBOss EAP 6.2. Os patches podem conter atualizações cumulativas, de segurança e únicas.
A atualização entre os maiores e menores lançamentos do JBoss EAP (por exemplo: a partir do 6.1 ao 6.2) requer um processo diferente.
Reportar um erro

14.2. Mecanismos de Aplicação de Patch

Os patches do JBoss são distribuídos de duas formas.
  • Atualizações assíncronas: patches únicos que são lançados fora do ciclo de atualização normal do produto existente. Elas podem incluir patches de segurança assim como outros patches únicos fornecidos pelo Red Hat Global Suport Services (GSS) para especificação de problemas.
  • Atualizações planejadas: elas incluem patches cumulativos assim como atualizações micro, menores e maiores de um produto existente. Os patches cumulativos incluem atualizações assíncronas desenvolvidas anteriormente para a versão do produto.
A decisão de que um patch é ou não lançado como parte de uma atualização planejada ou uma atualização assíncrona depende na severidade do problema sendo corrigido. Um problema de baixo impacto é normalmente adiado e é resolvido no próximo patch cumulativo ou do menor lançamento do produto afetado, contendo uma correção para apenas um problema específico.
Os patches de segurança e cumulativos para os produtos do JBoss são distribuídos em duas formas: zip (para todos os produtos) e RPM (para o subconjunto dos produtos).

Importante

A instalação do produto do JBoss deve sempre ser apenas atualizada usando um método de patch: tanto patches zip ou RPM.
As atualizações de segurança para os produtos JBoss são fornecidas por uma errata (para ambos os métodos zip e RPM). A errata encapsula uma lista de falhas resolvidas, sua classificação de falhas e a referência aos demais patches. As atualizações de correção de bug não são comunicadas através de errata.
Maiores informações sobre como a Red Hat avalia as falhas de segurança do JBoss podem ser encontradas na: Seção 14.6, “Classificação de impacto e gravidade do JBoss Security Patches (Patches de Segurança JBoss)”
A Red Hat mantém uma lista de correio para notificação aos subscritos sobre a segurança das falhas relacionadas. Consulte a Seção 14.3, “Subscrição para as Listas de Correio Patch”
Reportar um erro

14.3. Subscrição para as Listas de Correio Patch

Sumário

A equipe do JBoss na Red Hat mantém uma lista de correio de segurança para comunicados de segurança sobre os produtos do Red Hat JBoss Enterprise. Este tópico descreve o que você precisa realizar para subscrever-se a esta lista.

Pré-requisitos

  • Nenhum

Procedimento 14.1. Subscrição à Lista de Vigilância do JBoss

  1. Clique no seguinte link para ir à página de lista de correio de Vigilância do JBoss: JBoss Watch Mailing List.
  2. Insira o endereço de e-mail na seção Subscribing to Jboss-watch-list
  3. [Você pode também desejar inserir o seu nome e selecionar sua senha. Embora isto seja opcional, é também recomendado.]
  4. Pressione o botão Subscribe para iniciar o processo de subscrição.
  5. Você pode navegar nos arquivos da lista de correio através do: JBoss Watch Mailing List Archives.
Resultado

Após a confirmação de seu endereço de e-mail, você será subscrito a receber as novidades relacionadas à segurança da lista de correio patch do JBoss.

Reportar um erro

14.4. Instale os Patches na Forma Zip

14.4.1. O comando patch

O comando patch é usado para aplicar os patches do zip baixados a uma instância do servidor JBoss EAP 6. Ele não pode ser usado automaticamente nas instâncias do servidor JBoss EAP 6 de patch por todo managed domain. No entanto, instâncias de servidor individual no managed domain podem sofrer o patch de forma independente.

Importante

As instâncias do servidor JBoss EAP 6 que foram instaladas usando o método RPM não podem ser atualizadas usando o comando patch. Refira-se à Seção 14.5, “Instalação de Patches na forma RPM” para atualização dos servidores do JBoss EAP 6 instalados no RPM.

Nota

O comando patch pode ser apenas usado com patches produzidos nas versões do JBoss EAP 6.2 e mais avançadas. Para os patches de versões anteriores à versão 6.2, você deve referir-se à documentação de versão relevante disponível no https://access.redhat.com/site/documentation/.
Além dos patches aplicados, o comando patch pode fornecer a informação básica no estado de patches instalados e também fornecer uma maneira de reverter imediatamente o aplicativo de um patch.
Antes de iniciar um aplicativo patch ou reverter a operação, a ferramenta patch verificará os módulos e demais arquivos que estão sendo alterados por quaisquer modificações do usuário. Caso a modificação de um usuário for detectada e uma alteração de conflito de manuseio for especificada, a ferramenta patch irá cancelar a operação e avisar que existe um conflito. O aviso incluirá uma lista de módulos e outros arquivos que estiverem em conflito. Para completar a operação, o comando patch deve ser re-executado com uma alteração especificando como resolver o conflito: tanto preservar as modificações do usuário ou substituí-las.

Tabela 14.1. Alterações e Argumentos do Comando patch

Argumento ou Interruptor Descrição
apply Aplica o patch.
--override-all Caso haja um conflito, a operação de patch substitui quaisquer modificações do usuário.
--override-modules Caso haja conflito como resultado de quaisquer módulos modificados, esta alteração substitui aquelas modificações pelos conteúdos da operação do patch.
--override=path(,path) Caso existam arquivos diversos apenas, isto substituirá os arquivos modificados em conflito com os arquivos na operação patch.
--preserve=path(,path) Para os arquivos diversos especificados apenas, isto preservará os arquivos modificados em conflito.
info Retorna a informação nos patches instalados no momento.
rollback Reverte o aplicativo de um patch.
--reset-configuration=TRUE|FALSE Solicitado para a reversão, isto especifica se é que restaurar os arquivos de configuração do servidor como parte da operação de reversão.
Reportar um erro

14.4.2. Instalação de Patches na forma Zip usando o comando patch

Sumário

Esta tarefa descreve como usar o comando patch para instalação de patches para o JBoss EAP 6 que estão no formato zip.

Importante

O comando patch é um recurso que foi adiciona no JBoss EAP 6.2. Para as versões JBoss EAP antecedentes à versão 6.2, o processo de instalação de patches é diferente e você deve seguir a documentação de versão relevante no https://access.redhat.com/site/documentation/.

Pré-requisitos

  • Acesso válido e subscrição do Portal do Cliente Red Hat.
  • A subscrição atual ao produto JBoss instalado no formato zip.
  • Acesso ao CLI de Gerenciamento para a instância do servidor a ser atualizada. Refira-se à Iniciação do CLI de Gerenciamento no Guia de Configuração e Administração.

Procedimento 14.2. Aplique o patch zip a uma instância do servidor do JBoss EAP 6 usando o comando patch

Atenção

Antes da instalação de um patch, você deve realizar o backup de seu produto JBoss juntamente com todos os arquivos de confiquração personalizados.
  1. Realize o download do arquivo zip patch a partir do Portal do Cliente no https://access.redhat.com/downloads/
  2. A partir do CLI de Gerenciamento, aplique o patch com seguinte comando para o patch apropriado ao arquivo patch: 
    [standalone@localhost:9999 /] patch apply /path/to/downloaded-patch.zip
    A ferramenta patch o avisará se existe qualquer conflito na tentativa de aplicar o patch. Refira-se à Seção 14.4.1, “O comando patch” para opções disponíveis sobre executar novamente o comando com o objetivo de resolver qualquer conflito.
  3. Reinicie a instância do servidor JBoss EAP 6 para o patch tenha efeito: 
    [standalone@localhost:9999 /] shutdown --restart=true
Resultado

A instância do servidor JBoss EAP 6 possui patch com a última atualização.

Reportar um erro

14.4.3. Reversão do Aplicativo de um Patch na forma Zip usando o comando patch

Sumário

Esta tarefa descreve o comando patch para reverter o aplicativo de um patch zip aplicado anteriormente no JBoss EAP 6.

Atenção

A reversão de um aplicativo de um patch usando o comando patch não é intencionado como uma funcionalidade de desinstalação geral. Isto é apenas intencionado a ser usado imediatamente após o aplicativo de um patch que possuia consequências indesejáveis.

Importante

O comando patch é um recurso que foi adicionado ao JBoss EAP 6.2. Para as versões JBoss EAP antecedentes à versão 6.2, o processo de reversão de patches é diferente e você deve seguir a documentação de versão relevante no https://access.redhat.com/site/documentation/.

Pré-requisitos

  • O patch que foi aplicado anteriormente usando o comando patch.
  • Acesso ao CLI de Gerenciamento para a instância do servidor. Refira-se à Iniciação do CLI de Gerenciamento no Guia de Configuração e Administração.

Procedimento 14.3. Reversão de um patch a partir da instância do servidor JBoss EAP 6 usando o comando patch

  1. A partir do CLI de Gerenciamento, use o comando patch info para encontrar a ID do patch que está prestes a ser revertido.
    • Para os patches cumulativos, a ID do patch é o valor do primeiro cumulative-patch-id apresentado no resultado patch info.
    • A segurança única ou as IDs do patch de correção de bug estão descritas como o valor dos primeiros patches apresentados no resultado patch info, com o mais recente patch único aplicado e listado primeiramente.
  2. A partir do CLI de Gerenciamento, reverta o patch com a ID do patch apropriado a partir da etapa anterior.

    Atenção

    Recomendamos cuidado ao especificar o valor da opção --reset-configuration.
    Caso determinado para TRUE, o processo de reversão do patch irá reverter também os arquivos de configuração do servidor JBoss EAP 6 a seus estados de pre-patch. Quaisquer alterações realizadas aos arquivos de configuração do servidor JBoss EAP 6, após o patch ser aplicado, serão perdidas.
    Caso determinado para FALSE, os arquivos de configuração do servidor não serão revertidos. Nesta situação, é possível que o servidor não inicie após a reversão, uma vez que o pacth pode ter alterado configurações tais como namespaces, que podem não ser mais válidos e necessitaram ser corrigidos manualmente. 
    [standalone@localhost:9999 /] patch rollback PATCH_ID --reset-configuration=TRUE
    A ferramenta patch o avisará se existem quaisquer conflitos na tentativa da reversão do patch. Refira-se à Seção 14.4.1, “O comando patch” para opções possíveis de reexecução do comando para resolver quaisquer conflitos.
  3. Reinicie a instância do servidor JBoss EAP 6 para que a reversão do patch tenha efeito: 
    [standalone@localhost:9999 /] shutdown --restart=true
Resultado

O patch, e opcionalmente os arquivos de configuração do servidor, são revertidos na instância do servidor do JBoss EAP 6.

Reportar um erro

14.5. Instalação de Patches na forma RPM

Sumário

Os patches do JBoss são distribuídos em duas maneiras: ZIP (para todos os produtos) e RPM (para o subconjunto de produtos). Esta tarefa descreve as etapas que você precisa para instalar os patches através do formato RPM.

Pré-requisitos

  • Uma subscrição válida para o Red Hat Network.
  • A subscrição atual a um produto JBoss instalado através de um pacote RPM.

Procedimento 14.4. Aplicar um patch a um produto JBoss através do método RPM.

As atualizações de segurança para os produtos do JBoss são fornecidas por errata (para ambos métodos zip e RPM). A errata encapsula uma lista de erros resolvidos, seus graus de severidade, os produtos afetados, a descrição textual de erros e a referência aos patches.
Para as distribuições RPM dos produtos do JBoss, a errata inclui referências aos pacotes RPM atualizados. O patch pode ser instalado pelo uso do yum.

Atenção

Antes da instalação de um patch, você deve realizar o backup de seu produto do JBoss juntamente com todos os arquivos de configuração personalizados.
  1. Receba informação sobre o patch de segurança tanto sendo subscrito na lista de correio de vigilância do JBoss ou navegando pelos arquivos da lista de correio de vigilância do JBoss.
  2. Leia a errata para o patch de segurança e certifique-se de que está aplicado a um produto do JBoss em seu ambiente.
  3. Caso o patch de segurança é aplicado a um produto do JBoss no seu ambiente, use o seguinte link para realização do download do pacote RPM atualizado na errata.
  4. Use 
    yum update
    para instalação do patch.

    Importante

    Quando atualizando uma instalação RPM, o seu produto JBoss é atualizado cumulativamente com todas as correções lançadas do RPM.
Resultado

O produto JBoss possui patches com a atualização mais recente usando o formato RPM.

Reportar um erro

14.6. Classificação de impacto e gravidade do JBoss Security Patches (Patches de Segurança JBoss)

A Red Hat usa uma escala de 4 pontos de gravidade: baixa, moderada, importante e crítica, além de duas contagens básicas de versão do Common Vulnerability Scoring System (CVSS) que podem ser usadas para identificar o impacto da falha.

Tabela 14.2. Classificação de gravidade do JBoss Security Patches

Gravidade Descrição
Crítica
A classificação é dada para as falhas que poderiam ser facilmente exploradas por um invasor não identificado e levar a comprometer o sistema (execução de código arbitrário) sem requerer a interação do usuário. Existem tipos de vulnerabilidades que podem ser exploradas. As falhas que requerem um usuário remoto autenticado, um usuário local ou uma configuração improvável não são classificadas como impacto crítico.
Importante
A classificação é dada às falhas que podem facilmente comprometer a confidencialidade, integridade ou habilidade de recursos. Esses são tipos de vulnerabilidades que permitem usuários locais ganharem privilégios, permitir usuários remotos não autenticados a visualizarem recursos que deveriam ser protegidos pela autenticação ou permitir usuários local ou remoto a causarem uma negação de serviço.
Moderada
A classificação é dada para as falhas que poderiam ser dificilmente exploradas, mas podem comprometer a confidencialidade, integridade ou disponibilidade de recursos, sob certas circunstâncias. Existem tipos de vulnerabilidades que podem possuir um impacto crítico de falha ou impacto importante, no entanto não são exploradas com tanta facilidade devido à avalização técnica da falha ou afetam configurações comprometedoras.
Baixa
A classificação é dada a todos os demais problemas que um impacto de segurança possui. Estes são os tipos de vulnerabilidades que acredita-se requerem circunstâncias improváveis para estarem aptos a serem explorados ou onde a exploração com êxito geraria uma consequência mínima.
O componente de impacto da contagem CVSS v2 é baseado numa avaliação combinada de três impactos potenciais: Confidencialidade (C), Integridade (I) e Disponibilidade (A). Cada um deles podem ser classificados como Nenhum (N), Parcial (P) ou Completo (C).
Uma vez que o processo do servidor do JBoss executa como um usuário não privilegiado e está isolado do sistema operacional do host, as falhas de segurança do JBoss são apenas classificadas como possuindo impactos como tanto Nenhum (N) ou Parcial (P).

Exemplo 14.1. Métricas do CVSS v2

A amostra abaixo apresenta a pontuação do impacto CVSS v2, onde a exploração da falha não teria impacto na confiabilidade do sistema, impacto parcial na integridade do sistema e completo impacto na disponibilidade do sistema (quer dizer, o sistema tornaria-se completamente indisponível para qualquer uso, por exemplo: através do travamento do kernel). 
C:N/I:P/A:C
As organizações podem tomar decisões informativas sobre o risco de que cada problema influencia em seu ambiente único e agenda atualizações de acordo, com a combinação da classificação de gravidade e a pontuação CVSS.
Por favor consulte: CVSS2 Guide para maiores informações a respeito do CVSS2.
Reportar um erro

14.7. Gerenciamento das Atualizações de Segurança para Dependências de Agrupadas dentro dos Aplicativos Implantados no JBoss EAP

A Red Hat fornece patches de segurança para todos os componentes que fazem parte da distribuição do JBoss EAP. No entanto, muitos usuários do JBoss EAP implantam aplicativos que agrupam suas próprias dependências, ao invés de usarem exclusivamente componentes fornecidos como parte da distribuição do JBoss EAP. Por exemplo, um arquivo WAR implantado pode incluir dependência de JARs no diretório WEB-INF/lib. Esses JARs estão fora do escopo dos patches de segurança fornecidos pela Red Hat. O gerenciamento das atualizações de segurança agrupadas dentro dos aplicativos implantados no JBoss EAP são de responsabilidade dos mantedores dos aplicativos. As seguintes ferramentas e fontes de dados podem ajudá-lo neste assunto e são fornecidas sem nenhum suporte ou garantia.

Ferramentas e Fontes de Dados

Listas de correio do patch
A subscrição às listas do correio patch do JBoss irão mantê-los informados a respeito das falhas de segurança que foram corrigidas nos produtos, permitindo que você verifique se é que seus aplicativos implantados são agrupados em versões vulneráveis dos componentes afetados.
A página de consulta sobre segurança para os componentes agrupados.
Muitos componentes do código aberto possuem sua própria página de consulta sobre segurança. Por exemplo, struts é um componente comumente usado com muitos problemas conhecidos de segurança que não são fornecidos como parte da distribuição do JBoss EAP. O struts 2 mantém uma página de consulta sobre segurança, que pode ser monitorada caso os aplicativos implantados agrupam o struts 2. Muitos componentes fornecidos comercialmente também mantém as páginas de consulta de segurança.
Realize o scan regularmente dos aplicativos implantados para as vulnerabilidades conhecidas
Existem diversas ferramentas comerciais disponíveis para isto. Existe também uma ferramenta de código aberto chamada Victms, que é desenvolvida pelos funcionários da Red Hat, porém não possui suporte ou garantia. O Victms fornece plugins para diversas ferramentas de integração e construção, que automaticamente escaneia aplicativos para agrupamento das dependências vulneravelmente conhecidas. Os Plugins estão disponíveis para o Maven, Ant e Jenkins. Consulte https://victi.ms/about.html para maiores informações sobre a ferramenta Victms.

Veja também:

Reportar um erro

Parte III. Aplicativos de Segurança

Capítulo 15. Segurança do Aplicativo

15.1. Segurança do Aplicativo

A segurança de seus aplicativos é uma questão importante e complexa para cada desenvolvedor do aplicativo. O JBoss EAP fornece todas as ferramentas que você precisa para gravar os aplicativos de segurança, incluindo as seguintes habilidades:
Consulte também a Seção 17.4, “Uso do Security Domain em seu Aplicativo”.
Reportar um erro

15.2. Habilitação/Desabilitação da Substituição da Propriedade baseada no Descritor

Sumário

O controle finito sobre a substituição da propriedade do descritor foi introduzido no jboss-as-ee_1_1.xsd. Esta tarefa descreve as etapas de configuração do descritor baseado no descritor.

Pré-requisitos

  • Inicie a instância da Plataforma do Aplicativo JBoss Enterprise.
  • Inicie o CLI de Gerenciamento.
Os avisos de substituição da propriedade baseada no descritor possuem os valores booleanos:
  • Quando configurado para true, as substituições da propriedade são habilitadas.
  • Quando configurados para false, as substituições da propriedade são desabilitadas.

Procedimento 15.1. jboss-descriptor-property-replacement

O jboss-descriptor-property-replacement é usado para habilitar ou desabilitar a substituição da propriedade nos seguintes descritores:
  • jboss-ejb3.xml
  • jboss-app.xml
  • jboss-web.xml
  • *-jms.xml
  • *-ds.xml
O valor default para o jboss-descriptor-property-replacement é true.
  1. No CLI de Gerenciamento, execute o seguinte comando para determinar o valor do jboss-descriptor-property-replacement: 
    /subsystem=ee:read-attribute(name="jboss-descriptor-property-replacement")
  2. Execute o seguinte comando para configuração do comportamento: 
    /subsystem=ee:write-attribute(name="jboss-descriptor-property-replacement",value=VALUE)

Procedimento 15.2. spec-descriptor-property-replacement

O spec-descriptor-property-replacement é usado para habilitar ou desabilitar a substituição da propriedade nos seguintes descritores:
  • ejb-jar.xml
  • persistence.xml
O valor default para spec-descriptor-property-replacement é false.
  1. No CLI de Gerenciamento, execute o seguinte comando para confirmar o valor do spec-descriptor-property-replacement: 
    /subsystem=ee:read-attribute(name="spec-descriptor-property-replacement")
  2. Execute o seguinte comando para configuração do comportamento: 
    /subsystem=ee:write-attribute(name="spec-descriptor-property-replacement",value=VALUE)
Resultado

O descritor baseado nas tags de substituição da propriedade baseada no descritor foi configurado com êxito.

Reportar um erro

15.3. Segurança da Fonte de Dados

15.3.1. Segurança da Fonte de Dados

A solução preferida para a segurança da fonte de dados é o uso tanto dos security domains ou vaults da senha. As amostras de cada um estão incluídas abaixo. Refira-se abaixo para maiores informações sobre este assunto:

Exemplo 15.1. Amostra do Security Domain

<security>
   <security-domain>mySecurityDomain</security-domain>
</security>

Exemplo 15.2. Amostra do Vault de Senha

<security>
  <user-name>admin</user-name>
  <password>${VAULT::ds_ExampleDS::password::N2NhZDYzOTMtNWE0OS00ZGQ0LWE4MmEtMWNlMDMyNDdmNmI2TElORV9CUkVBS3ZhdWx0}</password>
</security>
Reportar um erro

15.4. Segurança do Aplicativo EJB

15.4.1. Identidade de Segurança

15.4.1.1. Identidade de Segurança EJB

O security identity, conhecido também como invocation identity, refere-se à tag <security-identity> na configuração de segurança. Isto refere-se à identidade de outro EJB deve usar quando ele invocar os métodos nos componentes.
A identidade da invocação pode ser tanto o chamador atual ou pode ser uma função específica. Nesse caso, a tag <use-caller-identity> está presente e no segundo caso a tag <run-as> for usada.
Refira-se à Seção 15.4.1.2, “Determine a Identidade de Segurança de um EJB” para maiores informações sobre a configuração da identidade de segurança num EJB.
Reportar um erro

15.4.1.2. Determine a Identidade de Segurança de um EJB

Exemplo 15.3. Determine a identidade de segurança de um EJB a ser o mesmo ao do seu chamador

Esta amostra determina a identidade de segurança para invocações de métodos realizadas por um EJB a ser a mesma à identidade do chamador atual. O comportamento é default caso você não especifique uma declaração do elemento <security-identity>. 
<ejb-jar>
  <enterprise-beans>
	 <session>
		<ejb-name>ASessionBean</ejb-name>
		<!-- ... -->
		<security-identity>
		  <use-caller-identity/>
		</security-identity>
	 </session>
	 <!-- ... -->
  </enterprise-beans>
</ejb-jar>

Exemplo 15.4. Determine a identidade de segurança de um EJB para uma função específica

Para determinar a identidade a função de segurança, use as tags <run-as> e <role-name> dentro da tag <security-identity>. 
<ejb-jar>
  <enterprise-beans>
	 <session>
		<ejb-name>RunAsBean</ejb-name>
		<!-- ... -->
		<security-identity>
		  <run-as>
			 <description>A private internal role</description>
			 <role-name>InternalRole</role-name>
		  </run-as>
		</security-identity>
	 </session>
  </enterprise-beans>
  <!-- ... -->
</ejb-jar>
Por default, quando você usar o <run-as>, um principal nomeado anonymous é determinado para chamadas de saída. Para determinar um principal diferente, use o <run-as-principal>. 
<session>
    <ejb-name>RunAsBean</ejb-name>
    <security-identity>
        <run-as-principal>internal</run-as-principal>
    </security-identity>
</session>

Nota

Você pode usar os elementos <run-as> e <run-as-principal> dentro de um elemento servlet.

Consulte também:

Reportar um erro

15.4.2. Permissões de Método EJB

15.4.2.1. Permissões do Método EJB

O EJB fornece uma declaração do elemento <method-permisison>. Essa declaração determina as funções que são permitidas a invocar os métodos da interface EJB. Você pode especificar permissões para as seguintes combinações:
  • Todos os métodos da interface do componente e principal do EJB nomeado
  • O método especificado da interface do componente e principal do EJB nomeado
  • O método especificado com um conjunto de métodos com um nome sobrecarregado
Consulte a Seção 15.4.2.2, “Uso das Permissões do Método EJB” para outros exemplos.
Reportar um erro

15.4.2.2. Uso das Permissões do Método EJB

Visão Geral

O elemento <method-permission> define as funções lógicas que são permitidas para acesso ao método EJB definido pelos elementos <method>. Diversas amostras demonstram a sintaxe do XML. As declarações de permissão do método podem estar presentes e elas possuem efeito cumulativo. O elemento <method-permission> é um filho do elemento <assembly-descriptor> do descritor <ejb-jar>.

A sintaxe XML é uma alternativa usando anotações para as permissões do método EJB.

Exemplo 15.5. Permite que funções acessem todos os métodos de um EJB

<method-permission>
  <description>The employee and temp-employee roles may access any method
  of the EmployeeService bean </description>
  <role-name>employee</role-name>
  <role-name>temp-employee</role-name>
  <method>
    <ejb-name>EmployeeService</ejb-name>
    <method-name>*</method-name>
  </method>
</method-permission>

Exemplo 15.6. Permite que funções acessem apenas métodos especificados de um EJB e limitam os parâmetros de método que precisam ser passados.

<method-permission>
  <description>The employee role may access the findByPrimaryKey,
  getEmployeeInfo, and the updateEmployeeInfo(String) method of
  the AcmePayroll bean </description>
  <role-name>employee</role-name>
  <method>
	<ejb-name>AcmePayroll</ejb-name>
	<method-name>findByPrimaryKey</method-name>
  </method>
  <method>
	<ejb-name>AcmePayroll</ejb-name>
	<method-name>getEmployeeInfo</method-name>
  </method>
  <method>
	<ejb-name>AcmePayroll</ejb-name>
	<method-name>updateEmployeeInfo</method-name>
	<method-params>
	  <method-param>java.lang.String</method-param>
	</method-params>
  </method>
</method-permission>

Exemplo 15.7. Permite que qualquer usuário autenticado acesse os métodos do EJBs

O uso do elemento <unchecked/> permite que qualquer usuário autenticado use os métodos especificados. 
<method-permission>
  <description>Any authenticated user may access any method of the
  EmployeeServiceHelp bean</description>
  <unchecked/>
  <method>
	<ejb-name>EmployeeServiceHelp</ejb-name>
	<method-name>*</method-name>
  </method>
</method-permission>

Exemplo 15.8. Exclui completamente os métodos EJB específicos de serem utilizados

<exclude-list>
  <description>No fireTheCTO methods of the EmployeeFiring bean may be
  used in this deployment</description>
  <method>
	<ejb-name>EmployeeFiring</ejb-name>
	<method-name>fireTheCTO</method-name>
  </method>
</exclude-list>

Exemplo 15.9. Um <assembly-descriptor> completo contendo diversos blocos <method-permission>

<ejb-jar>
    <assembly-descriptor>
        <method-permission>
            <description>The employee and temp-employee roles may access any
                method of the EmployeeService bean </description>
            <role-name>employee</role-name>
            <role-name>temp-employee</role-name>
            <method>
                <ejb-name>EmployeeService</ejb-name>
                <method-name>*</method-name>
            </method>
        </method-permission>
        <method-permission>
            <description>The employee role may access the findByPrimaryKey,
                getEmployeeInfo, and the updateEmployeeInfo(String) method of
                the AcmePayroll bean </description>
            <role-name>employee</role-name>
            <method>
                <ejb-name>AcmePayroll</ejb-name>
                <method-name>findByPrimaryKey</method-name>
            </method>
            <method>
                <ejb-name>AcmePayroll</ejb-name>
                <method-name>getEmployeeInfo</method-name>
            </method>
            <method>
                <ejb-name>AcmePayroll</ejb-name>
                <method-name>updateEmployeeInfo</method-name>
                <method-params>
                    <method-param>java.lang.String</method-param>
                </method-params>
            </method>
        </method-permission>
        <method-permission>
            <description>The admin role may access any method of the
                EmployeeServiceAdmin bean </description>
            <role-name>admin</role-name>
            <method>
                <ejb-name>EmployeeServiceAdmin</ejb-name>
                <method-name>*</method-name>
            </method>
        </method-permission>
        <method-permission>
            <description>Any authenticated user may access any method of the
                EmployeeServiceHelp bean</description>
            <unchecked/>
            <method>
                <ejb-name>EmployeeServiceHelp</ejb-name>
                <method-name>*</method-name>
            </method>
        </method-permission>
        <exclude-list>
            <description>No fireTheCTO methods of the EmployeeFiring bean may be
                used in this deployment</description>
            <method>
                <ejb-name>EmployeeFiring</ejb-name>
                <method-name>fireTheCTO</method-name>
            </method>
        </exclude-list>
    </assembly-descriptor>
</ejb-jar>
Reportar um erro

15.4.3. Anotações de Segurança EJB

15.4.3.1. Anotações de Segurança EJB

Os EJBs usam anotações de segurança para passar informação a respeito da segurança ao implantador. Elas são:
@DeclareRoles
Declara quais funções estão disponíveis.
@RolesAllowed, @PermitAll, @DenyAll
Especifica quais permissões de método são permitidas. Refira-se à Seção 15.4.2.1, “Permissões do Método EJB”, para maiores informações sobre as permissões do método.
@RunAs
Configura a identidade de segurança propagada de um componente.
Refira-se à Seção 15.4.3.2, “Anotações da Segurança EJB” para maiores informações.
Reportar um erro

15.4.3.2. Anotações da Segurança EJB

Visão Geral

Você pode usar tanto os descritores ou anotações XML para controlar quais funções de segurança estão aptas a chamar métodos em seu Enterprise JavaBeans (EJBs). Para maiores informações no uso dos descritores XML, refira-se à Seção 15.4.2.2, “Uso das Permissões do Método EJB”.

Anotações para Controle das Permissões de Segurança dos EJBs

@DeclareRoles
Use @DeclareRoles para definir quais funções de segurança verificar. Caso nenhum @DeclareRoles estiver presente, a lista é uma construção automática da anotação @RolesAllowed.
@SecurityDomain
Especifica o security domain para uso do EJB. Caso o EJB seja anotado para a autorização com o @RolesAllowed, a autorização irá apenas aplicar caso o EJB esteja anotado com o security domain.
@RolesAllowed, @PermitAll, @DenyAll
Use o @RolesAllowed para listar quais funções são permitidas para acessar um método ou métodos. Use o @PermitAll ou @DenyAll para tanto permitir ou negar todas as funções de uso um método ou métodos.
@RunAs
Use @RunAs para especificar uma função de um método que sempre será executado.

Exemplo 15.10. Amostra das Anotações de Segurança

@Stateless
@RolesAllowed({"admin"})
@SecurityDomain("other")
public class WelcomeEJB implements Welcome {
	@PermitAll
	public String WelcomeEveryone(String msg) {
		return "Welcome to " + msg;
	}
	@RunAs("tempemployee")
	public String GoodBye(String msg) {
	    return "Goodbye, " + msg;
	}
	public String GoodbyeAdmin(String msg) {
		return "See you later, " + msg;
	}
}
Neste código, todas as funções podem acessar o método WelcomeEveryone. O método GoodBye usa como função tempemployee quando realizando chamadas. Apenas a função admin pode acessar o método GoodbyeAdmin e quaisquer outros métodos sem anotação de segurança.
Reportar um erro

15.4.4. Acesso Remoto para os EJBs

15.4.4.1. Acesso de Método Remoto

O JBoss Remoting é o framework que fornece acesso remoto aos EJBs, JMX MBeans e outros serviços similares. Ele funciona com os seguintes tipos de transporte, com ou sem SSL:

Tipos de Transporte Suportados

  • Socket / Socket de Segurança
  • RMI / RMI sobre SSL
  • HTTP / HTTPS
  • Servlet / Servlet de Segurança
  • Bisocket / Bisocket de Segurança
O JBoss Remoting fornece também a descoberta automática através do Multicast ou JNDI.
Isto é usado por muitos dos subsistemas com o JBoss EAP 6 e também habilita-o ao design, implementação e implantação de serviços que podem ser invocados de maneira remota por clientes sobre mecanismos diferentes de transporte. Isto permite também o acesso a serviços existentes no JBoss EAP 6.
Marshalling Dados

O sistema Remoting fornece também o marshalling de dados e serviços sem marshalling. O marshalling de dados refere-se à habilidade de mover com segurança os dados através dos limites da plataforma e da rede, de forma que um sistema separado pode executar trabalhos no mesmo. O trabalho é então enviado de volta ao sistema original e comporta-se como se tivesse manuseado manualmente.

Visão Geral da Arquitetura

Quando você realiza o design de um aplicativo diferente que usa o Remoting, você direciona o seu aplicativo à comunicar-se com o servidor pela configuração do mesmo para uso de um tipo especial de localizador de recurso chamado InvokerLocator, que é uma Sequência simples com o formato de tipo de URL. O servidor escuta por solicitações para recursos remotos num connector, que é configurado como parte do subsistema remoting. O connector manuseia a solicitação ao ServerInvocationHandler configurado. Cada ServerInvocationHandler implementa um invoke(InvocationRequest) de método, que sabe como manusear a solicitação.

O framework do JBoss Remoting contém três camadas que espelham-se ao lado do cliente e do servidor.

Camadas do Framework do JBoss Remoting

  • O usuário interage com a camada externa. No lado do cliente, a camada externa é a classe Client, que envia as solicitações de invocação. No lado do servidor, ela é o InvocationHandler, que é implementado pelo usuário e recebe solicitações de invocação.
  • O transporte é controlado pela camada do invocador.
  • A camada mais baixa contendo o marshaller e sem marshaller, que converte formatos de dados para formatos eletrônicos.
Reportar um erro

15.4.4.2. Retorno de Chamada Remoting

Quando um cliente Remoting solicita informação a partir do servidor, ele pode bloquear e esperar que o servidor responda, porém normalmente este não é o comportamento ideal. Para permitir que o cliente escute por eventos no servidor e continue realizando outros trabalhos enquanto esperando pelo servidor encerrar a solicitação, o seu aplicativo pode pedir ao servidor o envio de uma notificação quando ele tiver encerrado. Isto é chamado de retorno de chamada. Um cliente pode adicionar-se com ouvinte para eventos assíncronos gerados em nome de outro cliente. Existem duas maneiras diferentes de como receber retorno de chamadas: retorno de chamada pull ou push. Os clientes verificam os retornos de chamadas de forma assíncrona, porém escutam passivamente os retornos de chamadas push.
Basicamente, o retorno de chamada funciona pelo servidor enviando um InvocationRequest ao cliente. O seu código ao lado do servidor funciona da mesma forma independente do retorno de chamada ser assíncrono ou não. Apenas o cliente precisa saber desta diferença. O InvocationRequest do servidor envia um responseObject ao cliente. Esta é a carga que o cliente solicita. Isto pode ser uma resposta direta a uma solicitação ou uma notificação de evento.
O seu servidor também rastreia os ouvintes usando um objeto m_listeners. Ele contém uma lista de todos os ouvintes que foram adicionados ao seu manuseador do servidor. A interface ServerInvocationHandler inclui os métodos que o permitem gerenciar esta lista.
O cliente manuseia o retorno de chamada pull e push em diferentes maneiras. Em ambos os casos, isto deve implementar um manuseador de retorno de chamada. Um manuseador de retorno de chamada é uma implementação do org.jboss.remoting.InvokerCallbackHandler da interface, que processa os dados do retorno da chamada. Após implementar o manuseador do retorno de chamada, você pode tanto adicionar-se como um ouvinte para o retorno de chamada pull ou implementar o servidor do retorno de chamada para o retorno de chamada push.
Retornos de Chamadas Pull

Para o retorno de chamada pull, o seu cliente adiciona-se à lista do servidor de ouvintes usando o método Client.addListener(). Ele então pesquisa o servidor periodicamente para a entrega assíncrona de dados do retorno de chamada. Esta pesquisa é executada usando o Client.getCallbacks().

Retorno de Chamada Push

O retorno de chamada push requer que seu aplicativo de cliente execute o seu próprio InvocationHandler. Para isto, você precisa executar um serviço Remoting ao lado do próprio cliente. Isto é chamado callback server. O servidor do retorno de chamada aceita as solicitações de entrada assíncronas e as processa para o solicitador (neste caso, o servidor). Com o objetivo de registrar o seu servidor de retorno de chamada do cliente com o servidor principal, por favor passe o InvokerLocator do servidor do retorno de chamada como segundo argumento ao método addListener.

Reportar um erro

15.4.4.3. Detecção do Servidor Remoting

Os clientes e servidores Remoting podem automaticamente detectar-se entre si usando o JNDI ou Multicast. O Detector Remoting é adicionado à ambos cliente e servidor e o NetworkRegistry é adicionado ao cliente.
O Detector ao lado do servidor escaneia periodicamente o InvokerRegistry e efetua o pull em todos os invocadores do servidor que ele criou. Ele usa esta informação para publicar a mensagem de detecção que contém o localizador e os subsistemas suportados por cada invocador do servidor. Ele publica esta mensagem através da difusão multicast ou um binding no servidor JNDI.
No lado do cliente, o Detector recebe a mensagem multicast ou periodicamente pesquisa pelo servidor JNDI para restaurar as mensagens de detecção. O detector noticia que a mensagem de detecção é para o servidor remoting recentemente detectado. Isto o registra no NetworkRegistry. O Detector também atualiza o NetworkRegistry caso ele detecte que o servidor não está mais disponível.
Reportar um erro

15.4.4.4. Configuração do Subsistema Remoting

Visão Geral

O JBoss Remoting possui três elementos configuráveis de nível superior: o pool thread do trabalhador, um ou mais conectores e as séries de URIs de conexão remota e local. Este tópico apresenta uma explicação de cada item configurado, amostra de comandos CLI de como configurar cada item e uma amostra XML de subsistema inteiramente configurado. Esta configuração é apenas válida ao servidor. A maioria das pessoas não irão precisar configurar o subsistema Remoting, a não ser que elas usem os conectores personalizados para os seus próprios aplicativos. Os aplicativos que atuam como clientes Remoting, tais como os EJBs, precisam de uma configuração separada para se conectarem a um conector específico.

Nota

A configuração do subsistema Remoting não é exposta ao Console de Gerenciamento baseado na web, porém ela é inteiramente configurável a partir do CLI de Gerenciamento. Não é recomendável a edição do XML manualmente.
Adaptação dos Comandos CLI

Os comandos CLI são formulados para o managed domain, quando configurando o perfil default. Para configurar um perfil diferente, substitua o seu nome. Para o servidor autônomo, omita a parte /profile=default do comando.

Configuração fora do Subsistema Remoting

Existem poucos aspetos de configurações que estão fora do subsistema remoting:

Interface da Rede
A interface da rede usada pelo subsistema remoting é a interface unsecure definida no domain/configuration/domain.xml ou standalone/configuration/standalone.xml. 
<interfaces>
   <interface name="management"/>
   <interface name="public"/>
   <interface name="unsecure"/>
</interfaces>
A definição por host da interface unsecure está definida no host.xml do mesmo diretório ao do domain.xml ou standalone.xml. Esta interface é também usada por diversos outros subsistemas. Recomendamos atenção ao modificá-lo. 
<interfaces>
   <interface name="management">
      <inet-address value="${jboss.bind.address.management:127.0.0.1}"/>
   </interface>
   <interface name="public">
      <inet-address value="${jboss.bind.address:127.0.0.1}"/>
   </interface>
   <interface name="unsecure">
      <!-- Used for IIOP sockets in the standard configuration.
         To secure JacORB you need to setup SSL -->
      <inet-address value="${jboss.bind.address.unsecure:127.0.0.1}"/>
   </interface>
</interfaces>
socket-binding
O socket-binding default usado pelo subsistema remoting aplica o bind ao TCP porta 4777. Refira-se à documentação sobre bindings do socket e seus grupos para maiores informações caso você precise alterá-los.
Referência de Conector Remoto para o EJB
O subsistema EJB contém uma referência ao conector remoto para invocações de método remoto. Segue abaixo a configuração default: 
<remote connector-ref="remoting-connector" thread-pool-name="default"/>
Configuração de Transporte de Segurança
Os transportes remotos usam o StratTLS para uso da conexão de segurança (HTTPS, Secure Servlet, etc) caso o cliente solicite isto. O mesmo socket binding (porta de rede) é usado para aplicar e retirar a segurança das conexões. O cliente solicita o transporte com ou sem segurança, conforme a própria necessidade. Os componentes do JBoss EAP 6 que usam o Remoting, tais como os EJBs, o ORB e o provedor JMS requerem interfaces com segurança por default.

Atenção

O StartTLS funciona pela ativação da conexão de segurança caso o cliente solicite isto. Do contrário, o default é uma conexão sem segurança. Ele é hereditariamente suscetível a um estilo Man in the Middle exploit, sendo que um atacante intercepta a solicitação do cliente e a modifica para solicitar uma conexão sem segurança. Os clientes devem ser gravados à falha de maneira apropriadas caso eles não recebam uma conexão de segurança, a não ser que a conexão sem segurança é uma falha apropriada.
Pool Thread do Trabalhador

O pool thread é um grupo de threads que está disponível para processar trabalho que vêem através dos conectores Remoting. Ele é um <worker-thread-pool> de elemento único e leva diversos atributos. Ajuste esses atributos caso você obter intervalos de rede, não tenha mais threads ou precise limitar o uso da memória. As recomendações específicas dependem de sua situação em específico. Contate os Serviços de Suporte Global da Red Hat para maiores informações.

Tabela 15.1. Atributos do Pool Thread do Trabalhador

Função Descrição Comando CLI
read-threads
O número de leitura de threads para criação de trabalhador remoto. O default é 1.
/profile=default/subsystem=remoting/:write-attribute(name=worker-read-threads,value=1)
write-threads
O número de threads de gravação para criação do trabalhador remoto. O default é 1.
/profile=default/subsystem=remoting/:write-attribute(name=worker-write-threads,value=1)
task-keepalive
O número de milésimos de segundos para manter os threads de tarefa do trabalhador remoto sem core. O default é 60.
/profile=default/subsystem=remoting/:write-attribute(name=worker-task-keepalive,value=60)
task-max-threads
O número máximo de threads para o pool thread de tarefa do trabalhador. O default é 16.
/profile=default/subsystem=remoting/:write-attribute(name=worker-task-max-threads,value=16)
task-core-threads
O número de threads core para o pool thread da tarefa do trabalhador remoto. O default é 4.
/profile=default/subsystem=remoting/:write-attribute(name=worker-task-core-threads,value=4)
task-limit
O número máximo de tarefas do trabalhador remoto a ser permitido antes da rejeição. O default é 16384.
/profile=default/subsystem=remoting/:write-attribute(name=worker-task-limit,value=16384)
Conector

O conector é o elemento de configuração Remota principal. Os conectores múltiplos são permitidos. Cada um consiste de um elemento <connector> com diversos subelementos, assim como um pouco de possíveis atributos. O conector default é usado por diversos subsistemas do JBoss EAP 6. As configurações específicas para os elementos e atributos dos conectores dependem de seus aplicativos, portanto contate os Serviços de Suporte Global da Red Hat para maiores informações.

Tabela 15.2. Atributos do Conector

Função Descrição Comando CLI
socket-binding O nome do binding do socket para uso deste conector.
/profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=socket-binding,value=remoting)
authentication-provider
O módulo Java Authentication Service Provider Interface for Containers (JASPIC) para uso com este conector. O módulo deve estar no classpath.
/profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=authentication-provider,value=myProvider)
security-realm
Opcional. O security realm que contém os usuários, senhas e funções. O Aplicativo da Web ou EJB pode autenticar em relação ao security realm. O ApplicationRealm está disponível na instalação do JBoss EAP 6 default.
/profile=default/subsystem=remoting/connector=remoting-connector/:write-attribute(name=security-realm,value=ApplicationRealm)

Tabela 15.3. Elementos do Conector

Função Descrição Comando CLI
sasl
O elemento anexo para os mecanismos de autenticação do Simple Authentication and Security Layer (SASL)
N/A
propriedades
Contém um ou mais elementos <property>, cada um com o atributo name e o atributo value opcional.
/profile=default/subsystem=remoting/connector=remoting-connector/property=myProp/:add(value=myPropValue)
Conexões Outbound

Você pode especificar os três diferentes tipos de conexão de saída:

  • Conexão de saída a um URI.
  • Conexão de saída local – conecta a um recurso local tal como socket.
  • Conexão de saída remota – conecta a um recurso remoto e autentica usando um realm de segurança.
Todas as conexões estão inclusas no elemento <outbound-connections>. Cada um dos tipos de conexão leva um atributo outbound-socket-binding-ref. A conexão de saída leva um atributo uri. A conexão de saída remota leva atributos opcionais username e security-realm para uso da autorização.

Tabela 15.4. Os Elementos de Conexão de saída

Função Descrição Comando CLI
outbound-connection Conexão de saída
/profile=default/subsystem=remoting/outbound-connection=my-connection/:add(uri=http://my-connection)
local-outbound-connection A conexão de saída com um esquema local:// URI implícito.
/profile=default/subsystem=remoting/local-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting2)
remote-outbound-connection
As conexões de saída para o esquema remote:// URI usando a autenticação com o realm de segurança.
/profile=default/subsystem=remoting/remote-outbound-connection=my-connection/:add(outbound-socket-binding-ref=remoting,username=myUser,security-realm=ApplicationRealm)
Elementos SASL

Antes da definição dos elementos filhos SASL, você precisa criar o elemento SASL inicial. Use o seguinte comando: 

/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:add
Os elementos filhos do elemento SASL estão descritos na tabela abaixo:
Função Descrição Comando CLI
include-mechanisms
Contém um atributo value, que é uma lista de espaço separado dos mecanismos SASL. 
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=include-mechanisms,value=["DIGEST","PLAIN","GSSAPI"])
qop
Contém um atributo value, que é uma lista de espaços separados da Qualidade SASL Quality dos valores de proteção, em ordem decrescente de preferência. 
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=qop,value=["auth"])
strength
Contém o atributo value, que é uma lista de espaço separado dos valores potentes de criptografia SASL, em ordem decrescente de preferência. 
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=strength,value=["medium"])
reuse-session
Contém o atributo value que é um valor booleano. Caso verdadeiro, tente reutilizar as sessões. 
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=reuse-session,value=false)
server-auth
Contém um atributo value que é um valor booleano. Caso verdadeiro, o servidor autentica para o cliente. 
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl:write-attribute(name=server-auth,value=false)
política
Um elemento anexo que contém zero ou mais dos seguintes elementos, cada qual leva um value único.
  • forward-secrecy – se é que mecanismos são solicitados para implementar sigilo a mais (a divisão em uma sessão não fornecerá informação para divisão em futuras sessões.
  • no-active – se é que os mecanismos suscetíveis aos ataques sem dicionário são permitidos. Um valor de false permite e true recusa.
  • no-anonymous – se é que os mecanismos que aceitam o login anônimo são permitidos. O valor de false permite e true recusa.
  • no-dictionary – se é que os mecanismos susceptíveis aos ataques do dicionário passivo são permitidos. O valor false permite e o valor true recusa.
  • no-plain-text – se é que os mecanismos que são suscetíveis aos ataques passivos planos e simples são permitidos. O valor de false permite e true recusa.
  • pass-credentials – se é que os mecanismos que passam os credenciais do cliente são permitidos. 
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:add
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=forward-secrecy,value=true)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-active,value=false)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-anonymous,value=false)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-dictionary,value=true)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=no-plain-text,value=false)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/sasl-policy=policy:write-attribute(name=pass-credentials,value=true)
propriedades
Contém um ou mais elementos <property>, cada um com o atributo name e o atributo value opcional. 
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/property=myprop:add(value=1)
/profile=default/subsystem=remoting/connector=remoting-connector/security=sasl/property=myprop2:add(value=2)

Exemplo 15.11. Configurações de Amostra

Essa amostra apresenta o subsistema remoto default que lança o JBoss EAP 6. 
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
    <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/>
</subsystem>
Essa amostra contém muitos valores hipotéticos e é representada para a adição dos elementos e atributos discutidos anteriormente no contexto. 
<subsystem xmlns="urn:jboss:domain:remoting:1.1">
    <worker-thread-pool read-threads="1" task-keepalive="60' task-max-threads="16" task-core-thread="4" task-limit="16384" write-threads="1" />
    <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm">
        <sasl>
            <include-mechanisms value="GSSAPI PLAIN DIGEST-MD5" />
            <qop value="auth" />
            <strength value="medium" />
            <reuse-session value="false" />
            <server-auth value="false" />
            <policy>
                <forward-secrecy value="true" />
                <no-active value="false" />
                <no-anonymous value="false" />
                <no-dictionary value="true" />
                <no-plain-text value="false" />
                <pass-credentials value="true" />
            </policy>
            <properties>
                <property name="myprop1" value="1" />
                <property name="myprop2" value="2" />
            </properties>
        </sasl>
        <authentication-provider name="myprovider" />
        <properties>
            <property name="myprop3" value="propValue" />
        </properties>
    </connector>
    <outbound-connections>
        <outbound-connection name="my-outbound-connection" uri="http://myhost:7777/"/>
        <remote-outbound-connection name="my-remote-connection" outbound-socket-binding-ref="my-remote-socket" username="myUser" security-realm="ApplicationRealm"/>
        <local-outbound-connection name="myLocalConnection" outbound-socket-binding-ref="my-outbound-socket"/>
    </outbound-connections>
</subsystem>

Aspectos da Configuração ainda não documentados

  • Detecção Automática Multicast e JNDI
Reportar um erro

15.4.4.5. Uso dos Security Realms com os Clientes EJB Remoto

Uma maneira de adicionar a segurança aos clientes que invocam os EJBs remotamente é usar os security realms. O security realm é uma fonte de dados simples dos pares nome do usuário/senha e pares do nome do usuário/função. A terminologia é também usada no contexto dos contêineres da web, com um significado um pouco diferenciado.
Para autenticar um EJB para um nome de usuário específico e senha que existe com o security realm, siga as seguintes etapas:
  • Adicione um security realm ao domain controller ou servidor autônomo.
  • Adicione os seguintes parâmetros ao arquivo jboss-ejb-client.properties, que está no classpath do aplicativo. Esta amostra assume que a conexão é referida como default por outros parâmetros no arquivo. 
    remote.connection.default.username=appuser
remote.connection.default.password=apppassword
  • Crie o conector Remoto no servidor autônomo ou domain, que usa o seu novo security realm.
  • Implante o seu EJB ao grupo do servidor que é configurado para uso do perfil com o conector Remoto personalizado ou o servidor autônomo caso você não esteja usando o managed domain.
Reportar um erro

15.4.4.6. Adição do Novo Realm de Segurança

  1. Execute o CLI de Gerenciamento.

    Inicie o comando jboss-cli.sh ou jboss-cli.bat e conecte-se ao servidor.

  2. Crie um novo realm de segurança.

    Execute o seguinte comando para criar um novo security realm nomeado MyDomainRealm no domain controller ou o servidor autônomo. 
    /host=master/core-service=management/security-realm=MyDomainRealm:add()

  3. Crie as referências ao arquivo de propriedade que irá aplicar o store na informação a respeito da nova função.

    Execute o seguinte comando para criar um direcionador ao arquivo nomeado myfile.properties, que terá as propriedades pertencentes à nova função.

    Nota

    O arquivo de propriedade recentemente criado não é gerenciado pelos scripts add-user.sh e add-user.bat incluídos. Ele deve ser gerenciado externamente. 
    /host=master/core-service=management/security-realm=MyDomainRealm/authentication=properties:add(path=myfile.properties)
Resultado

O seu novo realm de segurança é criado. Quando você adicionar usuários e funções a este novo realm, a informação será stored num arquivo separado aos realms de segurança default. Você pode gerenciar este novo arquivo usando os seus próprios aplicativos e procedimentos.

Reportar um erro

15.4.4.7. Adição de um usuário ao Realm de Segurança

  1. Execute o comando add-user.sh ou add-user.bat.

    Abra um terminal e altere os diretórios para o diretório EAP_HOME/bin/. Caso você esteja executando o Red Hat Enterprise Linux ou outro sistema operacional UNIX, execute o add-user.sh. Caso você execute o Microsoft Windows Server, execute o add-user.bat.

  2. Escolha entre adicionar o Usuário de Gerenciamento ou o Usuário do Aplicativo.

    Para este procedimento, digite b para adicionar o Usuário do Aplicativo.

  3. Escolha o realm que o usuário será adicionado.

    Por default, o único realm disponível é o ApplicationRealm. Caso você tenha adicionado um realm personalizado, você pode digitar o seu nome.

  4. Digite o nome do usuário, senha e funções quando solicitado.

    Digite o nome do usuário, senha e funções quando solicitado. Verifique sua escolha digitando yes ou digite no para cancelar as alterações. As alterações são gravadas a cada um dos arquivos de propriedade para o realm de segurança.
Reportar um erro

15.4.4.8. Acesso EJB Remoto usando a Criptografia SSL

Por default, o tráfego de rede para a Invocação do Método Remoto (IMR - Remote Method Invocation RMI) dos Beans EJB2 e EJB3 não está criptografado. As instâncias onde a criptografia é requerida, Secure Sockets Layer (SSL), podem ser usadas de forma que a conexão entre o cliente e o servidor esteja criptografada. O uso do SSL possui o benefício de permitir o tráfego de rede para desviar firewalls que bloqueiam a porta RMI.
Reportar um erro

15.5. Serviços do Aplicativo JAX-RS

15.5.1. Habilitação de Segurança baseada na Função para um Serviço da Web RESTEasy JAX-RS

Sumário

O RestEasy suporta as anotações @RolesAllowed, @PermitAll e @DenyAll nos métodos JAX-RS. No entanto, ele não reconhece essas anotações por default. Siga essas etapas para configurar o arquivo web.xml e habilitar a segurança baseada na função.

Atenção

Não ative a segurança baseada na função caso o aplicativo usar os EJBs. O contêiner EJB fornecerá a funcionalidade ao invés do RESTEasy.

Procedimento 15.3. Habilitação de Segurança baseada na Função para um Serviço da Web RESTEasy JAX-RS

  1. Abra o arquivo web.xml para o aplicativo num editor de texto.
  2. Adicione o seguinte <context-param> ao arquivo com as tags web-app: 
    <context-param>
    <param-name>resteasy.role.based.security</param-name>
    <param-value>true</param-value>
</context-param>
  3. Declare todas as funções usadas com o arquivo RESTEasy JAX-RS WAR usando as tags <security-role>: 
    <security-role><role-name>ROLE_NAME</role-name></security-role><security-role><role-name>ROLE_NAME</role-name></security-role>
  4. Autorize o acesso a todos os URLs manuseados pelo período de execução JAX-RS para todas as funções: 
    <security-constraint><web-resource-collection><web-resource-name>Resteasy</web-resource-name><url-pattern>/PATH</url-pattern></web-resource-collection><auth-constraint><role-name>ROLE_NAME</role-name><role-name>ROLE_NAME</role-name></auth-constraint></security-constraint>
Resultado

A segurança baseada na função foi habilitada com o aplicativo, com um conjunto de funções definidas.

Exemplo 15.12. Amostra de Configuração de Segurança baseada na Função

<web-app>

    <context-param>
	<param-name>resteasy.role.based.security</param-name>
	<param-value>true</param-value>
    </context-param>

    <servlet-mapping>
	<servlet-name>Resteasy</servlet-name>
	<url-pattern>/*</url-pattern>
    </servlet-mapping>

    <security-constraint>
	<web-resource-collection>
	    <web-resource-name>Resteasy</web-resource-name>
	    <url-pattern>/security</url-pattern>
	</web-resource-collection>
	<auth-constraint>
	    <role-name>admin</role-name>
	    <role-name>user</role-name>
	</auth-constraint>
    </security-constraint>

    <security-role>
	<role-name>admin</role-name>
    </security-role>
    <security-role>
	<role-name>user</role-name>
    </security-role>
    
</web-app>
Reportar um erro

15.5.2. Aplique a Segurança no Serviço da Web JAX-RS usando Anotações

Sumário

Este tópico descreve as etapas para segurar o serviço da web JAX-RS usando as anotações de segurança suportadas.

Procedimento 15.4. Aplique a Segurança do Serviço da Web JAX-RS usando as Anotações de Segurança Suportada

  1. Habilite a segurança baseada na função. Para maiores informações refira-se à Seção 15.5.1, “Habilitação de Segurança baseada na Função para um Serviço da Web RESTEasy JAX-RS”
  2. Adicione anotações de segurança ao serviço da web JAX-RS. O RESTEasy suporta as seguintes anotações:
    @RolesAllowed
    Define quais funções podem acessar o método. Todas as funções devem ser definidas no arquivo web.xml.
    @PermitAll
    Permite todas as funções definidas no arquivo web.xml para acessar o método.
    @DenyAll
    Nega todos os acessos ao método.
Reportar um erro

Capítulo 16. Single Sign On (SSO - Assinatura Única)

16.1. Single Sign On (SSO - Assinatura única) para Aplicativos da Web

Visão Geral

O Single Sign On (SSO) permite a autenticação a um recurso para autorizar o acesso aos demais recursos.

SSO com e sem Cluster

O SSO sem cluster limita o compartilhamento da informação de autorização aos aplicativos de mesmo host virtual. Além disso, não existe resiliência num evento de falha do host. Os dados SSO com cluster podem ser compartilhados entre aplicativos em hosts virtuais múltiplos e são resilientes à falha. Além disso, o SSO com cluster está apto a receber solicitações a partir do balanceador de carga.

Como o SSO funciona

Caso um recurso não esteja protegido, o usuário não é solicitado a autenticá-lo. Caso um usuário acesse um recurso protegido, o usuário é solicitado a autenticá-lo.

Sob uma autenticação com êxito, as funções associadas com o usuário são stored e usadas para autorização de todos os demais recursos associados.
Caso o usuário sair do aplicativo, ou um aplicativo invalidar a sessão de forma programática, todas os dados de autorizações persistidas são removidos e o processo inicia novamente.
A sessão de intervalo não invalida a sessão SSO caso as demais funções estiverem válidas.

Limitações do SSO

Nenhuma propagação sob os limites de terceiros.
O SSO pode ser apenas usado entre aplicativos implantados com os contêineres do JBoss EAP 6.
Autenticação gerenciada apenas pelo contêiner.
Você deve usar os elementos de autenticação gerenciados pelo contêiner tais como <login-config> no seu web.xml do aplicativo.
Cookies solicitadas.
O SSO é mantido através de cookies do navegador e a regravação do URL não é suportada.
Realm e limitações do security-domain
A não ser que o parâmetro requireReauthentication seja configurado para true, todos os aplicativos da web configurados na mesma válvula SSO devem compartilhar a mesma configuração Realm no web.xml e o mesmo security domain.
Você pode aninhar o elemento Realm dentro do elemento Host ou o elemento Mecanismo ao redor, mas não dentro do elemento context.xml para um dos aplicativos da web envolvidos.
O <security-domain> configurado no jboss-web.xml deve ser consistente em todos os aplicativos da web.
Todas as integrações de segurança devem aceitar os mesmos credenciais (por exemplo, nome do usuário e senha).
Reportar um erro

16.2. Single Sign On (SSO - Assinatura Única) com Cluster para Aplicativos da Web

A configuração Single Sign On (SSO - Assinatura Única) é a habilidade que os usuários possuem de autenticar o aplicativo da web único, e quando ocorre uma autenticação com sucesso, de serem concedidos a autorização para muitos outros aplicativos. O SSO com cluster efetua o store na informação de autenticação e autorização num cache com cluster. Isto permite que aplicativos em servidores múltiplos e diferentes compartilhem a informação, além de fazer com que a informação torne-se resistente à falha de um dos hosts.
A configuração SSO chama a válvula. A válvula é conectada a um security domain, que é configurada ao nível do servidor ou grupo do servidor. Cada aplicativo que deve compartilhar a mesma informação de autenticação com cache é configurado para uso da mesma válvula. Essa configuração é feita no jboss-web.xml do aplicativo.
Algumas das válvulas SSO suportadas pelo subsistema da web do JBoss EAP incluem:
  • Apache Tomcat ClusteredSingleSignOn
  • Apache Tomcat IDPWebBrowserSSOValve
  • SPNEGO-based SSO fornecido pelo PicketLink
Dependendo do tipo específico de válvula, você precisará realizar alguma configuração adicional em seu security domain, com o objetivo de sua válvula funcionar de maneira correta.
Reportar um erro

16.3. Escolha da Correta Implementação SSO

O JBoss EAP 6 executa os aplicativos do Java Enterprise Edition (EE), que podem ser aplicativos da web, aplicativos EJB, serviços da web ou outros tipos. O Single Sign On (SSO) permite você propagar o contexto de segurança e identificar a informação entre esses aplicativos. Dependendo das necessidades de sua organização, algumas soluções diferentes estão disponíveis. A solução em que você escolhe depende de seu uso dos aplicativos da web, aplicativos EJB ou serviços da web independente de seus aplicativos serem executados no mesmo servidor ou servidores com cluster múltiplos. Além disso, se é que você precisa integrá-los a um sistema de autenticação baseada no desktop ou se você precisa apenas da autenticação entre os aplicativos entre si.
Kerberos-Based Desktop SSO

Caso sua organização já use um sistema de autorização e autenticação baseado no Kerberos, tal como o Microsoft Active Directory, você pode usar os mesmos sistemas para autenticar de maneira clara os seus aplicativos enterprise executando no JBoss EAP 6.

SSO do Aplicativo da Web e sem Cluster

Caso você necessite propagar a informação de segurança sobre os aplicativos que executam com o mesmo grupo ou instância do servidor, você pode usar um SSO sem cluster. Isto apenas envolve a configuração à válvula no seu descritor jboss-web.xml do aplicativo.

SSO do Aplicativo da Web com Cluster

Caso você precise propagar a informação de segurança entre os aplicativos sendo executados num ambiente com cluster por todas as instâncias do JBoss EAP 6, você pode usar a válvula SSO com cluster. Isto está configurado em seu jboss-web.xml do aplicativo.

Reportar um erro

16.4. Uso do Single Sign On (SSO - Assinatura Única) num Aplicativo da Web

Visão Geral

As capacidades do Single Sign On (SSO) são fornecidas pelos sistemas da web e Infinispan. Use este procedimento para configurar o SSO nos aplicativos da web.

Pré-requisitos

  • Você precisa possuir um security domain configurado do qual manuseia a autenticação e autorização.
  • O subsistema infinispan precisa estar presente. Ele está presente no perfil full-ha para um managed domain ou pelo uso da configuração standalone-full-ha.xml num servidor autônomo.
  • O webcache-container e o contêiner SSO cache devem estar presentes. Os arquivos de configuração inicial já contém o contêiner web cache e algumas das configurações já contém o contêiner SSO cache também. Use os seguintes comandos para verificar e habilitar o contêiner SSO cache. Perceba que esses comandos modificam o perfil ha do managed domain. Você pode alterar os comandos para uso do perfil diferente ou remover a porção /profile=ha do comando para o servidor autônomo.

    Exemplo 16.1. Verificação do web cache-container

    Os perfis e configurações mencionados acima incluem o web cache-container por default. Use os seguintes comandos para verificar sua presença. Caso você use um perfil diferente, substitua este nome por ha. 
    /profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=false,proxies=false,include-runtime=false,include-defaults=true)
    Caso o resultado for success, o subsistema está presente. Do contrário, você precisa adicioná-lo.

    Exemplo 16.2. Adição do web cache-container

    Use os três seguintes comandos para habilitar o web cache-container a sua configuração. Modifique o nome do perfil, conforme apropriado, assim como outros parâmetros. Esses parâmetros são aqueles usados na configuração default. 
    /profile=ha/subsystem=infinispan/cache-container=web:add(aliases=["standard-session-cache"],default-cache="repl",module="org.jboss.as.clustering.web.infinispan")
    /profile=ha/subsystem=infinispan/cache-container=web/transport=TRANSPORT:add(lock-timeout=60000)
    /profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=repl:add(mode="ASYNC",batching=true)

    Exemplo 16.3. Verificação do SSO cache-container

    Execute o seguinte comando CLI de Gerenciamento: 
    /profile=ha/subsystem=infinispan/cache-container=web/:read-resource(recursive=true,proxies=false,include-runtime=false,include-defaults=true)
    Busque por um resultado parecido com: "sso" => {
    Caso você não possa encontrá-lo, o SSO cache-container não está presente em sua configuração.

    Exemplo 16.4. Adição do SSO cache-container

    /profile=ha/subsystem=infinispan/cache-container=web/replicated-cache=sso:add(mode="SYNC", batching=true)
  • O subsistema web precisa ser configurado para uso do SSO. O seguinte comando habilita o SSO no servidor virtual chamado default-host e o cookie domain domain.com. O nome do cache é sso, e a reautenticação está desabilitada. 
    /profile=ha/subsystem=web/virtual-server=default-host/sso=configuration:add(cache-container="web",cache-name="sso",reauthenticate="false",domain="domain.com")
  • Cada aplicativo que compartilhará a informação SSO precisa ser configurado para uso do mesmo <security-domain> em seu descritor de implantação jboss-web.xml e do mesmo Realm em seu arquivo de configuração web.xml.
Diferenças entre as Válvulas SSO com e sem Cluster

O SSO com Cluster permite o compartilhamento da autenticação entre hosts separados, enquanto o SSO sem cluster não permite isto. As válvulas SSO com e sem cluster são configuradas da mesma maneira, mas o SSO com cluster inclui os parâmetros cacheConfig, processExpiresInterval e maxEmptyLife, que controlam a replicação do cluster dos dados persistidos.

Exemplo 16.5. A amostra da Configuração SSO com Cluster

Uma vez que as configurações com e sem cluster são bastante parecidas, apenas a configuração com cluster é apresentada. Essa amostra usa o security domain chamado tomcat. 
<jboss-web>
	<security-domain>tomcat</security-domain>
	<valve>
		<class-name>org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn</class-name>
		<param>
			<param-name>maxEmptyLife</param-name>
			<param-value>900</param-value>
		</param>
	</valve>
</jboss-web>

Tabela 16.1. Opções da Configuração SSO

Opções Descrição
cookieDomain
O domain do host a ser usado para o SSO cookies. O default é /. Para permitir que o app1.xyz.com e app2.xyz.com compartilhem o SSO cookies, você pode determinar o cookieDomain para xyz.com.
maxEmptyLife
O SSO com cluster apenas. O número máximo de segundos que uma válvula SSO sem sessões será usada por uma solicitação, antes da expiração. Uma válvula positiva permite um manuseamento próprio de encerramento de um nó, caso seja o único com sessão ativa anexada à válvula. Caso o maxEmptyLife seja configurado para 0, a válvula termina ao mesmo tempo que as cópias de sessão local, porém as cópias de backup das sessões a partir dos aplicativos com cluster são disponibilizadas aos outros nós. A permissão à válvula de permanecer ativa além da atividade das sessões gerenciadas permite que o usuário pare para realizar outra solicitação que pode então falhar a um nó diferente, onde isto ativa a cópia de backup da sessão. O default é de 1800 (30 minutos).
processExpiresInterval
Apenas SSO com cluster. O número mínimo de segundos entre os esforços pela válvula para encontrar e invalidar as instâncias SSO que expiraram o intervalo MaxEmptyLife. O default é 60 (1 minute).
requiresReauthentication
Caso verdadeiro, cada solicitação usa os credenciais para reautenticar o realm de segurança. Caso falso (o default), o SSO cookie válido é suficiente para a válvula autenticar cada nova solicitação.
Invalidação da Sessão

Um aplicativo pode invalidar de forma programática uma sessão invocando o método javax.servlet.http.HttpSession.invalidate().

Reportar um erro

16.5. Kerberos

O Kerberos é um protocolo de autenticação para aplicativos do cliente/servidor. Ele permite a autenticação através da rede sem segurança numa maneira segura, usando a criptografia simétrica de chave secreta.
O Kerberos usa os tokens de segurança chamados tíquetes. Para uso de um serviço com segurança, você precisa obter um tíquete a partir de um Ticket Granting Service (TGS), que é um serviço sendo executado num servidor de sua rede. Após obter o tíquete, você solicita o Service Ticket (ST) a partir de um Authentication Service (AS), que é outro serviço sendo executado em sua rede. Você precisa então usar o ST para autenticar ao serviço que você deseja. Ambos TGS e AS executam dentro de um serviço chamado Key Distribution Center (KDC).
O Kerberos é designado para ser usado num ambiente do servidor do cliente e é raramente usado nos aplicativos da web ou ambientes do cliente thin. No entanto, muitas organizações já usam um sistema Kerberos para a autenticação do desktop e preferem reusar seus sistemas existentes ao invés de criar um segundo para seus Aplicativos da Web. O Kerberos é uma parte integral do Microsoft Active Directory e é também usado em muitos ambientes do Red hat Enterprise Linux.
Reportar um erro

16.6. SPNEGO

O Simple and Protected GSS_API Negotiation Mechanism (SPNEGO) fornece um mecanismo para extensão de um ambiente Kerberos-based Single Sign On (SSO) para uso dos aplicativos da Web.
Quando um aplicativo num computador de cliente, tal como um navegador da web, tenta acesso à página de proteção no servidor da web, o servidor responde que a autorização é solicitada. O aplicativo então solicita um tíquete de serviço a partir do Kerberos Key Distribution Center (KDC). Após o tíquete ser obtido, o aplicativo o envolve numa solicitação formatada para o SPNEGO e envia de volta ao aplicativo da Web através de um navegador. O contêiner da web executando o aplicativo da Web implantado desempacota a solicitação e autentica o tíquete. O acesso é concedido sob uma autenticação com êxito.
O SPNEGO funciona com todos os tipos de provedores Kerberos, incluindo o serviço Kerberos no servidor Kerberos e no Red Hat Enterprise Linux que é uma parte integral do Microsoft Active Directory.
Reportar um erro

16.7. Microsoft Active Directory

O Microsoft Active Directory é um serviço de diretório desenvolvido pela Microsoft para autenticar usuários e computadores num domain Microsoft Windows. Isto é incluído como parte do Microsoft Windows Server. O computador no Microsoft Windows Server é referido como o domain controller. Os servidores do Red Hat Enterprise Linux executando o serviço Samba podem também agir como o domain controller neste tipo de rede.
O Active Directory baseia-se em três tecnologias core que funcionam juntas:
  • O Lightweight Directory Access Protocol (LDAP), para informação de aplicação de store sobre usuários, computadores, senhas e outros recursos.
  • O Kerberos para fornecimento da autenticação de segurança sobre a rede.
  • O Domain Name Service (DNS) para fornecimento de mapeamentos entre os endereços IP e nomes do host dos computadores e outros dispositivos na rede.
Reportar um erro

16.8. Configuração do Kerberos ou Microsoft Active Directory Desktop SSO para os Aplicativos da Web

Introdução

Para autenticar os seus aplicativos EJB ou da web usando sua infraestrutura da autorização e autenticação baseado no Kerberos existente de sua organização, tal como o Microsoft Active Directory, você pode usar as capacidades do JBoss Negotiation construídas no JBoss EAP 6. Caso você configure o seu aplicativo da web de maneira apropriada, um login da rede ou desktop é suficiente para autenticar o seu aplicativo da web, de forma que nenhuma solicitação de login adicional é requerida.

Diferença de Versões Anteriores da Plataforma

Existem poucas diferenças notáveis entre o JBoss EAP 6 e as versões anteriores:

  • Os security domains são configurados centralmente, para cada perfil de um managed domain ou de cada servidor autônomo. Eles não fazem parte da implantação. O security domain que uma implantação deve usar está nomeado no arquivo jboss-web.xml ou jboss-ejb3.xml.
  • As propriedades de segurança são configuradas como parte do security domain, como parte de sua configuração central. Elas não fazem parte da implantação.
  • Você não precisa mais substituir os autenticadores como parte de sua implantação. No entanto, você pode adicionar uma válvula ao seu descritor jboss-web.xml para atingir o mesmo efeito. A válvula continua requerendo os elementos <security-constraint> e <login-config> a serem definidos no web.xml. Eles são usados para decidir quais recursos são assegurados. No entanto, o método de autorização escolhido será substituído pela válvula do NegotiationAuthenticator no jboss-web.xml.
  • Os atributos CODE nos security domains agora usam o nome simples ao invés de um nome de classe inteiramente qualificado. As seguintes tabelas apresentam os mapeamentos entre as classes usadas para o JBoss Negotiation e suas classes.

Tabela 16.2. Códigos do Módulo de Login e Nomes de Classe

Nome Simples Nome da Classe Propósito
Kerberos com.sun.security.auth.module.Krb5LoginModule Módulo de login Kerberos
SPNEGO org.jboss.security.negotiation.spnego.SPNEGOLoginModule Os mecanismos que habilitam seus aplicativos da Web para autenticar o seu servidor de autenticação Kerberos.
AdvancedLdap org.jboss.security.negotiation.AdvancedLdapLoginModule Usado para os servidores LDAP além do Microsoft Active Directory.
AdvancedAdLdap org.jboss.security.negotiation.AdvancedADLoginModule Usado com os servidores Microsoft Active Directory LDAP.
Jboss Negotiation Toolkit

O JBoss Negotiation Toolkit é uma ferramenta de depuração que está disponível para download a partir do https://community.jboss.org/servlet/JiveServlet/download/16876-2-34629/jboss-negotiation-toolkit.war. Isto é fornecido como uma ferramenta extra para ajudá-lo a depurar e testar os mecanismos de autenticação antes da introdução de seu aplicativo à produção. Isto é uma ferramenta não suportada, porém é considerada de muita ajuda, uma vez que o SPNEGO pode ser difícil de ser configurado para os aplicativos da web.

Procedimento 16.1. Configuração da Autenticação SSO para os seus Aplicativos EJB

  1. Configure um security domain para representar a identidade do servidor. Determine as propriedades caso seja necessário.

    O primeiro security domain autentica o próprio contêiner ao serviço do diretório. Ele precisa usar um módulo de login que aceita algum tipo de mecanismo de login estático, uma vez que o usuário real não está envolvido. Esta amostra usa um principal estático e referencia um arquivo keytab que contém o credencial.
    O código XML é gerado aqui para clareza, porém você deve usar o Console de Gerenciamento ou CLI de Gerenciamento para configuração de seus security domains. 
    <security-domain name="host" cache-type="default">
   <authentication>
      <login-module code="Kerberos" flag="required">
         <module-option name="storeKey" value="true"/>
         <module-option name="useKeyTab" value="true"/>
         <module-option name="principal" value="host/testserver@MY_REALM"/>
         <module-option name="keyTab" value="/home/username/service.keytab"/>
         <module-option name="doNotPrompt" value="true"/>
         <module-option name="debug" value="false"/>
      </login-module>
   </authentication>
</security-domain>

  2. Configure o segundo security domain para assegurar o aplicativo da web ou aplicativos. Determine as propriedades do sistema caso seja necessário.

    O segundo security domain é usado para autenticar o usuário individual ao Kerberos ou servidor de autenticação SPNEGO. Você precisa de pelo menos um módulo de login para autenticação do usuário e outro para buscar as funções a serem aplicadas ao usuário. O seguinte código XML apresenta um modelo de autorização para mapeamento das funções no próprio servidor de autenticação. 
    <security-domain name="SPNEGO" cache-type="default">
   <authentication>
      <!-- Check the username and password -->
      <login-module code="SPNEGO"  flag="requisite">
         <module-option name="password-stacking" value="useFirstPass"/>
         <module-option name="serverSecurityDomain" value="host"/>
      </login-module>
      <!-- Search for roles -->
      <login-module code="UsersRoles" flag="required">
         <module-option name="password-stacking" value="useFirstPass" />
         <module-option name="usersProperties" value="spnego-users.properties" />
         <module-option name="rolesProperties" value="spnego-roles.properties" />
      </login-module> 
   </authentication>
</security-domain>

  3. Especifique o security-constraint e login-config no web.xml

    O descritor web.xml contém informação sobre as restrições de segurança e configuração de login. Segue abaixo algumas amostras de valores para cada uma. 
    <security-constraint>
   <display-name>Security Constraint on Conversation</display-name>
   <web-resource-collection>
      <web-resource-name>examplesWebApp</web-resource-name>
      <url-pattern>/*</url-pattern>
   </web-resource-collection>
   <auth-constraint>
   <role-name>RequiredRole</role-name>
   </auth-constraint>
</security-constraint>

<login-config>
   <auth-method>SPNEGO</auth-method>
   <realm-name>SPNEGO</realm-name>
</login-config>
 
<security-role>
   <description> role required to log in to the Application</description>
   <role-name>RequiredRole</role-name>
</security-role>

  4. Especifique o security domain e outras configurações no descritor jboss-web.xml.

    Especifique o nome do security domain ao lado do cliente (a segunda amostra) no descritor jboss-web.xml de sua implantação para direcionar o seu aplicativo para uso de seu security domain.
    Você não pode mais substituir os autenticadores diretamente. Ao invés disto, você pode adicionar o NegotiationAuthenticator como um valor ao seu descritor jboss-web.xml, caso seja necessário. O <jacc-star-role-allow> permite você usar o caractere (*) de asterisco para coincidir com os nomes de função múltiplos e é opcional. 
    <jboss-web>
   <security-domain>java:/jaas/SPNEGO</security-domain>
   <valve>
      <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
   </valve>
   <jacc-star-role-allow>true</jacc-star-role-allow>
</jboss-web>

  5. Adicione uma dependência ao seu MANIFEST.MF do aplicativo para localizar as classes de Negociação.

    O aplicativo da web precisa de uma dependência no org.jboss.security.negotiation da classe a ser adicionada ao manifesto do META-INF/MANIFEST.MF da implantação, com o objetivo de localizar as classes do JBoss Negotiation. Segue abaixo uma entrada propriamente formatada. 
    Manifest-Version: 1.0
Build-Jdk: 1.6.0_24
Dependencies: org.jboss.security.negotiation
Resultado

O seu aplicativo da web aceita e autentica os credenciais em relação ao Kerberos, Microsoft Directory ou outro serviço do diretório compatível com o SPNEGO. Caso o usuário executar o aplicativo a partir de um sistema que já está conectado ao serviço do diretório, e onde as funções solicitadas já são aplicadas ao usuário, o aplicativo da web não solicita a autenticação e as capacidade SSO são atingidas.

Reportar um erro

Capítulo 17. Segurança baseada na Função nos Aplicativos

17.1. Arquitetura de Extensão de Segurança

A arquitetura das extensões de segurança do JBoss EAP 6 consiste de três partes. Essas três partes conectam seu aplicativo à sua infraestrutura de segurança subjacente, se é que é LDAP, Kerberos ou outro sistema externo.
JAAS

A primeira parte da infraestrutura é o JAAS API. O JAAS é um framework plugável que fornece uma camada de abstração entre a sua infraestrutura de segurança e seu aplicativo.

A implementação principal no JAAS é org.jboss.security.plugins.JaasSecurityManager, que implementa as interfaces AuthenticationManager e RealmMapping. O JaasSecurityManager integra o EJB e camadas do contêiner da web, baseado no elemento <security-domain> do descritor de implantação do componente correspondente.
Refira-se à Seção 17.2, “Java Authentication and Authorization Service (JAAS)” para maiores informações sobre o JAAS.
O JaasSecurityManagerService MBean

O serviço JaasSecurityManagerService MBean coordena os gerenciadores de segurança. Embora seu nome inicie com Jaas, os gerenciadores de segurança que este serviço gerencia não precisam usar o JAAS em suas implementações. O nome reflete o fato de que a implementação do gerenciador de segurança default é o JaasSecurityManager.

A função primária do JaasSecurityManagerService é externalizar a implementação do gerenciador de segurança. Você pode alterar a implementação do gerenciador de segurança fornecendo uma implementação alternativa das interfaces AuthenticationManager e RealmMapping.
A segunda função fundamental do JaasSecurityManagerService é fornecer uma implementação JNDI javax.naming.spi.ObjectFactory para permitir um gerenciamento simples sem código do binding entre o nome JNDI e a implementação do gerenciador de segurança. Para habilitar a segurança, especifique o nome JNDI da implementação do gerenciador de segurança através do elemento descritor de implantação <security-domain>.
Quando você especifica o nome JNDI, é necessário que um object-binding esteja existente. Com o objetivo de simplificar a configuração entre o nome JNDI e o gerenciador de segurança, o JaasSecurityManagerService efetua o bind no next naming system reference, nomeando-se como JNDI ObjectFactory sob o nome java:/jaas. Isto permite uma convenção de nomeação na forma de java:/jaas/XYZ como valor para o elemento <security-domain> e que a instância do gerenciador de segurança para o security domain XYZ seja criada conforme o necessário. Tudo isto, pela criação de uma instância de classe especificada pelo atributo SecurityManagerClassName, usando um construtor que leva o nome do security domain.

Nota

Você não precisa incluir o prefixo java:/jaas em seu descritor da implantação. No entanto, você poderá incluí-lo para compatibilidade reversa, porém isto é ignorado.
O JaasSecurityDomain MBean

O org.jboss.security.plugins.JaasSecurityDomain é uma extensão do JaasSecurityManager que adiciona a noção de um KeyStore, KeyManagerFactory e um TrustManagerFactory para suporte do SSL e outros de uso de criptografia.

Maiores Informações

Por favor refira-se à Seção 17.3, “Java Authentication and Authorization Service (JAAS)” para maiores informações e exemplos práticos sobre a arquitetura de segurança.

Reportar um erro

17.2. Java Authentication and Authorization Service (JAAS)

O Java Authentication and Authorization Service (JAAS) é um API de segurança que consiste de um conjunto de pacotes Java designados para a autorização e autenticação do usuário. O API é uma implementação Java do framework Pluggable Authentication Modules (PAM - Módulos de Autenticação Plugável). Isto estende a arquitetura de controle de acesso do Java Enterprise Edition para suporte de autorização baseado no usuário.
No JBoss EAP 6, o JAAS apenas fornece segurança baseada na função declarativa. Refira-se à Seção 2.1, “Segurança Declarativa” para maiores informações sobre a segurança declarativa.
O JAAS é independente de quaisquer tecnologias de autenticação subjacente, tais como Kerberos ou LDAP. Você pode alterar sua estrutura de segurança subjacente sem alteração de seu aplicativo. Você apenas precisa alterar a configuração JAAS.
Reportar um erro

17.3. Java Authentication and Authorization Service (JAAS)

A arquitetura de segurança do JBoss EAP 6 é composta de um subsistema de configuração de segurança, configurações de segurança específica do aplicativo que já são incluídas em diversos arquivos de configuração com o aplicativo e o JAAS Security Manager, que é implementado como um MBean.
Configuração Específica do Servidor, Grupo do Servidor e Domain

Os grupos do servidor (num managed domain) e servidores (no servidor autônomo) incluem a configuração para os security domains. O security domain inclui a informação a respeito da combinação da autenticação, autorização, mapeamento e módulos de auditoria com detalhes de configuração. Um aplicativo especifica qual security domain ele requer, pelo nome no próprio jboss-web.xml.

Configuração específica do Aplicativo

A configuração específica do aplicativo assume um ou mais dos seguintes arquivos:

Tabela 17.1. Arquivos de Configuração Específica do Aplicativo

Arquivo Descrição
ejb-jar.xml
O descritor da implantação para o aplicativo Enterprise JavaBean (EJB) localizado no diretório META-INF do EJB. Use o ejb-jar.xml para especificar as funções e as mapeie aos principals no nível do aplicativo. Você pode também limitar os métodos específicos e as classes de certas funções. Isto é também utilizado para outra configuração específica do EJB não relacionada à segurança.
web.xml
O descritor de implantação do aplicativo da web Java Enterprise Edition (EE). Use o web.xml para declarar o security domain que o aplicativo usa para autenticação e autorização, assim como restrições de transporte e recurso para o aplicativo, tais como a limitação dos tipos de solicitações HTTP permitidas. Você pode configurar uma autenticação baseada na web simples neste arquivo. Isto é também usado para outra configuração específica do aplicativo não relacionada com a segurança.
jboss-ejb3.xml
Contém as extensões específicas do JBoss para o descritor ejb-jar.xml.
jboss-web.xml
Contém as extensões específicas do JBoss ao descritor web.xml.

Nota

O ejb-jar.xml e web.xml estão definidos na especificação do Java Enterprise Edition (Java EE). O jboss-ejb3.xml fornece extensões específicas do JBoss para o ejb-jar.xml e o jboss-web.xml fornece extensões específicas do JBoss para o web.xml.
JAAS Security Manager MBean

O Java Authentication and Authorization Service (JAAS) é um framework para segurança à nível do usuário nos aplicativos Java, usando os pluggable authentication modules (PAM - módulos de autenticação plugáveis). Ele está integrado no Java Runtime Environment (JRE). O componente ao lado do contêiner é o org.jboss.security.plugins.JaasSecurityManager MBean no JBoss EAP 6. Ele fornece as implementações default das interfaces AuthenticationManagere RealmMapping.

O JaasSecurityManager MBean integra as camadas do web contêiner e EJB baseadas no security domain especificado no EJB e arquivos do descritor de implantação da web no aplicativo. Quando um aplicativo implanta, o contêiner associa o security domain especificado no descritor de implantação com a instância do gerenciador de segurança do contêiner. O gerenciador de segurança reforça a configuração do security domain conforme configurado no grupo de servidor ou servidor autônomo.
Fluxo de Interação entre o Cliente e o Contêiner com o JAAS

O JaasSecurityManager usa os pacotes JAAS para implantar o comportamento da interface do AuthenticationManager e RealmMapping. Na realidade, seu comportamento deriva da execução das instâncias do módulo de login que são configuradas no security domain pelo qual o JaasSecurityManager foi determinado. Os módulos de login implementam a autenticação principal do security domain e comportamento de mapeamento de função. Você pode usar o JaasSecurityManager por todos os security domains pelo plugging em configurações para os domains.

Para ilustrar como o JaasSecurityManager usa o processo de autenticação, siga as etapas seguintes sobre a invocação do cliente do método que implementa o método EJBHome. O EJB já foi implantado no servidor e seus métodos de interface EJBHome foram assegurados usando os elementos <method-permission> no descritor ejb-jar.xml. Ele usa o security domain jwdomain, que é especificado no elemento <security-domain> do arquivo jboss-ejb3.xml. A imagem abaixo apresenta as etapas que serão explicadas mais tarde:
Etapas de autenticação para um EJB

Figura 17.1. Etapas da Invocação do Método EJB com Segurança

  1. O cliente executa o login JAAS para estabelecer o principal e credenciais para autenticação. Isto é o Client Side Login rotulado na figura. Isto pode ser também executado na forma de JNDI.
    Para executar um login JAAS, você cria uma instância de LoginContext e passa o nome de configuração para uso. Neste caso, o nome da configuração é other. Este login associa de uma vez só o principal do login e credenciais com todas as invocações de método EJB subsequente. Este processo não autentica o usuário necessariamente. A natureza do login ao lado do cliente depende da configuração do módulo de login que o cliente usa. Nesta amostra, a entrada da configuração de login ao lado do cliente other usa o módulo de login ClientLoginModule. Este módulo efetua o bind no nome do usuário e senha à camada de invocação EJB para autenticação mais tarde no servidor. A autenticação do cliente não é autenticado no cliente.
  2. O cliente obtém o método EJBHome e o invoca no servidor. A invocação inclui os argumentos do método passados ao cliente, juntamente com a identidade do usuário e credenciais a partir do login JAAS ao lado do cliente.
  3. No lado do servidor, o servidor de segurança autentica o usuário que invocou o método. Isto envolve outro login JAAS.
  4. O security domain na parte inferior determina a escolha dos módulos de login. O nome do security domain é passado ao construtor LoginContext como o nome de entrada da configuração do login. O security domain é jwdomain. Caso a autenticação for bem sucedida, o JAAS Subject é criado. O JAAS subject inclui PrincipalSet, que inclui os seguintes credenciais:
    • A instância java.security.Principal que corresponde à identidade do cliente a partir do ambiente de segurança da implantação.
    • Um java.security.acl.Group chamado Roles que contém os nomes da função do domain do aplicativo do usuário. Os objetos org.jboss.security.SimplePrincipal do tipo representam os nomes da função. Essas funções validam o acesso aos métodos EJB de acordo com as restrições no ejb-jar.xml e implementação do método EJBContext.isCallerInRole(String).
    • O java.security.acl.Group opcional nomeado CallerPrincipal, que contém um org.jboss.security.SimplePrincipal único que corresponde à identidade do chamador do domain do aplicativo. O associado do grupo CallerPrincipal é o valor retornado pelo método EJBContext.getCallerPrincipal(). Este mapeamento permite que o Principal no ambiente de segurança operacional mapeie um Principal conhecido pelo aplicativo. Na ausência do mapeamento CallerPrincipal, o principal operacional é o mesmo do principal do domain do aplicativo.
  5. O servidor verifica que o usuário chamando o método EJB possui permissão. A execução desta autorização envolve as seguintes etapas:
    • Obtém os nomes de funções para acesso do método EJB a partir do contêiner EJB. Os nomes de funções são determinados pelos elementos <role-name> do descritor ejb-jar.xml de todos os elementos <method-permission> contendo o método invocado.
    • Caso nenhuma das funções seja determinada ou o método especificado num elemento de lista exclusivo, o acesso ao método é 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 determinado. Esse método interage através dos nomes de função e verifica se o grupo Subject Roles do usuário autenticado contém um SimplePrincipal com o nome da função determinado. O acesso é permitido caso o nome da função seja um associado do grupo Funções. O acesso é negado caso nenhum dos nomes de função seja associado.
    • Caso o EJB use um proxy de segurança personalizado, a invocação do método é delegada do proxy. Caso o proxy de segurança negar acesso ao chamador, ele lança um java.lang.SecurityException. Do contrário, o acesso ao método EJB é permitido e a invocação do método passa ao próximo interceptor do contêiner. O SecurityProxyInterceptor manuseia esta checagem e este interceptor não é apresentado.
    • Para as solicitações da conexão, o servidor da web verifica as restrições de segurança definidas no web.xml que combinam com o recurso solicitado e o método HTTP acessado.
      Caso a restrição existir para a solicitação, o servidor da web chama o JaasSecurityManager para executar a autenticação principal, que em troca garante que as funções do usuário são associadas com o objeto principal.
Reportar um erro

17.4. Uso do Security Domain em seu Aplicativo

Visão Geral

Para uso de um security domain em seu aplicativo, primeiro você precisa configurar o domain tanto no arquivo de configuração do servidor ou arquivo descritor do aplicativo. Então, você deve adicionar as anotações requeridas ao EJB que usam isto. Este tópico descreve as etapas solicitadas para uso de um security domain em seu aplicativo.

Procedimento 17.1. Configure o seu Aplicativo para Uso de um Security Domain

  1. Definição do Security Domain

    Você pode definir o security domain tanto no arquivo de configuração do servidor ou arquivo descritor aplicativo.

    • Configuração do security domain no arquivo de configuração do servidor.

      O security domain é configurado no subsistema security do arquivo de configuração do servidor. Caso a instância do JBoss EAP 6 estiver sendo executada num managed domain, este é o arquivo domain/configuration/domain.xml. Caso a instância do JBoss EAP 6 estiver sendo executada como um servidor autônomo, este é o arquivo standalone/configuration/standalone.xml.
      Os security domains other, jboss-web-policy e jboss-ejb-policy são fornecidos por default no JBoss EAP 6. A seguinte amostra XML foi copiada a partir do subsistema security no arquivo de configuração do servidor. 
      <subsystem xmlns="urn:jboss:domain:security:1.2">
    <security-domains>
        <security-domain name="other" cache-type="default">
            <authentication>
                <login-module code="Remoting" flag="optional">
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
                <login-module code="RealmDirect" flag="required">
                    <module-option name="password-stacking" value="useFirstPass"/>
                </login-module>
            </authentication>
        </security-domain>
        <security-domain name="jboss-web-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
        <security-domain name="jboss-ejb-policy" cache-type="default">
            <authorization>
                <policy-module code="Delegating" flag="required"/>
            </authorization>
        </security-domain>
    </security-domains>
</subsystem>
      Você pode configurar os security domains adicionais conforme seja necessário usando o Console de Gerenciamento ou CLI.

    • Configuração do security domain no arquivo do descritor do aplicativo

      O security domain é especificado no elemento filho <security-domain> do elemento <jboss-web> no arquivo WEB-INF/jboss-web.xml do aplicativo. A seguinte amostra configura o security domain nomeado my-domain. 
      <jboss-web>
    <security-domain>my-domain</security-domain>
</jboss-web>
      Esta é uma das muitas configurações que você pode especificar no descritor WEB-INF/jboss-web.xml.

  2. Adição da Anotação Requerida para o EJB

    Você configura a segurança no EJB usando as anotações @SecurityDomain e @RolesAllowed. A seguinte amostra de código EJB limita o acesso ao security domain other por usuários na função guest. 
    package example.ejb3;

import java.security.Principal;

import javax.annotation.Resource;
import javax.annotation.security.RolesAllowed;
import javax.ejb.SessionContext;
import javax.ejb.Stateless;

import org.jboss.ejb3.annotation.SecurityDomain;

/**
 * Simple secured EJB using EJB security annotations
 * Allow access to "other" security domain by users in a "guest" role.
 */
@Stateless
@RolesAllowed({ "guest" })
@SecurityDomain("other")
public class SecuredEJB {

   // Inject the Session Context
   @Resource
   private SessionContext ctx;

   /**
    * Secured EJB method using security annotations
    */
   public String getSecurityInfo() {
      // Session context injected using the resource annotation
      Principal principal = ctx.getCallerPrincipal();
      return principal.toString();
   }
}
    Para maiores amostras de código, consulte o ejb-security quickstart do pacote do JBoss EAP 6 Quickstarts, disponível a partir do Portal do Cliente Red Hat.
Reportar um erro

17.5. Uso da Segurança baseada na Função nos Servlets

Para adicionar a segurança a um servlet, você precisa mapear cada servlet a um padrão de URL e criar restrições de segurança nos padrões do URL que precisam ser protegidos. As restrições de segurança limitam o acesso aos URLs e funções. A autenticação e autorização são manuseadas pelo security domain especificados no jboss-web.xml do WAR.
Pré-requisitos

Antes de você usar a segurança baseada na função num servlet, o security domain usado para autenticar e autorizar o acesso precisa ser configurado no contêiner do JBoss EAP 6.

Procedimento 17.2. Adição da Segurança baseada na Função aos Servlets

  1. Adição dos mapeamentos entre os padrões servlets e URL.

    Use os elementos <servlet-mapping> no web.xml para mapear os servlets individuais aos padrões URL. A seguinte amostra mapeia o servlet chamado DisplayOpResult ao /DisplayOpResult default de URL. 
    <servlet-mapping>
    <servlet-name>DisplayOpResult</servlet-name>
    <url-pattern>/DisplayOpResult</url-pattern>
</servlet-mapping>

  2. Adição das restrições de segurança nos padrões URL.

    Para mapear o default URL a uma restrição de segurança, use o <security-constraint>. A seguinte amostra de acesso às restrições a partir do /DisplayOpResult default de URL a ser acessado pelos principals com o eap_admin da função. A função necessita estar presente no security domain. 
    <security-constraint>
	<display-name>Restrict access to role eap_admin</display-name>
	<web-resource-collection>
		<web-resource-name>Restrict access to role eap_admin</web-resource-name>
		<url-pattern>/DisplayOpResult/*</url-pattern>
	</web-resource-collection>
	<auth-constraint>
		<role-name>eap_admin</role-name>
	</auth-constraint>	
</security-constraint>	

<security-role>
  <role-name>eap_admin</role-name>
</security-role>


<login-config>
    <auth-method>BASIC</auth-method>
</login-config>
    Você precisa especificar o método de autenticação, que pode ser qualquer um dos seguintes: BASIC, FORM, DIGEST, CLIENT-CERT, SPNEGO. Essa amostra usa a autenticação BASIC.

  3. Especificação do security domain no jboss-web.xml do WAR.

    Adicione o security domain ao jboss-web.xml do WAR com o objetivo de conectar os servlets ao security domain configurado, que sabe como autenticar e autorizar os principals em referências de segurança. A seguinte amostra usa o security domain chamado acme_domain. 
    <jboss-web>
	...
	<security-domain>acme_domain</security-domain>
	...
</jboss-web>

Exemplo 17.1. Amostra web.xml com a Segurança configurada baseada na função

<web-app xmlns="http://java.sun.com/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
         version="3.0">

<display-name>Use Role-Based Security In Servlets</display-name>

<welcome-file-list>
  <welcome-file>/index.jsp</welcome-file>
</welcome-file-list>

<servlet-mapping>
    <servlet-name>DisplayOpResult</servlet-name>
    <url-pattern>/DisplayOpResult</url-pattern>
</servlet-mapping>

<security-constraint>
  <display-name>Restrict access to role eap_admin</display-name>
    <web-resource-collection>
      <web-resource-name>Restrict access to role eap_admin</web-resource-name>
      <url-pattern>/DisplayOpResult/*</url-pattern>
      </web-resource-collection>
      <auth-constraint>
        <role-name>eap_admin</role-name>
      </auth-constraint>
    </security-constraint>

    <security-role>
      <role-name>eap_admin</role-name>
    </security-role>

    <login-config>
        <auth-method>BASIC</auth-method>
    </login-config>

</web-app>
Reportar um erro

17.6. Uso do Sistema de Autenticação de Terceiros no seu Aplicativo

Você pode integrar os sistemas de segurança de terceiros com o JBoss EAP 6- Esses tipos de sistemas são normalmente baseados em token. O sistema externo executa a autenticação e passa o token de volta ao aplicativo da Web através de cabeçalhos de solicitação. Isto é normalmente referido como perimeter authentication. Adicione uma válvula de autenticação personalizada com o objetivo de configurar a autenticação do perímetro em seu aplicativo. Caso você possuir uma válvula do provedor de terceiros, certifique-se de que isto está no seu classpath e siga as amostras abaixo, juntamente com a documentação para seu módulo de autenticação de terceiros.

Nota

A localização para configuração de válvulas alterou no JBoss EAP 6. Não existe mais um descritor de implantação context.xml. As válvulas são configuradas diretamente no descritor jboss-web.xml. O context.xml é agora ignorado.

Exemplo 17.2. Válvula de Autenticação Básica

<jboss-web>
  <valve>
    <class-name>org.jboss.security.negotiation.NegotiationAuthenticator</class-name>
  </valve>
</jboss-web>
Esta válvula é usada para o SSO baseado no Kerberos. Ela também apresenta o padrão mais simples para especificação do autenticador de terceiro no seu aplicativo da Web.

Exemplo 17.3. Conjunto de Atributos do Cabeçalho com a Válvula Personalizada

<jboss-web>
  <valve>
    <class-name>org.jboss.web.tomcat.security.GenericHeaderAuthenticator</class-name>
    <param>
      <param-name>httpHeaderForSSOAuth</param-name>
      <param-value>sm_ssoid,ct-remote-user,HTTP_OBLIX_UID</param-value>
    </param>
    <param>
      <param-name>sessionCookieForSSOAuth</param-name>
      <param-value>SMSESSION,CTSESSION,ObSSOCookie</param-value>
    </param>
  </valve>
</jboss-web>
Esta amostra apresenta como configurar os atributos personalizados em sua válvula. O autenticador verifica a presença da ID do cabeçalho e a chave da sessão e passa-as ao framework JAAS que dirige a camada de segurança, assim como o nome do usuário e senha da válvula. Você precisa de um módulo de login JAAS personalizado que pode processar o nome do usuário e senha, além de popular o assunto com as funções corretas. Caso nenhum dos valores de cabeçalho coincidirem com os valores configurados, as semânticas de autenticação baseadas na forma regular serão aplicadas.
Gravação a um Autenticador Personalizado

A gravação de seu próprio autenticador não encontra-se no contexto desta documentação. No entanto, o seguinte código Java é fornecido como uma amostra.

Exemplo 17.4. GenericHeaderAuthenticator.java

/*
 * JBoss, Home of Professional Open Source.
 * Copyright 2006, Red Hat Middleware LLC, and individual contributors
 * as indicated by the @author tags. See the copyright.txt file in the
 * distribution for a full listing of individual contributors.
 *
 * This is free software; you can redistribute it and/or modify it
 * under the terms of the GNU Lesser General Public License as
 * published by the Free Software Foundation; either version 2.1 of
 * the License, or (at your option) any later version.
 *
 * This software is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
 * Lesser General Public License for more details.
 *
 * You should have received a copy of the GNU Lesser General Public
 * License along with this software; if not, write to the Free
 * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
 * 02110-1301 USA, or see the FSF site: http://www.fsf.org.
 */
 
package org.jboss.web.tomcat.security;

import java.io.IOException;
import java.security.Principal;
import java.util.StringTokenizer;

import javax.management.JMException;
import javax.management.ObjectName;
import javax.servlet.http.Cookie;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.catalina.Realm;
import org.apache.catalina.Session;
import org.apache.catalina.authenticator.Constants;
import org.apache.catalina.connector.Request;
import org.apache.catalina.connector.Response;
import org.apache.catalina.deploy.LoginConfig;
import org.jboss.logging.Logger;

import org.jboss.as.web.security.ExtendedFormAuthenticator;

/**
 * JBAS-2283: Provide custom header based authentication support
 * 
 * Header Authenticator that deals with userid from the request header Requires
 * two attributes configured on the Tomcat Service - one for the http header
 * denoting the authenticated identity and the other is the SESSION cookie
 * 
 * @author <a href="mailto:Anil.Saldhana@jboss.org">Anil Saldhana</a>
 * @author <a href="mailto:sguilhen@redhat.com">Stefan Guilhen</a>
 * @version $Revision$
 * @since Sep 11, 2006
 */
public class GenericHeaderAuthenticator extends ExtendedFormAuthenticator {
  protected static Logger log = Logger
      .getLogger(GenericHeaderAuthenticator.class);

  protected boolean trace = log.isTraceEnabled();

  // JBAS-4804: GenericHeaderAuthenticator injection of ssoid and
  // sessioncookie name.
  private String httpHeaderForSSOAuth = null;

  private String sessionCookieForSSOAuth = null;

  /**
   * <p>
   * Obtain the value of the <code>httpHeaderForSSOAuth</code> attribute. This
   * attribute is used to indicate the request header ids that have to be
   * checked in order to retrieve the SSO identity set by a third party
   * security system.
   * </p>
   * 
   * @return a <code>String</code> containing the value of the
   *         <code>httpHeaderForSSOAuth</code> attribute.
   */
  public String getHttpHeaderForSSOAuth() {
    return httpHeaderForSSOAuth;
  }

  /**
   * <p>
   * Set the value of the <code>httpHeaderForSSOAuth</code> attribute. This
   * attribute is used to indicate the request header ids that have to be
   * checked in order to retrieve the SSO identity set by a third party
   * security system.
   * </p>
   * 
   * @param httpHeaderForSSOAuth
   *            a <code>String</code> containing the value of the
   *            <code>httpHeaderForSSOAuth</code> attribute.
   */
  public void setHttpHeaderForSSOAuth(String httpHeaderForSSOAuth) {
    this.httpHeaderForSSOAuth = httpHeaderForSSOAuth;
  }

  /**
   * <p>
   * Obtain the value of the <code>sessionCookieForSSOAuth</code> attribute.
   * This attribute is used to indicate the names of the SSO cookies that may
   * be present in the request object.
   * </p>
   * 
   * @return a <code>String</code> containing the names (separated by a
   *         <code>','</code>) of the SSO cookies that may have been set by a
   *         third party security system in the request.
   */
  public String getSessionCookieForSSOAuth() {
    return sessionCookieForSSOAuth;
  }

  /**
   * <p>
   * Set the value of the <code>sessionCookieForSSOAuth</code> attribute. This
   * attribute is used to indicate the names of the SSO cookies that may be
   * present in the request object.
   * </p>
   * 
   * @param sessionCookieForSSOAuth
   *            a <code>String</code> containing the names (separated by a
   *            <code>','</code>) of the SSO cookies that may have been set by
   *            a third party security system in the request.
   */
  public void setSessionCookieForSSOAuth(String sessionCookieForSSOAuth) {
    this.sessionCookieForSSOAuth = sessionCookieForSSOAuth;
  }

  /**
   * <p>
   * Creates an instance of <code>GenericHeaderAuthenticator</code>.
   * </p>
   */
  public GenericHeaderAuthenticator() {
    super();
  }

  public boolean authenticate(Request request, HttpServletResponse response,
      LoginConfig config) throws IOException {
    log.trace("Authenticating user");

    Principal principal = request.getUserPrincipal();
    if (principal != null) {
      if (trace)
        log.trace("Already authenticated '" + principal.getName() + "'");
      return true;
    }

    Realm realm = context.getRealm();
    Session session = request.getSessionInternal(true);

    String username = getUserId(request);
    String password = getSessionCookie(request);

    // Check if there is sso id as well as sessionkey
    if (username == null || password == null) {
      log.trace("Username is null or password(sessionkey) is null:fallback to form auth");
      return super.authenticate(request, response, config);
    }
    principal = realm.authenticate(username, password);

    if (principal == null) {
      forwardToErrorPage(request, response, config);
      return false;
    }

    session.setNote(Constants.SESS_USERNAME_NOTE, username);
    session.setNote(Constants.SESS_PASSWORD_NOTE, password);
    request.setUserPrincipal(principal);

    register(request, response, principal, HttpServletRequest.FORM_AUTH,
        username, password);
    return true;
  }

  /**
   * Get the username from the request header
   * 
   * @param request
   * @return
   */
  protected String getUserId(Request request) {
    String ssoid = null;
    // We can have a comma-separated ids
    String ids = "";
    try {
      ids = this.getIdentityHeaderId();
    } catch (JMException e) {
      if (trace)
        log.trace("getUserId exception", e);
    }
    if (ids == null || ids.length() == 0)
      throw new IllegalStateException(
          "Http headers configuration in tomcat service missing");

    StringTokenizer st = new StringTokenizer(ids, ",");
    while (st.hasMoreTokens()) {
      ssoid = request.getHeader(st.nextToken());
      if (ssoid != null)
        break;
    }
    if (trace)
      log.trace("SSOID-" + ssoid);
    return ssoid;
  }

  /**
   * Obtain the session cookie from the request
   * 
   * @param request
   * @return
   */
  protected String getSessionCookie(Request request) {
    Cookie[] cookies = request.getCookies();
    log.trace("Cookies:" + cookies);
    int numCookies = cookies != null ? cookies.length : 0;

    // We can have comma-separated ids
    String ids = "";
    try {
      ids = this.getSessionCookieId();
      log.trace("Session Cookie Ids=" + ids);
    } catch (JMException e) {
      if (trace)
        log.trace("checkSessionCookie exception", e);
    }
    if (ids == null || ids.length() == 0)
      throw new IllegalStateException(
          "Session cookies configuration in tomcat service missing");

    StringTokenizer st = new StringTokenizer(ids, ",");
    while (st.hasMoreTokens()) {
      String cookieToken = st.nextToken();
      String val = getCookieValue(cookies, numCookies, cookieToken);
      if (val != null)
        return val;
    }
    if (trace)
      log.trace("Session Cookie not found");
    return null;
  }

  /**
   * Get the configured header identity id in the tomcat service
   * 
   * @return
   * @throws JMException
   */
  protected String getIdentityHeaderId() throws JMException {
    if (this.httpHeaderForSSOAuth != null)
      return this.httpHeaderForSSOAuth;
    return (String) mserver.getAttribute(new ObjectName(
        "jboss.web:service=WebServer"), "HttpHeaderForSSOAuth");
  }

  /**
   * Get the configured session cookie id in the tomcat service
   * 
   * @return
   * @throws JMException
   */
  protected String getSessionCookieId() throws JMException {
    if (this.sessionCookieForSSOAuth != null)
      return this.sessionCookieForSSOAuth;
    return (String) mserver.getAttribute(new ObjectName(
        "jboss.web:service=WebServer"), "SessionCookieForSSOAuth");
  }

  /**
   * Get the value of a cookie if the name matches the token
   * 
   * @param cookies
   *            array of cookies
   * @param numCookies
   *            number of cookies in the array
   * @param token
   *            Key
   * @return value of cookie
   */
  protected String getCookieValue(Cookie[] cookies, int numCookies,
      String token) {
    for (int i = 0; i < numCookies; i++) {
      Cookie cookie = cookies[i];
      log.trace("Matching cookieToken:" + token + " with cookie name="
          + cookie.getName());
      if (token.equals(cookie.getName())) {
        if (trace)
          log.trace("Cookie-" + token + " value=" + cookie.getValue());
        return cookie.getValue();
      }
    }
    return null;
  }
}
Reportar um erro

Capítulo 18. Migração

18.1. Configuração das Alterações de Segurança do Aplicativo

Configure a segurança para a autenticação básica

Nas versões anteriores do JBoss EAP, os arquivos de propriedades posicionados no diretório EAP_HOME/server/SERVER_NAME/conf/ estavam no classpath e poderiam ser facilmente encontrados pelo UsersRolesLoginModule. No JBoss EAP 6, a estrutura do diretório foi alterada. Os arquivos da propriedade devem ser empacotados com aplicativo para disponibilizá-los no classpath.

Importante

Você deve interromper o servidor antes de editar o arquivo de configuração do servidor para que sua alteração seja persistida na iniciação do servidor.
Para configurar a segurança para uma autenticação básica, adicione um novo security domain sob o security-domains para o standalone/configuration/standalone.xml ou o arquivo de configuração do servidor domain/configuration/domain.xml: 
<security-domain name="example">
    <authentication>
        <login-module code="UsersRoles" flag="required">
            <module-option name="usersProperties" 
                    value="${jboss.server.config.dir}/example-users.properties"/>
            <module-option name="rolesProperties" 
                    value="${jboss.server.config.dir}/example-roles.properties"/>
        </login-module>
    </authentication>
</security-domain>
Caso a instância do JBoss EAP 6 estiver sendo executada como um servidor autônomo, o ${jboss.server.config.dir} refere-se ao diretório EAP_HOME/standalone/configuration/. Caso a instância estiver executando num managed domain, o ${jboss.server.config.dir} refere-se ao diretório EAP_HOME/domain/configuration/.
Modificação dos nomes do security domain

Os security domains não usam mais o prefixo java:/jaas/ em seus nomes no JBoss EAP 6.

  • Você deve remover esse prefixo das configurações do security domain para os aplicativos da Web no jboss-web.xml.
  • Você deve remover esse prefixo das configurações do security domain para os aplicativos Enterprise no jboss-web.xml. Esse arquivo foi substituído pelo jboss.xml no JBoss EAP 6.

Reportar um erro

Apêndice A. Referência

A.1. Módulos de Autenticação Incluídos

Os seguintes módulos de autenticação estão incluídos no JBoss EAP 6. Algumas dessas autorizações de manuseio como também de autenticação. Isto inclui normalmente a palavra Role com o nome Code.
Quando você configurar esses módulos, use o valor Code ou o nome completo (pacote qualificado) para referir-se ao module.jaa

Módulos de Autenticação

Tabela A.1. Módulos de Login

Código Classe Descrição
Cliente Classe O módulo de login é designado a estabelecer credenciais e a identidade do chamador quando o JBoss EAP 6 estiver agindo como cliente. Isto nunca deve ser usado como parte de um security domain usado na autenticação do servidor atual.
Remoto N/A O módulo de login é usado para verificar se a solicitação sendo autenticada no momento é uma solicitação recebida numa conexão Remota. Neste caso, a identidade que foi criada durante o processo de autenticação é usado e associado com a solicitação atual. Caso a solicitação não chegar numa conexão Remota, este módulo não realiza nada e permite que o JAAS baseado no login continue ao próximo módulo.
RealmDirect N/A O módulo de login RealmDirect faz uso do realm de segurança para autenticar a solicitação atual. Caso isto não ocorra no módulo de login Remoto, o realm será usado para carregar as funções dos usuários. Por default, este módulo de login assume que o realm use o ApplicationRealm nomeado, embora outros nomes possam ser substituídos. A vantagem desta abordagem é que toda a configuração store de backup pode ser deixada no realm com o security domain delegando o realm.

Tabela A.2. Opções de Módulo do Cliente

Opções Tipo Default Descrição
multi-threaded
true ou false
false
Configure para verdadeiro caso cada thread possua o próprio storage credencial e principal. Configure para falso para indicar que todos os threads na MV compartilham a mesma identidade e credencial.
password-stacking
useFirstPass ou false
false
Configure para useFirstPass para indicar que este módulo de login deve buscar por informações stored no LoginContext para uso como a identidade. Esta opção pode ser usada quando empilhando outros módulos de login com este.
restore-login-identity
true ou false
false
Configure para verdadeiro caso a identidade e credencial vistos no início do método login() devem ser restaurados após o método logout() ser invocado.

Tabela A.3. Certificate

Código
Certificate
Classe
org.jboss.security.auth.spi.BaseCertLoginModule
Descrição
Este módulo de login é designado a autenticar os usuários baseados no X509 Certificates. Um caso de usuário sobre isto é a autenticação CLIENT-CERT de um aplicativo da web.

Tabela A.4. Opções do Módulo Certificate

Opções Tipo Default Descrição
securityDomain
faixa
nenhum
Nome do security domain que possui a configuração JSSE para o truststore que contém os certificados trusted.
verifier
Classe
nenhum
Nome de clouds para uso em importações. org.jboss.security.auth.certs.X509CertificateVerifier

Tabela A.5. CertificateUsers

Código
CertificateUsers
Classe
org.jboss.security.auth.spi.UsersRolesLoginModule
Descrição
Isto usa os recursos das propriedades. O primeiro mapeia os nomes dos usuários para senhas e o segundo mapeia os nomes do usuário para funções.

Tabela A.6. Opções de Módulo CertificateUsers

Opções Tipo Default Descrição
unauthenticatedIdentity
Sequência
nenhum
Define o nome principal que deve ser determinado para solicitações que não contém informação da autenticação. Isto pode permitir que servlets não protegidos invocarem métodos nos EJBs que não requerem uma função específica. Tal principal não possui funções associadas e pode apenas acessar tanto métodos EJB ou EJBs que são associados com uma restrição unchecked permission.
password-stacking
useFirstPass ou false
false
Configure para useFirstPass para indicar que esse módulo de login deve buscar pela informação stored no LoginContext para uso como identidade. Esta opção pode ser usada quando empilhando outros módulos com este.
hashAlgorithm Sequência
nenhum
O nome do algoritmo java.security.MessageDigest para efetuar o hash da senha. Não há default para isto, de forma que esta opção deve ser configurada explicitamente para habilitação do hash. Quando o hashAlgoritm for especificado, a senha de texto obtido do CallbackHandler obtém o hash antes de ser passada ao UsernamePasswordLoginModule.validatePassword como argumento inputPassword. O expectedPassword stored no arquivo users.properties deve possuir hash comparáveis. Refira-se ao http://docs.oracle.com/javase/6/docs/api/java/security/MessageDigest.html para informações sobre o java.security.MessageDigest e algoritmos que essa classe suporta.
hashEncoding
base64 ou hex
base64
O formato desta sequência para a senha com hash, caso o hashAlgorithm seja também configurado.
hashCharset
Sequência
A codificação default configurada no ambiente do contêiner.
A codificação usada para converter a senha de texto limpo para um byte array.
usersProperties
O caminho de arquivo inteiramente qualificado e nome do arquivo ou recurso de propriedades.
users.properties
O arquivo contendo os mapeamentos entre os usuários e senhas. Cada propriedade no arquivo possui o formato username=password.
rolesProperties
O caminho de arquivo inteiramente qualificado e nome do arquivo ou recurso de propriedades.
roles.properties
O arquivo contendo os mapeamentos entre os usuários e funções. Cada propriedade do arquivo possui o formato username=role1,role2,...,roleN.
ignorePasswordCase
true ou false
false
Se é que a comparação da senha deve ignorar o caso. Isto é útil para a codificação de senha com hash onde o caso da senha com hash não é significante.
principalClass
O nome da classe inteiramente qualificado.
nenhum
A classe de implementação Principal que contém um condutor que leva um argumento de Sequência para o nome principal.
roleGroupSeparator
Um caractere único
. (um período único)
O caractere usado para separar o nome do usuário a partir do nome do grupo de função no arquivo rolesGroup.
defaultUsersProperties
faixa
defaultUsers.properties
O nome do recurso ou arquivo de retrocedência caso o arquivo usersProperties não possa ser encontrado.
defaultRolesProperties
faixa
defaultRoles.properties
O nome do recurso ou arquivo de retrocedência caso o arquivo rolesProperties não possa ser encontrado.
hashUserPassword
true ou false
true
Se é que efetuar o hash na senha inserida pelo usuário, quando o hashAlgorithm for especificado. O default é true.
hashStorePassword
true ou false
true
Se é que a senha do store retornada do getUsersPassword() deve possuir o hash, quando o hashAlgorithm for especificado.
digestCallback
O nome da classe inteiramente qualificado.
nenhum
O nome da classe da implementação org.jboss.crypto.digest.DigestCallback que inclui o conteúdo de resumo pré ou pós tal como valores salt. Isto é apenas usado caso o hashAlgorithm seja especificado.
storeDigestCallback
O nome da classe inteiramente qualificado.
nenhum
O nome da classe da implementação org.jboss.crypto.digest.DigestCallback que inclui o conteúdo de resumo pré/pós como salts para o hashing da senha stored. Isto é apenas usado caso o hashStorePassword for verdadeiro e o hashAlgorithm for especificado.
callback.option.STRING
Diversos nenhum
Todas as opções pré-fixadas com callback.option. são passadas para o método DigestCallback.init(Map). O nome do usuário inserido é sempre passado através da opção javax.security.auth.login.name e a senha de entrada/store é passada através da opção javax.security.auth.login.password ao digestCallback ou storeDigestCallback.

Tabela A.7. CertificateRoles

Código
CertificateRoles
Classe
org.jboss.security.auth.spi.CertRolesLoginModule
Descrição
O módulo de login estende o módulo de login do certificado para adicionar as capacidades de mapeamento de função a partir do arquivo de propriedades. Isto leva tudo de mesmas opções como o módulo de login do Certificado e adiciona as seguintes opções:

Tabela A.8. CertificateRoles Module Options

Opções Tipo Default Descrição
rolesProperties
Sequência
roles.properties
O nome do recurso ou arquivo contendo as funções para determinação de cada usuário. O arquivo de propriedades de função no formato username=role1,role2 onde o nome do usuário é o DN do certificado, escapando qualquer sinal de = (igual) e caracteres com espaço. A seguinte amostra está no formato correto: 
CN\=unit-tests-client,\ OU\=Red\ Hat\ Inc.,\ O\=Red\ Hat\ Inc.,\ ST\=North\ Carolina,\ C\=US=JBossAdmin
defaultRolesProperties
Sequência
defaultRoles.properties
O nome do recurso ou arquivo de retrocedência caso o arquivo rolesProperties não possa ser encontrado.
roleGroupSeparator
Um caractere único
. (um período único)
Qual caractere de uso conforme o separador de grupo de função no arquivo roleProperties.

Tabela A.9. Database

Código Database
Classe
org.jboss.security.auth.spi.DatabaseServerLoginModule
Descrição
O módulo de login baseado no JDBC que suporta o mapeamento de função e autenticação. Isto é baseado em duas tabelas lógicas, com as seguintes definições:
  • Principals: PrincipalID (text), Password (text)
  • Roles: PrincipalID (text), Role (text), RoleGroup (text)

Tabela A.10. Database Module Options

Opções Tipo Default Descrição
dsJndiName
Recurso JNDI
nenhum
O nome do storing do recurso JNDI da informação de autenticação. Esta opção é requerida.
principalsQuery
Uma declaração SQL preparada
select Password from Principals where PrincipalID=?
A fila SQL preparada para obtenção da informação sobre o principal.
rolesQuery
Uma declaração SQL preparada
select Role, RoleGroup from Roles where PrincipalID=?
A fila SQL preparada para obtenção da informação sobre as funções. Isto deve ser equivalente ao select Role, RoleGroup from Roles where PrincipalID=?, onde Role (Função) é o nome da Função e o valor de coluna RoleGroup deve sempre ser tanto Roles com letra maiúscula R ou CallerPrincipal.

Tabela A.11. DatabaseCertificate

Código
DatabaseCertificate
Classe
org.jboss.security.auth.spi.DatabaseCertLoginModule
Descrição
O módulo de login estende o módulo de login do Certificado para adicionar as capacidades de mapeamento de função a partir da tabela da fonte de dados. Isto possui as mesmas opções, além das opções adicionais:

Tabela A.12. Opções de Módulo DatabaseCertificate

Opções Tipo Default Descrição
dsJndiName
Recurso JNDI
O nome do storing do recurso JNDI da informação de autenticação. Esta opção é requerida.
rolesQuery
Uma declaração SQL preparada
select Role,RoleGroup from Roles where PrincipalID=?
A declaração preparada SQL a ser executada em ordem das funções a serem mapeadas. Isto deve ser equivalente ao select Role, RoleGroup from Roles where PrincipalID=?, onde Role (Função) é o nome da Função e o valor de coluna RoleGroup deve sempre ser tanto Roles com letra maiúscula R ou CallerPrincipal.
suspendResume
true ou false
true
Se é que a transação JTA existente deve ser suspendida durante as operações de fonte de dados.

Tabela A.13. Identity

Código
Identity
Classe
org.jboss.security.auth.spi.IdentityLoginModule
Descrição
Associa o principal especificado nas opções de módulo com qualquer assunto autenticado em relação ao módulo. O tipo de classe Principal usado é org.jboss.security.SimplePrincipal.. Caso nenhuma opção seja especificada, um principal com o nome de guest será usado.

Tabela A.14. Opções de Módulo Identity

Opções Tipo Default Descrição
principal
Sequência
guest
O nome a ser usado pelo principal.
roles
A lista de vírgula separada das sequências
nenhum
A lista de vírgula delimitada das funções a serem determinadas ao assunto.

Tabela A.15. Ldap

Código
Ldap
Classe
org.jboss.security.auth.spi.LdapLoginModule
Descrição
Autentica em relação ao servidor LDAP, quando o nome do usuário e senha forem stored num servidor LDAP que é acessível usando um provedor JNDI LDAP. Muitas das opções não são requeridas, uma vez que elas são determinadas pelo provedor LDAP ou o ambiente.

Tabela A.16. Opções do Módulo Ldap

Opções Tipo Default Descrição
java.naming.factory.initial
nome da classe
com.sun.jndi.ldap.LdapCtxFactory
O nome da classe de implementação InitialContextFactory.
java.naming.provider.url
ldap:// URL
nenhum
URL para o servidor LDAP.
java.naming.security.authentication
none, simple, ou o nome do mecanismo SASL
simple
O nível de segurança para uso para efetuar o bind no servidor LDAP.
java.naming.security.protocol
O protocolo de transporte
Caso não especificado, determinado pelo provedor.
O protocolo de transporte para uso do acesso de segurança, tal como o SSL.
java.naming.security.principal
Sequência
nenhum
O nome do principal para autenticação do chamador para o serviço. Isto é construído a partir de outras propriedades descritas abaixo.
java.naming.security.credentials
O tipo de credencial
nenhum
O tipo de credencial usado pelo esquema de autenticação. Alguns exemplos, incluindo a senha com hash, senha de texto limpo, chave ou certificado. Caso a propriedade não estiver especificada, o comportamento é determinado pelo provedor do serviço.
principalDNPrefix
Sequência
nenhum
O prefixo adicionado para o nome do usuário para formar o DN. Você pode solicitar o nome do usuário e construir o DN inteiramente qualificado usando o principalDNPrefix e principalDNSuffix.
principalDNSuffix
faixa
O sufixo adicionado para o nome do usuário para formar o DN. Você pode solicitar o nome do usuário e construir o DN inteiramente qualificado usando o principalDNPrefix e principalDNSuffix.
useObjectCredential
true ou false
falso
Se é que o credencial deve ser obtido como um Objeto Opaco usando o tipo org.jboss.security.auth.callback.ObjectCallback de Callback ao invés de uma senha char[] usando um JAAS PasswordCallback. Isto permite a passagem de informação de credencial non-char[] ao servidor LDAP.
rolesCtxDN
Um DN inteiramente qualificado
nenhum
O DN inteiramente qualificado para o contexto para busca das funções do usuário.
userRolesCtxDNAttributeName
Atributo
nenhum
O atributo no objeto do usuário que contém o DN para o contexto para pesquisa das funções do usuário. Isto difere-se do rolesCtxDN no que se refere ao contexto de busca das funções do usuário, que poderão ser únicas para cada usuário.
roleAttributeID
Atributo
roles
Nome do atributo contendo funções do usuário.
roleAttributeIsDN
true ou false
false
Se é que o roleAttributeID contém o DN inteiramente qualificado do objeto da função. Caso seja falso, o nome da função é obtida do valor do atributo roleNameAttributeId do nome do contexto. Certos esquemas do diretório, tais como o Microsoft Active Directory, requerem que este atributo seja configurado para true.
roleNameAttributeID
Atributo
group
O nome do atributo com o contexto roleCtxDN que contém o nome da função. Caso a propriedade roleAttributeIsDN seja configurada para true, esta propriedade será usada para buscar o atributo do nome do objeto de função.
uidAttributeID
Atributo
uid
O nome do atributo no UserRolesAttributeDN que corresponde à ID do usuário. Isto é usado para localizar as funções do usuário.
matchOnUserDN
true ou false
false
Se é que a busca das funções do usuário devem coincidir com o DN inteiramente distinguido do usuário ou apenas nome do usuário. Caso seja true, o DN completo de usuário é usado como valor de combinação. Caso seja false, apenas o nome do usuário é usado para combinar o valor em referência ao atributo uidAttributeName.
allowEmptyPasswords
true ou false
true
Se é que permitir as senhas vazias. A maioria dos servidores LDAP tratam senhas vazias com tentativas de login anônimas. Configure isto para falso, com o objetivo de rejeitar senhas vazias.

Tabela A.17. LdapExtended

Código
LdapExtended
Classe
org.jboss.security.auth.spi.LdapExtLoginModule
Descrição
Uma implementação de módulo de login que usa buscas para localizar o usuário bind e funções associadas. A fila das funções segue recursivamente os DNs para navegar a uma estrutura de função hierárquica. Isto usa as mesmas opções java.naming como o módulo Ldap e usa as seguintes opções ao invés de outras opções do módulo Ldap.
A autenticação acontece em duas etapas:
  1. Um bind inicial ao do servidor LDAP é realizado usando as opções bindCredential e bindDN. O bindDN é um usuário LDAP com a habilidade de buscar ambas as árvores baseCtxDN e rolesCtxDN para o usuário e funções. O DN do usuário para autenticação é requerido usando o filtro especificado pelo atributo baseFilter.
  2. O DN do usuário resultante é autenticado pelo binding para o servidor LDAP usando o Dn do usuário como o Context.SECURITY_PRINCIPAL do ambiente InitialLdapContext. A propriedade Context.SECURITY_CREDENTIALS é configurada à senha de Sequência obtida pelo manuseador da chamada de retorno.

Tabela A.18. Opções de Módulo LdapExtended

Opções Tipo Default Descrição
baseCtxDN
Um DN inteiramente qualificado
nenhum
O DN fixado do contexto de nível superior para iniciar a busca do usuário.
bindDN
Um DN inteiramente qualificado
nenhum
O DN usado para efetuar o bind no servidor LDAP para as solicitações de funções e dos usuários. Este DN precisa ler e buscar permissões nos valores baseCtxDN e rolesCtxDN.
bindCredential
Uma sequência, opcionalmente criptografada
nenhum
A senha armazenada como texto plano para o bindDN, ou carregada externamente usando o comando EXT. Essa senha pode ser criptografada usando o mecanismo vault. Você pode usar os seguintes formatos:
  • {EXT}... onde a ... é solicitado como comando externo. Amostra: {EXT}cat /mysecretpasswordfile
  • {EXTC[:expiration_in_millis]}... onde a ... é um comando que será passado ao método Runtime.exec(String) para executar o comando da plataforma. A primeira linha de resultado do comando é usada como senha.
    EXTC variante que efetua o cache às senhas para expiration_in_millis em milésimos de segundos. A expiração do cache default é 0 = infinito.
  • {CLASS}classname[:ctorargs] onde o [:ctorargs] é uma sequência delimitada pelo : a partir do nome de classe que será passado ao nome de classe ctor. O próprio ctorargs é uma lista de vírgula delimitada de sequências.
    A senha é obtida a partir do nome de classe pela invocação a um método char[] toCharArray() caso encontrado, do contrário, o método String toString() será usado.
Refira-se ao seguinte tópico para maiores informações sobre as sequências confidenciais de criptografia: Seção 10.11.2, “Criação do Java Keystore para Sequências Confidenciais do Store”
baseFilter
Sequência do filtro LDAP
nenhum
O filtro de busca para localizar o contexto do usuário para autenticação. O nome do usuário ou userDN obtido da chamada de retorno do módulo de login é substituído no filtro em qualquer local onde uma expressão {0} for usada. Uma amostra comum de busca do filtro é (uid={0}).
rolesCtxDN
DN inteiramente qualificado
nenhum
O DN fixado do contexto de busca para as funções do usuário. Este não é o DN onde as funções atuais se encontram, mas o DN onde os objetos contendo as funções do usuário estão. Por exemplo, num servidor Microsoft Active Directory, este é o DN onde a conta do usuário se encontra.
roleFilter
Sequência do filtro LDAP
A busca do filtro usada para localizar as funções associadas com o usuário de autenticação. O nome do usuário de entrada ou userDN obtido pela chamada de retorno do módulo de login é substituído no filtro em qualquer local onde a expressão {0} for usada. O uderDN autenticado é substituído no filtro em qualquer lugar onde um {1} for usado. Uma amostra da busca do filtro que combina com o nome do usuário de entrada é (member={0}). Uma alternativa que combina com o userDN autenticado é o (member={1}).
roleAttributeIsDN
true ou false
false
Se é que o roleAttributeID contém o DN inteiramente qualificado do objeto da função. Caso seja falso, o nome da função é obtida do valor do atributo roleNameAttributeId do nome do contexto. Certos esquemas do diretório, tais como o Microsoft Active Directory, requerem que este atributo seja configurado para true.
defaultRole
Nome da função
nenhum
A função incluída para todos os usuários autenticados.
parseRoleNameFromDN
true ou false
false
O sinalizador indicando se o DN retornado por uma fila contém o roleNameAttributeID. Caso configurado para true, o DN é checado pelo roleNameATtributeID. Caso configurado para false, o DN não é checado pelo roleNameAttributeID. Este sinalizador pode melhorar o desempenho das filas LDAP.
parseUsername
true ou false
false
Um sinalizador indicando se o DN deve ser pesquisado pelo nome do usuário. Caso configurado para true, o DN pelo nome do usuário. Caso configurado para false o DN pelo nome do usuário. Esta opção é usada juntamente com o usernameBeginString e usernameEndString.
usernameBeginString
uma sequência
nenhum
Define a sequência que está prestes a ser removida a partir do início do DN para revelar o nome do usuário. Esta opção é usada juntamente com o usernameEndString.
usernameEndString
uma sequência
nenhum
Define a sequência que está prestes a ser removida a partir do final do DN para revelar o nome do usuário. Esta opção é usada juntamente com o usernameBeginString.
roleNameAttributeID
Atributo
group
O nome do atributo com o contexto roleCtxDN que contém o nome da função. Caso a propriedade roleAttributeIsDN seja configurada para true, esta propriedade será usada para buscar o atributo do nome do objeto de função.
distinguishedNameAttribute
Atributo
distinguishedName
O nome do atributo na entrada do usuário que contém o DN do usuário. Isto deve ser necessário caso o próprio DN do usuário conter caracteres especiais (barra invertida, por exemplo) que previne o mapeamento do usuário correto. Caso o atributo não existir, o DN de entrada será usado.
roleRecursion
O número
0
Os números de níveis de recursão de busca da função serão inferiores ao do contexto de combinação. Desabilite a recursão configurando-a para 0.
searchTimeLimit
O número
10000 (10 segundos)
O intervalo em milésimos de segundos para buscas do usuário e funções.
searchScope
Um dos: OBJECT_SCOPE, ONELEVEL_SCOPE, SUBTREE_SCOPE
SUBTREE_SCOPE
O escopo de busca para uso.
allowEmptyPasswords
true ou false
true
Se é que permitir as senhas vazias. A maioria dos servidores LDAP tratam senhas vazias com tentativas de login anônimas. Configure isto para falso, com o objetivo de rejeitar senhas vazias.

Tabela A.19. RoleMapping

Código
RoleMapping
Classe
org.jboss.security.auth.spi.RoleMappingLoginModule
Descrição
Mapeia a função que é o resultado final do processo de autenticação a uma função declarativa. Este módulo deve ser sinalizado como optional quando você adicioná-lo ao security domain.

Tabela A.20. Opções de Módulo RoleMapping

Opções Tipo Default Descrição
rolesProperties
O caminho de arquivo inteiramente qualificado e nome do arquivo ou recurso de propriedades.
roles.properties
O caminho do arquivo inteiramente qualificado e nome do arquivo de propriedades ou recurso que mapeia funções para substituição das funções. O formato é original_role=role1,role2,role3.
replaceRole
true ou false
false
Se é que adicionar às funções atuais ou substituir as funções atuais pelas mapeadas. Isto é substituído caso configurado para true.

Tabela A.21. RunAs

Código
RunAs
Classe
Class: org.jboss.security.auth.spi.RunAsLoginModule
Descrição
O módulo ajudante que envia uma função run as à pilha para a duração da fase de login da autenticação e tira a função run as da pilha tanto na fase de confirmação ou anulação. Este módulo de login fornece uma função para os demais módulos que devem acessar os recursos de segurança com o objetivo de executar suas autenticações, tais como o módulo de login que acessa o EJB de segurança. O RunAsLoginModule deve ser configurado antes dos módulos de login que requerem a função run as a ser estabelecida.

Tabela A.22. Opções RunAs

Opções Tipo Default Descrição
roleName
Nome da função
nobody
O nome da função de uso como a função run as durante a fase de login.

Tabela A.23. Simple

Código
Simple
Classe
org.jboss.security.auth.spi.SimpleServerLoginModule
Descrição
O módulo para montagem rápida de segurança para propósitos de testes. Ele implementa o seguinte algoritmo simples:
  • Caso a senha seja nula, autentique o usuário e determine uma identidade do guest e a função do guest.
  • Do contrário, caso a segurança seja igual à do usuário, determine uma identidade igual á do nome do usuário e ambas funções de admin e guest.
  • Do contrário, a autenticação falhará.
Opções de Módulo Simple

O módulo Simple não possui opções.

Tabela A.24. ConfiguredIdentity

Código
ConfiguredIdentity
Classe
org.picketbox.datasource.security.ConfiguredIdentityLoginModule
Descrição
Associa o principal especificado nas opções do módulo com qualquer assunto autenticado em referência ao módulo. O tipo de classe Principal usada é org.jboss.security.SimplePrincipal.

Tabela A.25. Opções de Módulo ConfiguredIdentity

Opções Tipo Default Descrição
principal
Nome do principal.
none
O principal que será associado com qualquer assunto autenticado em referência ao módulo.

Tabela A.26. SecureIdentity

Código
SecureIdentity
Classe
org.picketbox.datasource.security.SecureIdentityLoginModule
Descrição
Este módulo é fornecido para propósitos de legacia. Isto permite você criptografar a senha e então usar a senha criptografada com um principal estatístico. Caso o seu aplicativo usar SecureIdentity, considere o uso de um mecanismo vault da senha.

Tabela A.27. Opções do Módulo SecureIdentity

Opções Tipo Default Descrição
username
faixa nenhum O nome do usuário para autenticação.
password
sequência criptografada nenhum
A senha de uso para autenticação. Para criptografar a senha, use o módulo diretamente na linha de comando. 
java org.picketbox.datasource.security.SecureIdentityLoginModule password_to_encrypt
Copie o resultado deste comando no campo do valor da opção do módulo.
managedConnectionFactoryName
Recurso JCA nenhum
O nome da conexão JCA para a fonte de dados.

Tabela A.28. PropertiesUsers

Código
PropertiesUsers
Classe
org.jboss.security.auth.spi.PropertiesUsersLoginModule
Descrição
Usa o arquivo das propriedades para aplicar o store dos nomes do usuário e senhas para autenticação. Nenhuma autorização (mapeamento de função) é fornecido. Este módulo é apenas apropriado para testes.

Tabela A.29. SimpleUsers

Código
SimpleUsers
Classe
org.jboss.security.auth.spi.SimpleUsersLoginModule
Descrição
O módulo de login efetua o store do nome do usuário e senha de texto limpo no arquivo de propriedades Java. Isto está incluído para testes apenas e não é apropriado para um ambiente de produção.

Tabela A.30. Opções do Módulo SimpleUsers

Opções Tipo Default Descrição
username
faixa nenhum O nome de usuário para uso da autenticação.
password
faixa nenhum A senha de texto limpo para uso da autenticação.

Tabela A.31. LdapUsers

Código
LdapUsers
Classe
org.jboss.security.auth.spi.LdapUsersLoginModule
Descrição
O módulo LdapUsers é substituído pelos módulos ExtendedLDAP e AdvancedLdap.

Tabela A.32. Kerberos

Código
Kerberos
Classe
com.sun.security.auth.module.Krb5LoginModule
Descrição
Executa a autenticação de login do Kerberos, usando GSSAPI. Este módulo faz parte do framework de segurança a partir do API fornecido pelo Sun Microsystems. Maiores informações podem ser encontradas no http://docs.oracle.com/javase/1.4.2/docs/guide/security/jaas/spec/com/sun/security/auth/module/Krb5LoginModule.html. Este módulo precisa ser emparelhado com outro módulo que manuseia o mapeamento de funções e autenticação.

Tabela A.33. Opções de Módulo Kerberos

Opções Tipo Default Descrição
storekey
true ou false
falso
Se é que ou não adicionar o KerberosKey aos credenciais privados do assunto.
doNotPrompt
true ou false
falso
Caso configurado para true, não haverá solicitação de senha ao usuário.
useTicketCache
Valor Booliano de true ou false
. 		falso
Caso true, o GTG é obtido a partir do cache do tíquete. Caso false, o cache do tíquete não será usado.
ticketcache
Um arquivo ou recurso representando um cache de tíquete Kerberos.
O default depende do sistema operacional em que você está utilizando.
  • Red Hat Enterprise Linux / Solaris: /tmp/krb5cc_uid, usando o valor UID numérico do sistema operacional.
  • Microsoft Windows Server: usa o Local Security Authority (LSA) API para encontrar o ticketcache.
A localização do cache do tíquete do cache.
useKeyTab
true ou false
falso Se é que obter a chave principal a partir de um arquivo de tabela de chave.
keytab
O arquivo ou recurso representando o Kerberos keytab.
a localização do arquivo de configuração Kerberos do sistema operacional ou /home/user/krb5.keytab
A localização do arquivo da tabela da chave.
principal
Sequência nenhum
O nome do principal. Isto pode ser tanto um nome de usuário ou um nome de serviço tal como host/testserver.acme.com. Use isto ao invés de obter o principal a partir da tabela chave ou quando a tabela chave conter mais de um principal.
useFirstPass
true ou false
falso
Se é que recuperar o nome do usuário e senha a partir do estado compartilhado do módulo, usando o javax.security.auth.login.name e javax.security.auth.login.password como chaves. Caso a autenticação falhar, nenhuma nova tentativa é realizada.
tryFirstPass
true ou false
falso
O mesmo ao do useFirstPass, mas se a autenticação falhar, o módulo usa o CallbackHandler para recuperar uma nova senha e nome do usuário. Caso uma segunda autenticação falhar, a falha é relatada ao aplicativo de chamada.
storePass
true ou false
falso
Se é que realizar o store no nome do usuário e senha no estado compartilhado do módulo. Isto não acontece caso as chaves já existirem no estado compartilhado ou se a autenticação falhar.
clearPass
true ou false
falso
Defina isto para true para limpar o nome do usuário e senha do estado compartilhado após ambas as fases de autenticação forem completadas.

Tabela A.34. SPNEGOUsers

Código
SPNEGOUsers
Classe
org.jboss.security.negotiation.spnego.SPNEGOLoginModule
Descrição
Permite a autenticação SPNEGO ao servidor Microsoft Active Directory ou de outro ambiente que suporta o SPNEGO. O SPNEGO pode levar as credenciais do Kerberos. Este módulo precisa ser emparelhado com outro módulo que manuseia o mapeamento de função e autenticação.

Tabela A.35. Opções de Módulo SPNEGO

Opções Tipo Default Descrição
storeKey
true ou false
false
Se é que ou não aplicar o store na chave.
useKeyTab
true ou false
false
Se é que usar uma tabela de chave.
principal
Sequência representando o principal para a autenticação Kerberos.
nenhum
O nome do principal para autenticação.
keyTab
O arquivo ou recurso de representação da keytab.
none
A localização da tabela da chave.
doNotPrompt
true ou false
false
Se é que solicitar a senha.
debug
true ou false
false
Se é que gravar as mensagens mais verbosas para propósitos de depuração.

Tabela A.36. AdvancedLdap

Código AdvancedLdap
Classe
org.jboss.security.negotiation.AdvancedLdapLoginModule
Descrição
O módulo que fornece funcionalidade adicional, tal como SASL e uso do security domain JAAS.

Tabela A.37. Opções de Módulo AdvancedLdap

Opções Tipo Default Descrição
bindAuthentication
faixa
nenhum
O tipo de autenticação SASL para uso do binding para o servidor do diretório.
java.naming.provider.url
string
nenhum
O URI do servidor do diretório.
baseCtxDN
O Distinguished Name (DN - Nome Distinguido) inteiramente qualificado.
nenhum
O nome distinguido para uso como base para as pesquisas.
baseFilter
A sequência representando um filtro de busca LDAP.
nenhum
O filtro para uso para diminuir os resultados de busca.
roleAttributeID
Uma sequência representando um atributo LDAP.
nenhum
O atributo LDAP que contém os nomes das funções de autorização.
roleAttributeIsDN
true ou false
false
Se é que o atributo da função é um Distinguished Name (DN - Nome Distinguido).
roleNameAttributeID
A sequência representando um atributo LDAP.
nenhum
O atributo contido com o RoleAttributeId que contém o atributo de função atual.
recurseRoles
true ou false
false
Se é que buscar de recursivamente o RoleAttributeId para funções.

Tabela A.38. AdvancedADLdap

Código AdvancedADLdap
Classe
org.jboss.security.negotiation.AdvancedADLoginModule
Descrição
Este módulo estende o módulo de login AdvancedLdap e adiciona parâmetros extra que são relevantes ao Microsoft Active Directory.

Tabela A.39. UsersRoles

Código UsersRoles
Classe
org.jboss.security.auth.spi.UsersRolesLoginModul
Descrição
O módulo de login simples que suporta usuários múltiplos e funções de usuários stored em dois arquivos de propriedades diferentes.

Tabela A.40. Opções de Módulo UsersRoles

Opções Tipo Default Descrição
usersProperties
Caminho a um arquivo ou recurso.
users.properties
O arquivo ou recurso que contém os mapeamentos do usuário-à-senha. O formato do arquivo é user=hashed-password
rolesProperties
Caminho a um arquivo ou recurso.
roles.properties
O arquivo ou recurso que contém os mapeamentos do usuário-à-função. O formato do arquivo é username=role1,role2,role3
password-stacking
useFirstPass ou false
false
O valor do useFirstPass indica que este módulo de login deve primeiramente observar a informação stored no LoginContext para a identidade. Esta opção pode ser usada quando empilhando outros módulos de login com este.
hashAlgorithm
A sequência representando um algoritmo hashing da senha.
none
O nome do algoritmo java.security.MessageDigest para efetuar o hash na senha. Não há default de forma que esta opção deve ser explicitamente configurada para habilitar o hashing. Quando o hashAlgorithm for especificado, a senha de texto limpo obtido a partir do CallbackHandler contém hash antes de ser passado ao UsernamePasswordLoginModule.validatePassword como um argumento inputPassword. A senha stored no arquivo users.properties deve ser um hash comparável.
hashEncoding
base64 ou hex
base64
O formato da sequência para a senha com hash, caso o hashAlgoritmo for também configurado.
hashCharset
Sequência
A codificação default determinada no ambiente do período de execução do contêiner.
A codificação usada para converter a senha de texto limpo para um byte array.
unauthenticatedIdentity
O nome principal
nenhum
Define o nome principal determinado para solicitações que não contém informação de autenticação. Isto pode permitir que servlets não protegidos invoquem métodos nos EJBs que não solicitem uma função específica. Tal principal não possui funções associadas e podem apenas acessar métodos EJB e EJBs que são associados com a restrição unchecked permission.
Módulos de Autenticação Personalizados

Os módulos de autenticação são implementações do javax.security.auth.spi.LoginModule. Refira-se à documentação API para maiores informações sobre a criação de um módulo de autenticação personalizado.

Reportar um erro

A.2. Módulos de Autorização Incluída

Os seguintes módulos fornecidos nos serviços de autorização.
Código Classe
DenyAll org.jboss.security.authorization.modules.AllDenyAuthorizationModule
PermitAll org.jboss.security.authorization.modules.AllPermitAuthorizationModule
Delegação org.jboss.security.authorization.modules.DelegatingAuthorizationModule
Web org.jboss.security.authorization.modules.WebAuthorizationModule
JACC org.jboss.security.authorization.modules.JACCAuthorizationModule
Reportar um erro

A.3. Módulos de Mapeamento de Segurança Incluída

As seguintes funções de mapeamento de segurança são fornecidas no JBoss EAP 6.
Código Classe
PropertiesRoles org.jboss.security.mapping.providers.role.PropertiesRolesMappingProvider
SimpleRoles org.jboss.security.mapping.providers.role.SimpleRolesMappingProvider
DeploymentRoles org.jboss.security.mapping.providers.DeploymentRolesMappingProvider
DatabaseRoles org.jboss.security.mapping.providers.role.DatabaseRolesMappingProvider
LdapRoles org.jboss.security.mapping.providers.role.LdapRolesMappingProvider
Reportar um erro

A.4. Módulos do Fornecedor de Auditoria de Segurança Incluídos

O JBoss EAP 6 fornece um fornecedor de auditoria de segurança.
Código Classe
LogAuditProvider org.jboss.security.audit.providers.LogAuditProvider
Reportar um erro

A.5. Referência da Configuração jboss-web.xml

Introdução

O jboss-web.xml é um arquivo com o seu diretório WEB-INF ou META-INF da implantação. Ele contém informação de configuração sobre os recursos que o contêiner do JBoss Web adiciona à especificação Servlet 3.0. As configurações específicas à especificação Servlet 3.0 são posicionadas no web.xml do mesmo diretório.

O elemento de nível superior no arquivo jboss-web.xml é o elemento <jboss-web>.
Requerimentos WAR dos Recursos Globais de Mapeamento

Muitos dos requerimentos de mapeamento da configuração disponíveis configurados no web.xml do aplicativo aos recursos locais. As explicações das configurações web.xml podem ser encontradas no http://docs.oracle.com/cd/E13222_01/wls/docs81/webapp/web_xml.html.

Por exemplo, caso o web.xml solicitar o jdbc/MyDataSource, o jboss-web.xml poderá mapear o java:/DefaultDS da fonte de dados global para preencher esta necessidade para o jdbc/MyDataSource.

Tabela A.41. Os atributos de Nível Superior Comuns

Função Descrição
env-entry
O mapeamento a um env-entry solicitado pelo web.xml.
ejb-ref
O mapeamento a um ejb-ref solicitado pelo web.xml.
ejb-local-ref
Um mapeamento a um ejb-local-ref solicitado pelo web.xml.
service-ref
O mapeamento a um service-ref solicitado pelo web.xml.
resource-ref
O mapeamento a um resource-ref solicitado pelo web.xml.
resource-env-ref
O mapeamento a um resource-env-ref solicitado pelo web.xml.
message-destination-ref
O mapeamento a um message-destination-ref solicitado pelo web.xml.
persistence-context-ref
O mapeamento a um persistence-context-ref solicitado pelo web.xml.
persistence-unit-ref
O mapeamento a um persistence-unit-ref solicitado pelo web.xml.
post-construct
O mapeamento a um post-context solicitado pelo web.xml.
pre-destroy
O mapeamento a um pre-destroy solicitado pelo web.xml.
data-source
O mapeamento a um data-source solicitado pelo web.xml.
context-root O contexto raiz do aplicativo. O valor default é o nome da implantação sem o sufixo .war.
virtual-host O nome do host virtual HTTP que o aplicativo aceita as solicitações. Isto refere-se aos conteúdos do cabeçalho HTTP Host.
anotação Descreve uma anotação usado pelo aplicativo. Refira-se ao <annotation> para maiores informações.
listener (ouvinte) Descreve um ouvinte usado pelo aplicativo. Refira-se ao <listener> para maiores informações.
session-config O elemento preenche a mesma função ao do elemento <session-config> do web.xml e é incluído apenas para compatibilidade.
válvula Descreve a válvula usada pelo aplicativo. Refira-se ao <valve> para maiores informações.
overlay O nome da sobreposição para adição ao aplicativo.
security-domain O nome do security domain usado pelo aplicativo. O próprio security domain é configurado no console baseado na web ou no CLI de gerenciamento.
security-role Este elemento preenche a mesma função como o elemento <security-role> do web.xml e é incluído apenas para a compatibilidade.
use-jboss-authorization Caso este elemento estiver presente e conter o valor de inconfiabilidade do caso como "verdadeiro", a pilha de autorização do JBoss web será usada. Caso ele não estiver presente ou conter qualquer valor que não é "verdadeiro", apenas os mecanismos da autorização especificados nas especificações do Java Enterprise Edition serão usados. Este elemento é novo para o JBoss EAP 6.
disable-audit Caso este elemento vazio estiver presente, a auditoria de segurança da web será desabilitada. Do contrário, isto será habilitado. A auditoria de segurança da web não faz parte da especificação do Java EE. Este elemento é novo no JBoss EAP 6.
disable-cross-context Caso false, o aplicativo está apto a chamar outro contexto de aplicativo. O default é true.
Os seguintes elementos de cada elemento filho.
<annotation>

Descreve uma anotação usada pelo aplicativo. A seguinte tabela lista os elementos filho de um <annotation>.

Tabela A.42. Elementos de Configuração da Anotação

Função Descrição
class-name
Nome da classe de anotação
servlet-security
O elemento, tal como @ServletSecurity, que representa a segurança servlet.
run-as
O elemento, tal como @RunAs, que representa a informação run-as.
multi-part
O elemento, tal como @MultiPart, que representa a informação múltipla em partes.
<listener>

Descreve um ouvinte. A seguinte tabela lista os elementos filhos de um <listener>.

Tabela A.43. Elementos de Configuração Ouvinte

Função Descrição
class-name
O nome da classe do ouvinte.
listener-type
Lista os elementos condition que indicam qual o tipo de ouvinte deve ser adicionado ao Contexto do aplicativo. As escolhas válidas são:
CONTAINER
Adiciona um ContainerListener ao Contexto.
LIFECYCLE
Adiciona um LifecycleListener ao Contexto.
SERVLET_INSTANCE
Adiciona um InstanceListener ao Contexto
SERVLET_CONTAINER
Adiciona um WrapperListener ao Contexto.
SERVLET_LIFECYCLE
Adiciona um WrapperLifeCycle ao Contexto.
module
O nome do módulo contendo a classe ouvinte.
param
O parâmetro. Isto contém dois elementos filhos, <param-name> e <param-value>.
<valve>

Descreve a válvula do aplicativo. Ele contém os mesmos elementos de configuração como o <listener>.

Reportar um erro

A.6. Referência do Parâmetro de Segurança EJB

Tabela A.44. Elementos do parâmetro de segurança EJB

Elemento Descrição
<security-identity>
Contém elementos filhos relativos à identidade de segurança de um EJB.
<use-caller-identity />
Indica que o EJB usa a mesma identidade de segurança à do chamador.
<run-as>
Contém um elemento <role-name>.
<run-as-principal>
Caso presente, indica o principal assinalado para chamadas de saída. Caso não esteja presente, as chamadas de saída são determinadas a um principal nomeado anonymous.
<role-name>
Especifica que a função do EJB deve ser executada.
<description>
Descreve a função nomeada no <role-name>
.

Exemplo A.1. Amostras da identidade de segurança

Esta amostra apresenta cada tag descrita na Tabela A.44, “Elementos do parâmetro de segurança EJB”. Elas podem ser também usadas dentro de um <session>. 
<ejb-jar>
    <enterprise-beans>
        <session>
            <ejb-name>ASessionBean</ejb-name>
            <security-identity>
                <use-caller-identity/>
            </security-identity>
        </session>
        <session>
            <ejb-name>RunAsBean</ejb-name>
            <security-identity>
                <run-as>
                    <description>A private internal role</description>
                    <role-name>InternalRole</role-name>
                </run-as>
            </security-identity>
        </session>
		  <session>
			 <ejb-name>RunAsBean</ejb-name>
			 <security-identity>
				<run-as-principal>internal</run-as-principal>
			 </security-identity>
		  </session>
    </enterprise-beans>
</ejb-jar>
Reportar um erro

Apêndice B. Histórico de Revisão

Histórico de Revisões
Revisão 1.0.0-1Wed Jul 02 2014CS Builder Robot
Built from Content Specification: 14876, Revision: 564067

Nota Legal

Copyright © 2014 Red Hat, Inc..
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.