@RunAs em ambiente de produção

Não conheço muito bem esse mecanismo, mas se não me engano, ele é feito para rodar com JAAS, não?

[]´s

asaudate:

Não conheço muito bem esse mecanismo, mas se não me engano, ele é feito para rodar com JAAS, não?

[]´s

Sim, exatamente. Ele valida, no caso do RolesAllowed(“TESTE”) se o atual Principal possui a role TESTE.

garcia-jj:

asaudate:

Não conheço muito bem esse mecanismo, mas se não me engano, ele é feito para rodar com JAAS, não?

[]´s

Sim, exatamente. Ele valida, no caso do RolesAllowed(“TESTE”) se o atual Principal possui a role TESTE.

Então, como o JAAS se integra com alguns mecanismos bem interessantes (tipo LDAP), porque não usar o mecanismo todo em produção?

As anotações do pacote javax.annotation.security usam o JAAS para autorização, porém não fazem parte do JAAS.

Acho que eu não expliquei direto, escrevi o post no meio da correria. Na documentação do RunAs há algo assim:

http://download.oracle.com/docs/cd/E17410_01/javaee/6/api/

Ou seja, alí diz que permite ao desenvolvedor testar um EJB forçando ele a rodar como outro Principal. Isso eu sempre usei mesmo para testes, porém estou na dúvida se posso usar assim normalmente sem violar a segurança do sistema, pois eu estou forçando um ANONYMOUS a ser outro usuário. Fiz isso porque não achei outra forma de rodar o scheduler como se fosse um “usuário sistema”.

Minha preocupação é no sentido disso ser portável (embora esteja na spec) e se há problemas nisso rodando em ambiente com o security-manager ativo. Procurei na documentação algo sobre isso, mas não achei nada muito claro se há problemas ou não.

Nao vejo nenhum problema em rodar com RunAs Mas sempre que voce “forca” algo, voce precisa se certificar de que essa informacao eh valida 100% do tempo. No seu caso, significa se assegurar que somente o scheduler vai chamar este EJB.