JBoss AS 5

Encrypt Keystore Password no JBoss AS 6.1 / 5.1

Postado em Atualizado em

Olá a todos 😀

Hoje vamos aprender como encriptar a senha do keystore/certificado que fica configurado no connector HTTPs no server.xml do JBoss. Em configurações normais quando habilitamos o HTTPs configuramos a caminho e password dos certificados em texto puro no connector mas essa não é um boa pŕatica, veja abaixo:

<Connector protocol="HTTP/1.1" SSLEnabled="true"
    port="${jboss.web.https.port}" address="${jboss.bind.address}"
    scheme="https" secure="true" clientAuth="false"
    keystoreFile="${jboss.server.home.dir}/conf/example.keystore"
    keystorePass="changeit" sslProtocol = "TLS" />

Se você quiser encriptar a senha da keystore então a sintaxe acima não é necessária. A sintaxe correta seria:

<Connector port="${jboss.web.https.port}" address="${jboss.bind.address}"
   maxThreads="100" minSpareThreads="5" maxSpareThreads="15"
   scheme="https" secure="true" clientAuth="false"
   sslProtocol="TLS"
   securityDomain="java:/jaas/encrypt-keystore-password"
   SSLImplementation="org.jboss.net.ssl.JBossImplementation" >
</Connector>

O próximo passo é configurar MBean JaasSecurityDomain. Você precisa criar o arquivo JBOSS_HOME/server//deploy/security-service.xml e adicionar o conteúdo abaixo:

<server>
   <mbean code="org.jboss.security.plugins.JaasSecurityDomain"
      name="jboss.security:service=PBESecurityDomain">
      <constructor>
         <arg type="java.lang.String" value="encrypt-keystore-password"></arg>
      </constructor>
      <attribute name="KeyStoreURL">resource:example.keystore</attribute>
      <attribute name="KeyStorePass">{CLASS}org.jboss.security.plugins.FilePassword:${jboss.server.home.dir}/conf/keystore.password</attribute>
      <attribute name="Salt">mysaltmagnani</attribute>
      <attribute name="IterationCount">13</attribute>
      <!--
        <attribute name="KeyStoreType">pkcs12</attribute>
       -->
   </mbean>
</server>

Você pode alterar o valor de salt e iterationCount conforme a sua necessidade.

O próximo passo é criar o arquivo de senha. Execute o seguinte comando:

[mmagnani@dhcp-32 conf]$ pwd
/home/mmagnani/WorkSpace/jboss-org/jboss-6.1.0.Final/server/blog/conf
[mmagnani@dhcp-32 conf]$ java -cp ../../../lib/jbosssx.jar org.jboss.security.plugins.FilePassword mysaltmagnani 13 password keystore.password

O arquivo keystore.password foi criado.

Agora para finalizar temos que dizer ao container web para iniciar serviço PBESecurityDomain(security-service.xml) que havíamos criado.

Edite o arquivo JBOSS_HOME/server//deploy/jbossweb.sar/META-INF/jboss-beans.xml e adicione PBESecurityDomain abaixo:

<?xml version="1.0" encoding="UTF-8"?>
<deployment xmlns="urn:jboss:bean-deployer:2.0">

   <bean name="WebServer"
         class="org.jboss.web.tomcat.service.deployers.TomcatService">

     ....

       <depends>jboss.security:service=PBESecurityDomain</depends>

     ....

  </bean>
</deployment>

Inicie o JBoss e verifique se o HTTPs está funcionando corretamente. Para gerar o certificado eu utilizei o comando abaixo:

keytool -genkeypair -keystore example.keystore -storepass password -keypass password -keyalg RSA -validity 180 -alias example -dname "cn=Mauricio Magnani,o=Home,c=BR"

Espero que tenha ajudado, Abraços.

Evitando Erros de Deploy no JBoss AS 5.1

Postado em Atualizado em

Um problema muito comum ao realizar deploy de arquivos no JBoss é que  o deployment scanner  pode tentar implantar a aplicação antes que ela tenha sido totalmente copiada para o diretório de implantação.

A primeira dica é bem simples: Evite realizar deploy de aplicações em máquinas remotas, uma alternativa seria copiar para um diretório local onde o JBoss esteja instalado e em seguida copiar esse arquivo para o diretório de implantação adequado. Eu mesmo por muitas vezes a alguns anos atrás tentava realizar o hot deploy de uma aplicação  WAR de 50 MB  e na época não entendia o por que dos erros. A causa raiz é que por padrão o deployment scanner percorre os diretório de deploy a cada 5 segundos em busca de novas aplicações, caso encontre automaticamente a aplicação é implantada mesmo que não tenha sido totalmente copiada ocasionando erros.

Observando esse cenário podemos escolher entre duas opções: Desabilitar o deployment scanner ou alterar o valor do “Scan Period” dos diretório de deploy.

Para alterar o Scan Period edite o arquivo:


jboss-5.1.0.GA\jboss-5.1.0.GA\server\<profile>\deploy\hdscanner-jboss-beans.xml

E altere o valor da propriedade:


<!-- Frequency in milliseconds to rescan the URLs for changes -->

<property name="scanPeriod">15000</property>

Para desabilitar deployment scanner simplesmente remova o arquivo:

jboss-5.1.0.GA\jboss-5.1.0.GA\server\<profile>\deploy\hdscanner-jboss-beans.xml

Espero que tenha ajudado.

Abraços

Fonte: https://community.jboss.org/wiki/TurnDeploymentScannerDown

Utilizando SSL e JDBC no JBoss AS 5.1

Postado em Atualizado em

Já precisei muitas vezes habilitar o connector HTTPs no JBoss para utilizar conexões seguras ( SSL ). Mas nunca havia utilizado em conexões JDBC e é sobre isso que vamos falar no post de hoje.

A primeira coisa a ser feita é verificar se o banco de dados utilizado fornece suporte a SSL. Para os nossos testes vamos utilizar o MySQL presumo que você já o tenha instalado.

Realize login no MySQL:

mysql -uroot -p123456

Verifique se o suporte ao SSL está habilitado:

mysql> show variables like "%ssl%";
 +---------------+----------+
 | Variable_name | Value    |
 +---------------+----------+
 | have_openssl  | DISABLED |
 | have_ssl      | DISABLED |
 | ssl_ca        |          |
 | ssl_capath    |          |
 | ssl_cert      |          |
 | ssl_cipher    |          |
 | ssl_key       |          |
 +---------------+----------+
 7 rows in set (0.00 sec)

Como podemos visualizar “DISABLED ” significa que o MySQL suporta SSL mas está desabilitado. Para mais informações execute:

mysql> \s
 --------------
 mysql  Ver 14.14 Distrib 5.1.61, for redhat-linux-gnu (x86_64) using readline 5.1

Connection id:          3
 Current database:
 Current user:           root@localhost
 SSL:                    Not in use
 Current pager:          stdout
 Using outfile:          ''
 Using delimiter:        ;
 Server version:         5.1.61 Source distribution
 Protocol version:       10
 Connection:             Localhost via UNIX socket
 Server characterset:    latin1
 Db     characterset:    latin1
 Client characterset:    latin1
 Conn.  characterset:    latin1
 UNIX socket:            /var/lib/mysql/mysql.sock
 Uptime:                 3 min 54 sec

Threads: 1  Questions: 10  Slow queries: 0  Opens: 15  Flush tables: 1  Open tables: 8  Queries per second avg: 0.42
 --------------

Crie o diretório mysql:

mkdir -p /etc/mysql

Entre no diretório /etc/mysql e execute os comandos abaixo para gerar o certificado:

openssl genrsa -out ca-key.pem 2048;
openssl req -new -x509 -nodes -days 1000 -key ca-key.pem -out ca-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout server-key.pem -out server-req.pem;
openssl x509 -req -in server-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem;
openssl req -newkey rsa:2048 -days 1000 -nodes -keyout client-key.pem -out client-req.pem;
openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem;

Edite o arquivo de configuração do MySQL:

vim /etc/my.cnf

Adicione as informações do certificado:

[client]
 ssl-ca=/etc/mysql/ca-cert.pem
 ssl-cert=/etc/mysql/client-cert.pem
 ssl-key=/etc/mysql/client-key.pem

[mysqld]
 ssl-ca=/etc/mysql/ca-cert.pem
 ssl-cert=/etc/mysql/server-cert.pem
 ssl-key=/etc/mysql/server-key.pem

Restart o MySQL:

service mysqld restart

Realize login novamente no MySQL e verifique se o suporte ao SSL foi habilitado:

mysql> show variables like "%ssl%";
 +---------------+----------------------------+
 | Variable_name | Value                      |
 +---------------+----------------------------+
 | have_openssl  | YES                        |
 | have_ssl      | YES                        |
 | ssl_ca        | /etc/mysql/ca-cert.pem     |
 | ssl_capath    |                            |
 | ssl_cert      | /etc/mysql/server-cert.pem |
 | ssl_cipher    |                            |
 | ssl_key       | /etc/mysql/server-key.pem  |
 +---------------+----------------------------+
 7 rows in set (0.01 sec)

mysql>  \s
 --------------
 mysql  Ver 14.14 Distrib 5.1.61, for redhat-linux-gnu (x86_64) using readline 5.1

Connection id:          2
 Current database:
 Current user:           root@localhost
 SSL:                    Cipher in use is DHE-RSA-AES256-SHA
 Current pager:          stdout
 Using outfile:          ''
 Using delimiter:        ;
 Server version:         5.1.61 Source distribution
 Protocol version:       10
 Connection:             Localhost via UNIX socket
 Server characterset:    latin1
 Db     characterset:    latin1
 Client characterset:    latin1
 Conn.  characterset:    latin1
 UNIX socket:            /var/lib/mysql/mysql.sock
 Uptime:                 8 min 32 sec

Threads: 1  Questions: 7  Slow queries: 0  Opens: 15  Flush tables: 1  Open tables: 8  Queries per second avg: 0.13
 --------------

Agora o SSL está habilitado.

Agora vamos “transformar” os certificados gerado para que eles sejam reconhecidos pelo Java. Execute os comandos abaixo:

PKCS12

openssl pkcs12 -export -out cert-and-key.p12 -in client-cert.pem -inkey client-key.pem

openssl pkcs12 -export -out cert-and-key-with-ca.p12 -in client-cert.pem -inkey client-key.pem -CAfile ca-cert.pem -chain

openssl pkcs12 -export -out cacert.p12 -in ca-cert.pem -nokeys

JKS

keytool -importkeystore -destkeystore cert-and-key-with-ca.jks -srckeystore cert-and-key-with-ca.p12 -srcstoretype PKCS12

keytool -keystore cacert-added-then-cert-nokey.jks -import -file ca-cert.pem -alias cacert

keytool -keystore cacert-added-then-cert-nokey.jks -import -file client-cert.pem -alias cert

keytool -keystore cacert-added-then-cert-withkey.jks -import -file ca-cert.pem -alias cacert

keytool -destkeystore cacert-added-then-cert-withkey.jks -importkeystore -srckeystore cert-and-key.p12 -srcstoretype PKCS12</pre>

Agora no JBoss AS vamos adicionar as propriedades ao data source que permitem utilizar as conexões seguras fornecidas pelo banco de dados.

Em JBOSS_HOME/server/<config>/deploy crie o arquivo mysql-ds e deixe-o como abaixo:

<datasources>
 <local-tx-datasource>
   <jndi-name>MySqlDS</jndi-name>
   <connection-url>jdbc:mysql://localhost:3306/test</connection-url>
   <driver-class>com.mysql.jdbc.Driver</driver-class>
   <user-name>root</user-name>
   <password>123456</password>
   <track-statements>true</track-statements>

   <connection-property name="verifyServerCertificate">false</connection-property>
   <connection-property name="requireSSL">true</connection-property>
   <connection-property name="useSSL">true</connection-property>
   <connection-property name="javax.net.ssl.trustStore">/etc/mysql/cert-and-key-with-ca.jks</connection-property>
   <connection-property name="javax.net.ssl.trustStorePassword">123456</connection-property>
   <connection-property name="javax.net.ssl.trustStoreType">JKS</connection-property>
   <connection-property name="javax.net.ssl.keyStore">/etc/mysql/cacert-added-then-cert-withkey.jks</connection-property>
   <connection-property name="javax.net.ssl.keyStorePassword">123456</connection-property>
   <connection-property name="javax.net.ssl.keyStoreType">JKS</connection-property>

   <metadata>
     <type-mapping>mySQL</type-mapping>
   </metadata>
  </local-tx-datasource>
</datasources>

Finalmente nossas conexões JDBC que utilizam o data source do JBoss estão trafegando em canal seguro.

Espero que tenha ajudado.

Abraços

Fontes:


JBoss Clustering – Parte 2

Postado em Atualizado em

Basicamente a arquitetura do JBoss Clustering, está dividido em 2 partes: Smart Proxy Architecture e External Load Balancer. Para diferenciar podemos afirmar que o External Load Balancer é utilizado em aplicações web clusterizadas. enquando Smart Proxies são utilizados para todos os outros componentes clusterizados.

External load balancer

Não é requerido nenhum download para executar serviços HTTP em cluster, mas por uma questão lógica é necessária a configuração de um componente (hardware ou software) que encaminhe as requisições para outros nós em caso de falha. Atualmente existem alguns balanceadores muito difundidos na plataforma JBoss: Mod Cluster e Mod JK.

Smart proxies

Ao utilizar serviços no JBoss como JNDI, EJB, RMI, e JBoss remoting, a comunicação entre o cliente e o servidor não é peer-to-peer.  Quando um cliente chama um EJB,  um objeto smart proxy é localizado e baixado localmente. Em um ambiente não clusterizado, o smart proxy somente encaminha a chamada do cliente para o servidor, verificando alguns parâmetros e pegando os valores de retorno do EJB. Já em um ambiente clusterizado o smart proxy possui um interceptor que sabe como encaminhar chamadas para vários nós do cluster. O smart proxy está preparado para situações como failover. Caso um nó deixe de responder o proxy stub é atualizado com as utimas modificações na estrutura do cluster.

No próximo post, vamos abordar os principais arquivos da estrutura de cluster no JBoss.

Abraços.

JBoss Clustering – Parte 1

Postado em Atualizado em

Hoje vamos iniciar uma séries de posts sobre cluster no JBoss AS 5 e 6. JBoss clustering não é o produto de uma única biblioteca ou uma especificação, mas sim um conjunto de tecnologias. Um cluster de servidores de aplicação JBoss, é composto por várias instâncias ( nós ) executados simultâneamente visando alcançar escalabilidade e confiabilidade. Os nós podem estar na mesma máquina ou em máquinas diferentes. Para o cliente isso é  irrelevante porque o cluster aparece como uma única instância do servidor.

Os benefícios do cluster incluem:

  • Escalabilidade: É possível aumentar o poder de processamento do cluster, conforme o aumento da carga. Basicamente deve-se adicionar um novo nó para que o cluster passe a atender uma carga maior do que a prevista inicialmente.
  • Balanceamento de Carga: Consistem em distribuir a carga entre os nós participantes do cluster, evitando que somente um nó seja sobre-carregado ocasionando a sua queda.
  • Alta Disponibilidade: Os aplicativos executados no cluster, podem continuar disponíveis mesmo se um dos nós participantes falhar.

O JBoss AS já vem com suporte nativo a clusterização, localizado no profile  JBOSS_HOME/server/all . Para que o JBoss esteja em cluster os nós das instâncias devem ser agrupados em partições. Como dito anteriormente os nós podem estar na mesma máquina ou em máquinas diferente, mas é necessário que cada nó tenha endereços de IP diferentes.

Na figura a abaixo, você pode ver  um cluster composto de dois nós na mesma partição (DefaultPartition), cada um com seu endereço IP atribuído.

 

Você também pode ter múltiplas partições cluster rodando na mesma rede. A fim de diferenciá-los, cada grupo deve ter um nome individual e multicast endereço/porta.  Na imagem abaixo, temos um  cenário  com duas partições, ou seja, partition1 e partition2, cada um com dois membros do cluster e endereço de multicast distintos.
Veja o conceito de Multicast na Wikipedia. Para realização a comunicação entre os nós do cluster o JBoss utiliza uma biblioteca chamada JGroups.  Na inicialização do JBoss, o JGroups disponibiliza um conjunto de canais que têm a capacidade para descobrir  um ao outro de forma dinâmica através da troca de pacotes multicast. Todas as mensagens enviadas e recebidas  utilizando o canal tem que passar através do protocolo na stack. O conhecimento da stack não é necessário,  a menos que você precise ajustar os valores padrão ou realizar configurações extras.Acompanhem o próximo post.
Abraços.

JSF da Aplicação ou do JBoss AS ?

Postado em Atualizado em


Se você possui uma aplicação .war, com a implementação do JSF no diretório WEB-INF/lib, deve-se especificar o parâmetro abaixo, para “dizer” ao JBoss que você quer usar a implementação que está na sua aplicação e não a que é disponibilizada pelo Servidor (JBoss). Esse  parâmetro deve ser adicionado ao web.xml, da sua aplicação.


<context-param>
  <param-name>org.jboss.jbossfaces.WAR_BUNDLES_JSF_IMPL</param-name>
  <param-value>true</param-value>
</context-param>

Dica simples. Abraço!

Fonte: http://docs.jboss.org/jbossas/

Estrutura de Diretórios do JBoss Application Server 5.1

Postado em Atualizado em

A estrutura do servidor de aplicação mudou bastante a partir da versão 5x. Vamos dar uma olhada na árvore de diretórios do JBoss  e suas propriedades correspondentes.

Se você não estiver familiarizado com o JBoss  AS, irá se sentir um pouco desorientado. No entanto as tabelas abaixo servirão como uma referência inicial para o entendimento do servidor de aplicação. A tabela mostra os diretórios e seus significados correspondentes.

Diretório Descrição
bin Esse diretório contém os scripts necessários para o gerenciamento de inicialização e desligamento do servidor. Junto com esses scripts, existem utilitários para gerenciamento do servidor.
client Este diretório contém as bibliotecas necessárias para executar o cliente de aplicações. (Ex: EJB, WS, etc.).
common Este diretório hospeda a pasta lib, que é o novo repositório para bibliotecas comuns usadas por diferentes aplicações.
docs Apesar desse nome, esse diretório não contém a documentação do JBoss, ele hospeda modelos de configuração para JMS, JCA, JTA, Data Sources entre outros.
lib Esse diretório contém as bibliotecas necessárias para execução do JBoss AS, aqui estão o Micro container e o kernel JMX anterior.
server Esse diretório é o home de todos os “profiles” do servidor. Aqui será criada ou utilizada a configuração mais adequada a sua necessidade.

Abaixo temos a tabela com a descrição dos diretórios contidos em cada profile(configuração).

Diretório Descrição
conf Nesse diretório estão arquivos de configuração como: login-config, standardjbosscmp-jdbc, entre outros
data Diretório que está disponível para armazenar se necessário,  arquivos de sistemas utilizados pelos serviços.
deploy Esse diretório é o principal local para Implantação (deploy) de serviços e aplicações no JBoss AS.
deployers Esse diretório contém todos os serviços do JBoss AS, que são utilizados para reconhecer e implantar aplicações e tipo de arquivos.
log Esse é o diretório padrão onde o servidor coloca registros de inicialização de aplicações.
tmp Esse diretório é utilizado para armazenar as aplicações implantadas, para uso local, no caso o JBoss.
work Esse diretório é usado pelo JBoss AS para armazenar JSPs compilados e outros dados temporários.

O objetivo aqui foi simplesmente apresentar a estrutura de diretórios do servidor.

Um grande abraço e até a próxima!

Fonte: http://docs.jboss.org/jbossas/