O evento ocorrerá nos dias 07 e 08 de Maio e contará com palestrantes internacionais, commiters de projetos JBoss, consultores Red Hat, especialistas no segmento Telco e representantes das maiores Java Education Centers do país.

No dia 07 de Maio serão realizados os workshops. Serão três salas onde os participantes poderão não só ouvir mas codificar, podendo tirar dúvidas ali mesmo com os especialistas.

Serão seis workshops que ocorrerão em dois horários distintos: o primeiro horário das 13:30 às 15:30, e no segundo horário das 16:00 às 18:00.

Os seguintes workshops serão realizados no primeiro horário:

* JPA 2.0 na prática, com Hibernate – Paulo Silveira (Caelum)
* Administração e Tunning JBoss Application Server 5 – Bruno Machado (Red Hat)e Samuel Tauil (Red Hat)
* Social Networking by Phone – Utilizando SeamTelcoFramework – Antonio Anderson Souza (Voice Technology) e André Pantalião

Já os workshops abaixo serão realizados no segundo horário:

* JSF 2.0: Uma evolução nas interfaces web com Java – Alberto Lemos, Vinicius Senger e Yara Senger (Globalcode)
* Virtualização e Federação de Dados – Leandro Abite (Red Hat)
* Fundamentos do Drools Platform – Alexandre Porcelli (Caravela Tech/Drools Project) e Mauricio Salatino(PlugTree/Drools Project)

No dia 08 de Maio ocorrerá a conferência, onde palestrantes internacionais e vários palestrantes nacionais compartilharão as novidades das tecnologias JBoss.

Um dos palestrantes internacionais é Pete Muir, líder do projeto Seam e Weld (Implementação de referência da JSR 299 – Contexts and Dependency Injection for Java EE), além de desenvolvedor líder do Aquillian, um conjunto de utilitários para testes de Servidores de Aplicação.

Outro palestrante internacional é Benjamin Mestrallet, CEO da eXo Platform, uma empresa francesa que ele fundou logo após a universidade para atender seu primeiro cliente: Departamento de Defesa Americano. Com a recente expansão da eXo para os EUA, Benjamin supervisiona de São Francisco-EUA o crescimento da companhia, marketing e estratégia de vendas. Ele criou o projeto eXo enquanto ainda estudante em Dezembro de 2002, entregando o primeito Java Portlet Container da indústria.

Mauricio Salatino, outro palestrante internacional, é CTO na PlugTree, uma empresa especializada no fornecimento de soluções usando a plataforma Drools com escritórios em Miami, EUA e Buenos Aires, Argentina. Maurício é committer no projeto Drools, e vem desenvolvendo inúmeros projetos com os conceitos de Motor de Regras, CEP(Complex Event Process) BPM e portais com Alfresco. Autor do livro: jBPM Developer Guide pela PacktBuk, é o fundador do grupo de usuários JBoss da Argentina (http://www.jbug.ar).

Para ver a localização correta do local do evento e os hotéis mais próximos, acesse o mapa.

Participantes do Falando Em Java terão desconto na inscrição, que pode ser feita aqui.

Você pode verificar a grade completa dos workshops e das palestras nesse link.

Você pode verificar a grade completa dos workshops e seus tutoriais e das palestras nesse link.

Na realidade o poder do JAAS provém de sua arquitetura plugável, o que permite aos Servidores de Aplicação JavaEE utilizarem sua estrutura tanto para autenticação/autorização em componentes EJB, como em aplicações web ou serviços de mensageria. Além disso a implementação do acesso aos dados de autenticação também fica abstraída da sua aplicaçao, ou seja, não é necessario saber se esta autenticando em LDAP, database ou file-systems, quem resolve isso é a configuração login-module do JAAS de seu Servidor.

Mas mesmo assim o Security Service do servidor de aplicação é limitado. Como não poderia deixar de ser, o JAAS implementado pelo container só pode agir sobre objetos gerenciados pelo container como EJBs e Servlets, ou seja, os POJOs de sua aplicação fica de fora. Outra limitação é que embora possa restringir contextos de páginas pelo serviço de segurança JAAS do container, ele não é capaz de restringir acesso ou visibilidade de “trechos” de uma página, como uma caixa de texto por exemplo.

Por essas e outras, soluções “paralelas” de segurança começaram explodir pela marginalidade da especificação, tendo destaque o Spring Security (ACEGI) e o Seam Security, cobrindo as brechas deixadas pelos servidores.

A solução do Seam para segurança é bastante completa e pode ser uma simples configuração de papéis e credenciais, uma elaborada solução de Identity Managment out-of-box para databases ou LDAP, marcadores baseados em anotações com políticas de acesso para POJOs, EJBs, páginas e trechos de páginas ou ainda complexas regras codificadas em um engine de regras (Drools) externas a aplicação. Na verdade, apenas com a configuração de credenciais e papéis já dá pra fazer MUITA coisa.

Por exemplo:

public class Authenticator implements AuthenticatorI{

    @In Identity identity;
    @In Credentials credentials;
    @In UserRepository userRepository;
    @Out(required=false) User user;

    public boolean authenticate(){

        //aqui lógica de autenticacao XPTO
        User user  = userRepository.getByCredentials(
                        credentials.getUsername(),
                        credentials.getPassword());

        if(user!=null){
                for(Role role:user.getRoles()){
                    identity.addRole(role);
                }
                return true;
        }
        return false
    }
}

Na autenticação bem tradicional do Seam logo acima, vários papéis(roles) são adicionados a identity no login. Com isso é possível fazer:

- proteger uma classe:

@Restrict(“#{s:hasRole(‘auditor’)}”)
public class Inventory(){
….
}

- um método:

@Restrict(“#{s:hasRole(‘mailer’)}”)
public void sender(Mail mail){
….
}

- trechos de páginas

<h:commandButton action=#{car.run} value=”Run” rendered=”#{s:hasRole(‘booster’)}”>

O problema é: as vezes uma aplicação baseada em Seam Security precisa acessar EJBs protegidos no Security Service do servidor de aplicação. Pra piorar, o Seam apesar de lidar bem com seus componentes, ele nativamente não propaga sua autenticação/autoriazação para os objetos gerenciados apenas pelo container.

Para superar isso no JBoss é simples. No diretório do JbossWeb (tomcat embarcado) no servidor, existe um jar chamado jbossweb-service.jar. Este jar possui a classe responsável pela autenticação JAAS do container web, e propaga isso também para o container EJB. Então, apenas é necessário adicionar este jar ao classpath e alterar a classe de autenticação para algo como:
…

    public boolean authenticate(){

        //aqui lógica de autenticacao XPTO
        User user  = userRepository.getByCredentials(
                                credentials.getUsername(),
                                credentials.getPassword());

        if(user!=null){
                for(Role role:user.getRoles()){
                    identity.addRole(role);
                }

                //propagando para o container
                WebAuthentication webAuthentication = new WebAuthentication();
                webAuthentication.login(credentials.getUsername(),
                                        credentials.getPassword());

                return true;
        }
     }

…

Além de fornecer as credenciais para o container, também é necessário dizer qual a Application-Policy JAAS do container será usada para fornecer as roles desta autenticação. Para tal, basta adicionar o arquivo jboss-web.xml no war do projeto (em WEB-INF), contendo:

<jboss-web>
    <security-domain flushOnSessionInvalidation="true">
       java:/jaas/nomeDaSuaRelmJAAS
    </security-domain>
</jboss-web>

Beleza, agora você pode acessar tanto EJBs e POJOs protegidos pelo Seam, como EJBs isolados protegidos pelo container.

Hmmm, mas perae, ainda parece não estar legal. Parece que estou duplicando código. O mesmo código que uso para pesquisar o usuário, recuperar suas Roles e adicionar para o Seam, o container vai ter que fazer também. Então porque não uso diretamente o código de autenticacao do container também para o Seam? Isso me parece razoável e possível.

Para isso temos que modificar a tag security do components.xml:

disso:

<security:identity authenticate-method="#{authenticator.authenticate}" />

para isso:

<security:identity  jaas-config-name="nomeDaSuaRelmJAAS"/>

Quando é feita essa configuração não precisamos mais implementar uma classe de Autenticação que fara uma pesquisa em algum lugar retornando o usuário e seus direitos, o container faz isso pra gente. Isso é possível porque o Seam obedece a mesma estrutura de Autenticação/Autorização do container, ou seja, também é baseada em JAAS, logo pode delegar para o Server esta tarefa.

Mas o problema de propagação para o container ainda existe, aquele código de WebAuthentication ainda é necessário. Mas agora fica a pergunta, se não temos mais a classe de autenticação já que o container esta fazendo isso, onde colocar este código extra?

O Seam possui suporte a configuração de Listeners e Observers para QUALQUER um de seus componentes. É bem simples fazer uma configuração que represente a idéia: “Sempre que ocorrer um evento de Login, execute determinado código”. Na prática isso seria:

login.page.xml

   <navigation from-action="#{identity.login}">
     <rule if="#{identity.loggedIn}">
         <raise-event type="loginEvent"/>
         <redirect view-id="/home.xhtml"/>
      </rule>
   </navigation>

Com isso configuramos um evento chamado loginEvent. Agora o Observer do evento:

@Name("loginListener")
public class LoginListener {
        @In
        private Identity identity;

        @Observer("loginEvent")
        public void configJaas(){
                WebAuthentication webAuthentication = new WebAuthentication();
                webAuthentication.login(identity.getCredentials().getUsername(),
                                        identity.getCredentials().getPassword());
        }
}

Pronto!!! Agora através da mesma configuração no servidor podemos ter configurados EJBs Standalones, Webservices, Filas de mensagem e a própria aplicação Seam, tudo no servidor. Se a configuração da aplicação para buscar usuarios e direitos mudar de banco de dados para LDAP, FileSystem ou qualquer outra coisa, nenhuma linha da aplicação precisará ser alterada.

Ops, tem uma pegadinha neste “identity.getCredentials().getPassword()” do último código que deixo para o próximo post

Para quem não me conhece, meu nome é Alessandro Lazarotti (err, o nome do blog) – Jundiaiense torcedor do Palmeiras -  trabalho atualmente na divisão JBoss da Red Hat em São Paulo na área de consultoria e treinamentos. Algumas pessoas me chamam de Alessandro/Ale/Lê/Lezinho/Laza, qualquer um destes codinomes perigosos, eu atendo.

Como não poderia deixar de ser, o foco deste blog vai ser mesmo tencologia e afins, contudo algum besteirol cotidiano também será serventia da casa.

Alguns dos primeiros assuntos que abordarei irão ser retroativos, para poder colocar a ordem em casa, portanto que ninguém se assuste comigo falando de JustJava agora em novembro.

Eu auto-apresentado, blog apresentado, só falta agora o conteúdo =)
Já Já eu volto com “algunas cositas más”.

Abraços e sejam bem-vindos