Autenticação de usuários com o vraptor 4

[Fabrício Cabral]

Olá todos!

Pretendo desenvolver um sistema no qual vou precisar:

- Autenticar usuários;

- Controlar quais usuários podem ou não acessar determinadas

funcionalidades;

- Manter um log de qual usuário, fez tal alteração e quando ela

foi feita.

Assim, de acordo com este cenário, o que vocês recomendam

para trabalhar com o vraptor  4. Vi que existe um plugin chamado

vraptor-shiro, mas será que ele vai me atender?

Agradeço a atenção!

--
--fx

[Otávio Garcia]

Eu utilizo aqui o JAAS em um ambiente Java EE, que faz toda a autenticação e autorização automaticas. Mas você pode usar o mesmo conceito no Shiro, já que eles são semelhantes.

Cada funcionalidade no sistema tem uma ROLE necessária para acessar. No cadastro de usuário, por exemplo, tenho as roles: CUSTOMER (pode listar os clientes e ver informações básicas), CUSTOMER_EDIT (pode adicionar e editar as informações dos clientes), CUSTOMER_SUBSCRIPTION (pode adicionar/editar assinaturas ao cliente), CUSTOMER_COLLECTIONS (pode visualizar informações de cobrança), e assim por diante.

Quando um administrador cria os grupos, ele define as roles que cada grupo possui. E cada usuário possui um grupo.

O login é feito pelo container via JAAS, que carrega as roles do usuário na autenticação. Na hora de carregar o menu verifico se o usuário possui as roles de cada item de menu e o carrego somente com os que o usuário pode acessar.

A autorização de cada recurso é automatico pelo container, onde anoto meus EJBs com @PermitAll, @RolesAllowed, etc. Se para execuctar um método eu preciso da role CUSTOMER_SUBSCRIPTION, eu apenas anoto este método com @RolesAlowed("CUSTOMER_SUBSCRIPTION").

Para manter um log de tudo que o usuário fez você pode usar o envers. Para cada alteração em uma entidade anotada com @Audit guarda os dados da alteração. Para mais info dê uma olhada no Hibernate Envers. A documentação é bem curta.

--
You received this message because you are subscribed to the Google Groups "caelum-vraptor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to caelum-vrapto...@googlegroups.com.
To post to this group, send email to caelum-...@googlegroups.com.
Visit this group at http://groups.google.com/group/caelum-vraptor.
For more options, visit https://groups.google.com/d/optout.

[Marcio Angelo Matté]

Boa noite Otávio, 

permita-me a intromissão no post, mas é que o tema muito me interessa. Eu realizei alguns testes com o Shiro, mas acabei abandonando, não por deficiência, longe disso, até acho que o plugin é muito interessante. Pelas minhas andanças (googlando) por aí, vejo que o tema é realmente complexo pois depende muito de cada caso. Creio que se busque algum modelo meio "pronto", no estilo extends isso, implements aquilo e a coisa aconteça, só que neste tema, sinceramente é muito individual. Confesso que ainda estou estudando mais aprofundadamente o JAAS e espero consegui implementar algum mecanismo realmente eficiente. A ideia seria fazer algo como o controle de autenticação do Wildfly, que inclusive acho ser o modelo que você sugeriu. O problema eu acho que a coisa é pensar nisso levando em consideração o VRaptor, ou o SpringMVC, onde as ações normalmente são os métodos e aí vem as vezes dúvidas, como: se eu tenho um método add(Entity anny) e hoje  eu uso um @Allowed("ADMIN") e amanhã haja a necessidade de um @Allowed("ADMIN","OUTRO_QUALQUER"), como implementar sobre o ponto de vista do uso do VRaptor. 

Creio que nós menos experientes no assunto estamos enfrentando mesmo é a questão implementação e com certeza o conceitual também.

Bom.. não sei se o texto foi claro rsrsrrs, mas é mesmo apenas para discutir, mas que este post merece um debate e troca de experiências não tenho duvidas. 

Forte abraço a todos!

Att

--
Marcio Angelo Matté
marcio...@gmail.com

[Fábio Brandão]

Márcio,

Concordo com vc, esse é um excelente assunto para discutir.

Quando comecei a usar Vraptor nos meus projetos comecei com o SACI desenvolvido pelo bronx. Até hoje utilizo ele pois acho fácil e simples sua codificação, porém faz muito tempo que não tem atualização para esse plugin, problema quando eu for migrar para o vraptor4.

Gostaria de saber tbm oq a comunidade anda utilizando no novo vraptor4 e seus devidos feedbacks referente a autenticação.

Abraços

Fábio Brandão
Desenvolvedor Java/Android

www.mecanicasonline.com.br

www.brandom.com.br

www.tiempregos.com

@fabiocbrandao

+55 (11) 98683-6618

[Rodrigo Turini]

porém faz muito tempo que não tem atualização para esse plugin, 
problema quando eu for migrar para o vraptor4.

a migração desse plugin será bem simples, se quiser pode abrir uma

issue que faço, ou até mesmo tentar migrar que vamos te guiando :)

Gostaria de saber tbm oq a comunidade anda utilizando no novo 
vraptor4 e seus devidos feedbacks referente a autenticação.

além do que já foi mencionado, pessoal tem falado bem do brutalth.

Ele é usado pelo guj.com.br e tem feito bem o trabalho. um abraço 

Rodrigo Turini

Caelum | Ensino e Inovação
www.caelum.com.br

[Leonardo Wolter]

Oi pessoal,

Como o rodrigo ja disse, uma opção seria utilizar o https://github.com/leocwolter/vraptor-brutauth, que oferece uma boa estratégia de autorização e ja suporta vraptor4.

Abraço!

[Chico Sokol]

O brutauth é mega flexível e cuida bem da parte de autorização. Também tem o vaas: https://github.com/asouza/vaas. Ele também cuida de autenticação e é integrado com o jaas.

--
Chico Sokol

[Otávio Garcia]

Marcio, tudo bem? Desculpe a demora em responder. Acabei perdendo esta thread de vista.

O JAAS é uma especificação, e cada container pode implementar da forma que desejar. E o Wildfly possui uma implementação muito boa de JAAS, com vários conectors para database, autenticação por certificados, etc.

Só que a autenticação só funciona para beans gerenciados pelo container e não é integrado ao CDI. Ou seja, funciona bem nos EJBs e servlets, mas não nos controllers do vraptor.

Mas você pode criar um interceptor para isso, que faz o mesmo que os EJBs fazem. O que você precisa validar é se o usuário atual (o Principal) possui as roles que seu método está anotado. Lembre-se que o JAAS sempre faz um OR nas roles, ou seja, se você anotar @RolesAllowed("role1", "role2"), quem tem a role1 OU a role2 pode acessar o método.

No entanto acho que se você tiver que implementar algumas coisas assim na mão, talvez valha a pena usar o bruthauth, que já faz tudo isso sem você precisar ter muito trabalho. Eu particularmente deixaria o controle de permissões nos EJBs.

Abraço

[Marcio Angelo Matté]

Legal Otávio, realmente o tema, como mencionei em resposta, é muito interessante!

Eu estou estudando mecanismos para fazer isto e talvez o bruthauth seja um que mereça mais atenção. Eu ainda tenho minhas duvidas justamente em como fazer certas coisas dinamicamente. Pelo teu exemplo a anotação @RolesAllowed("role1", "role2", ..., "roleN") é o que preciso, mas acho ainda um pouco nebuloso torna isso dinâmico. Ou seja, se eu criar uma RoleQualquer, tenho que ir no código e acrescentar tal role ao método anotado. Compreende? Quando falei do JAAS no Wildfly eu estava me referindo à forma de criar GRUPOS e PAPEIS a atribuir os usuários, porém depois dizer quais recursos do sistema tais grupos ou papeis terão acesso. Acho que não me fiz entender... 

Vou ver bem o Bruthauth mais a fundo.. pois nunca utilizei.. 

Mesmo assim, valeu pela discussão :D

Forte abraço!