JBoss AS 5

Linux e JBoss: Seja Cuidadoso!

Postado em

E ai Galera blz?

Esse post é mais uma dica do que um tutorial.

Em hipótese alguma inicie o JBoss utilizando o usuário root, pois a plataforma Java oferece APIs para execução de códigos nativos do sistema operacional e mecanismos de gerenciamento remoto. No Linux crie um usuário com privilégios adequados para iniciar o serviço do JBoss.

Se quiser ver com isso tudo pode prejudicar o seu ambiente. Pegue a aplicação filebrowser e faça um deploy no JBoss.

Primeiro execute o JBoss utilizando um usuário com privilégios reduzidos e brinque com algumas funcionalidade da aplicação filebrowser.

Agora execute o JBoss com o usuário root e teste novamente o filebrowser. Perceba que com uma aplicação web escrita em Java você pode ser capaz de invadir até uma rede ser as permissões estiverem no nível de root.

Abraços

App: http://www.vonloesch.de/filebrowser.html

 

Slimming descomplicado no AS 5

Postado em

Olá, pessoal!

Hoje vou promover um pouco o projeto rboss apresentando a funcionalidade de slimming no JBoss AS 5 (e EAP 5 também).

Para quem ainda não sabe, o slimming significa retirar recursos que não são utilizados. Isso acelera muito o tempo de startup do JBoss e, de quebra, diminui o consumo de memória.

Pré-requisitos

Obviamente que precisamos do rboss instalado. Você pode conferir aqui como instalá-lo.

Removendo os recursos

A funcionalidade foi baseada na documentação sobre slimming disponível na wiki.

A remoção dos recursos é feita renomeando os arquivos e diretórios para a extensão “.rej”. Basta entrar no diretório do profile e executar o seguinte comando:

$ rboss-profile --this --slim [recursos]

Abaixo segue o que pode ser removido e o respectivo parâmetro.

  • Admin Console – admin-console
  • Web Console – web-console
  • Mail Service – mail
  • BeanShell – bean-shell
  • Hot Deploy – hot-deploy
  • UDDI – uddi
  • UUID Key Generator – key-generator
  • Scheduling – scheduling
  • JMX Console – jmx-console
  • JBoss WS – jboss-ws
  • JMX Remoting – jmx-remoting
  • ROOT Page – root-page
  • Management – management
  • IIOP – iiop
  • JBoss Web – jboss-web
  • SNMP – snmp
  • Profile Service – profile
  • EJB3 – ejb3
  • EJB2 – ejb2
  • JMX Invoker – jmx-invoker
  • HA HTTP Invoker – ha-http-invoker
  • Legacy Invoker – legacy-invoker
  • Transaction – transaction
  • Remoting – remoting
  • Properties Service – properties
  • Database/Datasource – database
  • JSR-88 – jsr87
  • XNIO – xnio

Os parâmetros devem ser separados por vírgulas. Se você desejar remover o JMX Console e o Hot Deploy, por exemplo, basta digitar:

rboss-profile --this --slim jmx-console,hot-deploy

Para ver o que foi “removido” (lembre-se de que se trata de uma remoção lógica), use o comando com o parâmetro “-v”.

Se precisar restaurar os recursos removidos, use –restore no lugar de –slim. O comando acima ficaria, dessa forma, assim:

rboss-profile --this --restore jmx-console,hot-deploy

Um abraço a todos!

Simulando Logs no JBoss usando twiddle

Postado em

Neste post farei um jogo rápido sobre como simular logs no JBoss usando twiddle e como isso pode ser útil apresentando dois exemplos práticos.

Basicamente, podemos criar um aplicativo qualquer que use o componente de log do JBoss e receba um input com a mensagem, a categoria e a severidade. Algo bem simples e que pode muito bem ser feito como um aplicativo web, mas, como eu sou fã de linha de comando, vou mostrar como fazer isso usando o twiddle.

Pra quem não sabe, o twiddle é uma forma de acessarmos o JMX do JBoss via linha de comando (pra quem já usou o jmx-console, é praticamente a versão linha de comando dele). A ideia é criar um serviço no JBoss que possa ser utilizado pelo twiddle (e pelo jmx-console, claro). Para tal, precisamos seguir alguns passos:

  1. Criar uma interface com a anotação @org.jboss.ejb3.annotation.Management
  2. Criar a implementação com a anotação @org.jboss.ejb3.annotation.Service
  3. Empacotar tudo e fazer o deploy na instância do JBoss em questão

Como não é o escopo deste post mostrar como criar o serviço e, sim, como utilizá-lo, você pode baixar os fontes no meu github e compilar o projeto (basta usar o ant pra isso e pegar o jar em out/artifacts/jmx-logger.jar).

Assumindo que o jmx-logger.jar esteja no seu JBoss, você pode mandar qualquer mensagem de log usando as severidades do JBoss (trace, debug, info, warn, error e fatal) como o nome do método e os seguintes parâmetros (todos são Strings):

  • mensagem
  • categoria, mensagem
  • categoria, mensagem, exceção

O grande barato é que você pode usar qualquer classe de exceção, mesmo que ela não exista (nesse caso ela será criada em tempo de execução usando o Javassist). Abaixo seguem alguns exemplos de uso:

# simula um warn com a mensagem "atencao"
$ twiddle.sh invoke jboss.system:service=Logging,type=Logger warn atencao

# simula um OutOfMemoryError com a mensagem "heap space" na categoria "org.minhaclasse"
$ twiddle.sh invoke jboss.system:service=Logging,type=Logger error org.minhaclasse "heap space" java.lang.OutOfMemoryError

Você deve estar se perguntando “Tá, mas e onde eu vou usar isso?”. Mostrarei dois exemplos bem interessantes.

Testar configurações de log

Configurar o log pode parecer simples, mas existem casos onde as saídas precisam ser diferentes para cada aplicativo, sqls devem ser gravados em arquivos diferentes e outros casos onde precisamos da aplicação no ar para testar as configurações. Usando um serviço desses, podemos simular os logs das aplicações facilmente e ver se tudo está ok antes mesmo de subir a aplicação. Também podemos testar outras configurações de log sem termos as aplicações no JBoss. É uma excelente carta na manga!

Simular alertas no RHQ

Podemos trabalhar com alertas no RHQ para que, quando uma determinada mensagem for pega no log, uma ação seja disparada. Um exemplo clássico é o OutOfMemory. Podemos criar os alertas e simulá-los usando o serviço jmx-logger. Outra aplicação legal é usar em demonstrações do JOPR pra equipes ou clientes.

Eu sempre usei esse serviço no JBoss 5, mas acredito que seja compatível com o JBoss 6. Já coloquei um TODO pra tornar compatível com o JBoss 7 usando o jboss-cli. Falta só o tempo pra isso 🙂

Introdução ao PicketLink

Postado em

Sei que já dei uma “introdução” ao PicketLink, mas dessa vez vou fazer um post mais detalhando,  portanto vamos lá :

PicketLink é uma solução de IDM que está sendo construida para antender a plataform JBoss. Identity Management (IDM) descreve o gerenciamento de identidades individuais, sua autenticação, autorização e privilégios/permissões dentro de um contexto de segurança.

Exemplos de IDMs concorrentes do PicketLink:

http://www-01.ibm.com/software/tivoli/products/identity-mgr/
http://www.oracle.com/technetwork/middleware/id-mgmt/overview/index.htm

Uma das perguntas mais frequentes e que até eu mesmo me fazia antes de conheçer o PicketLink mais a fundo é: Qual é a referência entre o PicketLink e o PicketBox?

Picketbox (implementa o JAAS) é API que sustenta quaquer implementação de segurança dentro do JBoss Application Server (JBoss AS). O PicketLink está em cima dessa camada e visa fornecer diversas soluções para gerenciamento de identidade.

O PicketLink agrupa vários projetos por exemplo:

  • IDM: Provide an object model for managing Identities (Users/Groups/Roles) and associated behavior using different identity store backends like LDAP and RDBMS.
  • Federated Identity:  Support SAMLv2, WS-Trust and OpenID.
  • AuthZ: Developer friendly authorization framework
  • XACML:  Oasis XACMLv2 implementation.
  • Negotiation: Provide SPNego/Kerberos based Desktop SSO.

Mais informações podem ser encontradas na página do projeto: http://www.jboss.org/picketlink .

PicketLink Federation (PicketLink Federated Identity)

O projeto PicketLink Federation fornece suporte para Federated Identity e Single Sign On.

É oferecido suporte para as seguintes especificações:

Oasis SAML v2.0
Oasis SAML v1.1
Oasis WS-Trust v1.3
OpenID

Planeja-se suporte para:

OAuth

Para utilizarmos o PicketLink Federation devemos entender alguns conceitos de SAML v2.0.

O que é o SAML?

È um padrão para troca de informações de autorização de usuário pela web de uma forma interoperável(xml). O objetivo é que o usuário se autentique em algum lugar e receba um token (identidade), e com esse token ele consiga acessar qualquer recurso que esteja dentro do contexto de segurança onde o token foi emitido.

Nesse contexto podemos destacar as duas entidades: Identity Provider(IDP) e Service Provider(SP).

A especificação SAML possui uma série de profiles, que funcionam como se fossem casos de uso. Por exemplo um dos profiles que vamos abordar nesse post será o Web Browser SSO Profile, que define um caso de uso para SSO utilizando o browser. Para mais informações sobre os profiles do SAML veja o link abaixo:

http://docs.oasis-open.org/security/saml/v2.0/saml-profiles-2.0-os.pdf

O próximo conceito a ser entendido é o SAML protocol binding, que são mapeamentos (canais) padrões para trocas de mensagens SAML entre o IDP e o SP.
Por exemplo no profile(caso de uso) Web Browser SSO é utilizado o HTTP Binding, então toda a troca de informações entre IDP e SP será realizada utilizando HTTP Binding. Existem também outros bindings como SAML SOAP Binding ou Reverse SOAP (PAOS) Binding. Para mais informações sobre o SAML protocol binding veja o link abaixo:

http://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf

Finalmente chegamos ás assertions que são as informações de autenticação e alguns atributos do contexto de segurança.

http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf
http://saml.xml.org/assertions

A parte sobre Authentication Context e Metadata ainda não está totalmente implementada.

 

Ps: Eu vou continuar editando esse post e colocando mais informações (ultimo update  30/06/12)

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.

Como Utilizar o JBoss na porta 80

Postado em Atualizado em

Quando iniciei o meu aprendizado no JBoss tive muitas dúvidas e uma delas foi: Como posso rodar o JBoss na porta 80? Depois de algumas pesquisas observei que normalmente existem duas opções:

1 – Iniciar o JBoss como root

Isso não é recomendado em hipótese alguma.
Em sistemas operacionais Linux/Unix é necessário ser root para que as aplicações escutem em portas TCP / UDP abaixo de 1024.

2 – Utilizar o JBoss com o mod_jk, mod_proxy ou mod_cluster

Pode-se utilizar um proxy e redirecionar as requisições para JBoss. Essas soluções já foram abordadas em artigos anteriores.

Existem também alguns balanceadores como:

Na dúvida consulte uma pessoa experiente que possa indicar as melhores práticas.

Abraços

Blogs sobre JBoss em Português

Postado em Atualizado em

E ai galera blz? Eu sempre acompanho a comunidade JBoss em relação ao artigos, publicações, tutoriais, etc. Vou deixar abaixo a lista de alguns blogs de pessoas que estão fazendo ou fizeram um trabalho bem legal ajudando a comunidade:

Meus parabéns a todos acima. Com a ajuda de vocês a tecnologia JBoss cresce cada vez mais na nossa língua 🙂

Bom existem muitos brasileiros que contribuem com código, até alguns da lista acima mas tentei citar especificamente o pessoal que escreve artigos.

Acho legal também o trabalho do infoblogs que ajuda a divulgar as publicações e o blog da Caelum que sempre divulga as tecnologias JBoss.

Coloquei somente os que conheço… se esqueci de algum por favor me corrijam que eu adiciono nessa lista 🙂

Abraços e Obrigado a toda comunidade JBoss da língua Portuguesa.