Gostaria de saber se podem me ajudar na seguinte especificação:
Preciso montar uma solução aonde o desenvolvedor não precise setar no web.xml quais as urls e as roles que o usuario precisa ter para acessar tal requisição. Esta configuração precisa ser transparente para o desenvolvedor da aplicação.
Por default, nenhum usuário teria acesso a nada na aplicação, e quando fizer qualquer requisição, seja verificado se o usuário tem o acesso para a transação desejada.
As informações de roles para o usuário estão em um ldap.
Estava pensando em utilizar o realm, mas o desenvolvedor tem que indicar no web.xml quais os locais que precisa de autorização, e o que preciso é tirar este controle do desenvolvedor.
Caso o web.xml possa estar em um servidor, com todas as autorizações necessárias, não teria problema, mas a cada transação nova precisarei atualizar o web.xml do servidor na mão, ou posso automatizar isto quando o ldap for atualizado, para replicar as informações no web.xml?
Alguém teria outra solução java para tirar o controle de acesso das mãos do desenvolvedor?
Abraços
Lúcio Camilo
Utilizando Realm para autorização
7 Respostas
Quando você fala em tirar o controle de acesso da mão do desenvolvedor, está se referindo a que? Evitar que ele tenha o trabalho de fazer essa configuração (e consequentemente evitar o risco de erro humano), ou é por questão de segurança (na empresa o desenvolvedor é considerado “não confiável”) ?
Outra pergunta também: Com que frequência são cadastradas novas transações no sistema? É algo que justifique um mecanismo para autorização dinâmica?
Essas respostas são importantes para que o pessoal que vai ajudar possa ter mais idéia da sua necessidade real, e qual a melhor solução.
Gomesrod, quando falo em retirar o controle de acesso da mão do desenvolvedor, me refiro à segurança, partindo do pressuposto que o desenvolvedor poderia não colocar o mecanismo de autorização, ou “burlar” este controle caso esteja nas mãos dele.
Criando um mecanismo que fosse transparente para o desenvolvedor, ele até poderia burlar o sistema, mas somente se programasse com este intuito, o que minimizaria o risco.
As transações novas são criadas com grande frequência, porém eu já possuo estas informações de transações em um Ldap que vou utilizar para manter a solução de acesso.
Hum…
Eu consigo imaginar duas possíveis soluções, uma “manual” e uma “programática”:
-
Continuar com a configuração de segurança no web.xml, só que em produção seria feita por uma pessoa independente dos desenvolvedores.
-
Criar um filtro e mapea-lo para interceptar todas as requisições de páginas. Ele verificaria se o usuário está logado, e se estiver verifica no Ldap se há permissão para o recurso que está tentando acessar. Caso algum desses testes falhe, direciona para uma página do tipo “Não autorizado”.
Gostei da sua solução, poderia me falar mais sobre a utilização do filtro, e como fazer para que todas as requisições passassem por este filtro??
O filtro é simples, a parte mais complexa você já deve ter, que é a consulta ao LDAP.
Faria assim:
-
Crie uma classe que implementa a interface Filter.
-
Dentro do método doFilter, coloque o código que decide se o usuário tem acesso. Se sim, continua a executar a requisição, se não direciona para página de erro.
// Exemplo:
String urlSolicitada = request.getRequestURI;
String usuario = request.getSession().getAttribute("usuario");
// Agora com o usuario e a URL em mãos, passe pela sua rotina
// que consulta o LDAP e verifica a permissão:
if (verificarAcessoUsuario(usuario, urlSolicitada)) {
chain.doFilter(req, res); // Continua o processamento
} else {
// Houve um problema!
RequestDispatcher rd = request.getRequestDispatcher("/sem_permissao.jsp");
rd.forward(req, res);
return;
}
- No web.xml você indica quais solicitações passarão pelo filtro - no caso, todas as páginas:
<filter>
<filter-name>AuthorizationFilter</filter-name>
<filter-class>test.AuthorizationFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>AuthorizationFilter</filter-name>
<url-pattern>*.jsp</url-pattern>
</filter-mapping>
Agora essas duas tags são tudo que você precisa ter no web.xml, e não mais as permissões para cada página. Muito mais fácil de manter sob controle.
Informações básicas sobre filtros, com exemplos: http://java.sun.com/products/servlet/Filters.html
gomes, gostei muito do seu exemplo, porém não sei se resolve, pois a obrigação de colocar o que precisa passar pelo
filtro está com o desenvolvedor, e não tenho como controlar se ele colocou dentro do web.xml ou não, e mesmo se
tivesse, teria alguma forma de obrigá-lo a herdar a classe que vai implementar o filtro, para ele ser obrigado a
acessar através dela, senão todas as requisições seriam negadas por default?
… não sei se resolve, pois a obrigação de colocar o que precisa passar pelo
filtro está com o desenvolvedor…
Na verdade essa configuração é feita uma única vez e nunca mais precisará mexer de novo, não existe risco de alguém esquecer, ou mesmo “fingir que esqueceu”, como você tinha medo no caso da configuração individual para cada página.
Na pior das hipóteses, alguém MUUUUUITO mal-intencionado poderia retirar o filtro antes de fazer o deploy, e aí você logo perceberia pois a aplicação inteira ficaria sem mecanismo de autorização.
Algumas soluções:
- Uma breve inspeção antes de cada subida para produção pegaria o problema antes que pudesse causar prejuizos.
- Utilizar um servidor de aplicações Open Source e modifica-lo para executar suas próprias rotinas de segurança.
Mas o ponto é, antes de sair à procura de mais soluções, você deveria refletir sobre isso: se sua empresa não tem um mínimo de confiança no desenvolvedor e acredita que na primeira oportunidade ele vai arrancar os mecanismos de segurança do aplicativo, infelizmente você vai acabar em um “loop infinito” tentando tirar do desenvolvedor todo controle sobre o sistema sem jamais conseguir - pois enquanto ele tiver acesso ao código-fonte sempre haverá algum ponto “burlável”.