OCWCD - Sobre Declarações de Segurança: Vale ou Valia a Pena?

Jaba,

Existem lugares que ainda utilizam a segurança declarativa pelo Java.

Com isso eles controlam por grupos de usuário de rede, quem pode ou não acessar determinados recursos.

Eu mesmo estou trabalhando em um Projeto para um banco de grande porte, no qual a segurança do aplicativo PRECISA ser feita dessa maneira. (Coloquei o precisa em maiúsculo porque a gente é obrigado a utilizar este “padrão”)

Aproveitando, se você esta estudando para a SCWCD, eu postei um resumos que fiz quando prestei a minha. Caso tenha algum interesse o link é este: http://nykolaslima.wordpress.com/2010/12/17/estudos-scwcd/

Abraços

E aew Nykolas.
Ok, mas precisa por quê?
Essa é a questão. Não consegui achar um sentido em fazer esse tipo de restrição ao invés de colocar no WEB-INF, e as restrições e redirecionamentos corretos serem usados na aplicação.

E aew Nykolas.
Ok, mas precisa por quê?
Essa é a questão. Não consegui achar um sentido em fazer esse tipo de restrição ao invés de colocar no WEB-INF, e as restrições e redirecionamentos corretos serem usados na aplicação.

É padrão do cliente usar segurança declarativa pelo XML. E outra, você colocando as JSPs no WEB-INF só impede que sejam chamadas diretamente do browser, mas não faz controle do que cada usuário pode acessar.

Claro que é importante.

Não tem nada de ultrapassado, o container é responsável por gerenciar a segurança da aplicação.

Ou voce quer usar filtros na mão para controlar a sessão, ou pior fica fazendo “ifs” verificando em cada lugar se o pessoal esta na sessão.

Autenticação, Autorização, confidencialidade e integridade dos dados… deixa para o container.

Vale a pena conferir o post que fiz, quando estudei este assunto.

http://infoblogs.com.br/view.action?contentId=217027&Seguranca-Declarativa-J2EE.html

Então, esse tópico que você está lendo no livro não é desatualizado.
E nos ajuda e muito a configurar corretamente a segurança no projeto.

Imagine um projeto que tudo o que não for acessivel seja colocado dentro do WEB-INF, do jeito que você está sugerindo.
Mas imagine que um dia seu chefe peça para que vários recursos ANTES bloqueados fossem agora acessiveis à vários roles.
Nesse caso você precisaria movimentar vários e vários arquivos de pastas no servidor, configurar o caminho perfeitamente,
testar meticulosamente para ter certeza que tudo funcionou. Olha o trabalho que tal serviço iria dar e qualquer erro seria desastroso.

Mas seria muito muito mais facil que os recursos já estivessem fora do WEB-INF e que fossem controlados as permissões em um simples
arquivo xml chamado web.xml.

Conseguiu entender o ponto ? Se todos os recursos ficassem dentro do WEB-INF teria um trabalho gigantesco para movimenta-los para outro diretorio,
sendo que configurar umas linhas no xml fazeria isso sem trazer dor de cabeça. A gente sempre tem que ter em mente que
os requerimentos podem mudar, e por essa razão sempre devemos fazer a estrutura bem flexivel para evitar dor de cabeça no futuro.

Entendi sobre a necessidade da declaração de restrição de recursos, mas ainda tem pontos que eu acho que são fracos, como por exemplo:

A declaração de usuários nos roles não é nada flexivel:

Imagine um sistema com 100 a 200 usuários, e outra, e se eu quiser fazer um módulo em que se cadastra usuários no sistema? Como eu vou fazer esse controle no XML?

Porque usar filtros para controlar sessão? E não preciso de um monte de if para verificar sessão, basta colocar o controle da sessão no controller, e passar o usuário que está acessando para o Model.
Outra questão também é que a autenticação vai permitir que a autorização sobre um usuário autenticado seja feita, mais e quando eu preciso de uma autorização na regra de negócio, e não em um recurso?

Sim. Fazer o Realm da aplicação utilizando xml não é algo muito flexivel.

Por essa razão o realm nomalmente é implementado no DataBase, para que assim seja
dinamico. Todos os projetos que já participei utilizam essa modelagem.

johnny quest:

Por essa razão o realm nomalmente é implementado no DataBase, para que assim seja
dinamico. Todos os projetos que já participei utilizam essa modelagem.

Se o realm é implementado no database, então a gente volta no ponto que eu citei no inicio, pra que o xml?
No maximo, pra implementar HTTPS, já que o controle de autenticação e o cadastro de usuários vai estar no banco, e talvez um controle de autorização, mais para restringir recursos “globalmente”, já que não é possivel associar um role no XML com um usuário no banco. Alguem discorda?

Blz, e melhor autenticar, mas a questão é essa declaração dos usuários no XML. E aí eu já não sei se é a explicação do livro que é pouca ou se não existe, mais essa sessão não expira?

E outra coisa que eu achei bem fraca também foi essa limitação sobre o xml do container ter o escopo de container, e não de aplicação.

Não conheco, nunca mexi, então, me desculpem se eu tiver falando besteira: O JAAS é muito melhor que esse controle do container, correto? Ele sana todas essas dificuldades?

cara tu ta confundindo tudo.

O xml do “tomcat” é uma maneira proprietária simples de criar usuários.

Normalmente você usa um Realm de dados… que é configurar o tomcat ou qualquer outro container para procurar os usuário no banco. Está configuração é feita no mesmo XML do tomcat.

http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html

Isto é mais complicado de fazer por isto o livro não mostra e opta por usar a forma simples.

Agora a autenticação, autorização e confidencialidade e integridade é no WEB.xml, e sempre vai ser independente de container.

Diabo Loiro:

cara tu ta confundindo tudo.

O xml do “tomcat” é uma maneira proprietária simples de criar usuários.

Normalmente você usa um Realm de dados… que é configurar o tomcat ou qualquer outro container para procurar os usuário no banco. Está configuração é feita no mesmo XML do tomcat.

http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html

Isto é mais complicado de fazer por isto o livro não mostra e opta por usar a forma simples.

Agora a autenticação, autorização e confidencialidade e integridade é no WEB.xml, e sempre vai ser independente de container.

Não to confundindo nada, o problema é que cada um fala uma coisa. E ninguem me dá uma resposta boa ou definitiva sobre o assunto, a impressão que eu tenho é que as perguntas desse topico foram respondidas no chute.
Ninguem falou sobre a expiração da sessão, sobre limitação por container e não aplicação, sobre alguma vantagem do JAAS…

Foram citados varios exemplos por pessoas diferentes falando a mesma coisa… melhor voce ler denovo.

Se fosse para chutar ninguem ia perder tempo postando tentando te ajudar.

Eu já li de novo, e a unica coisa que foi dita duas vezes com redundancia é sobre configurar o realm pra buscar os usuários no banco.

E o negócio do chute, não leva pro lado pessoal não, cara, eu disse que “era a impressão que eu tinha”. Eu nunca implementei segurança dessa maneira em um sistema, por isso as dúvidas e questões. O Assunto é pouco divulgado, o próprio livro da certificação possui pouca informação sobre o assunto e o que possui tem uma boa limitação em uma realidade do dia a dia.

blog diabo loiro:

Antigamente em uma aplicação web nos costumávamos verificar a cada pagina se o usuário tinha permissão de acessá-la através de verificações redundantes ou na melhor das hipóteses usando um filtro Java que é uma solução mais elegante pelo menos? Mais na verdade existe uma maneira bem melhor de realizar essas verificações? Delegando essa responsabilidade para o container! Sim é muito mais elegante e segura, e um container às vezes pode ser bem caro então vamos dar mais trabalho para ele, e facilitar o nosso.

Bom para começar, funciona da seguinte maneira você define restrições de segurança (Security Constraints) para determinados recursos, na verdade é tão melhor que você define restrições para um método HTTP tais como Post, Get, Put etc, ou seja, bem mais seguro, As restrições funcionam como portas temos que dizer quem pode passar pelas portas, e quem pode passar pelas portas?

O começo do post explica um pouco das vantagens por isso que te passei este link ,pois tive essa mesma dificuldade quando estudei esta parte do livro por isso postei, realmente o livro é fraco nesta parte, tem fazer uma aplicação e testar.

afim mais sempre da pra pesquisar mais… porém se vc testar vai sentir na pele a diferença.

a impressão que eu tenho é que as perguntas desse topico foram respondidas no chute

:shock:

Eu respondi as suas perguntas, com o intuito de te ajudar, mas mesmo assim parece que não foi suficiente.
E com certeza não foi por não falar claramente.

Se você não conseguiu entender o funcionamento e o porque vale a pena das declarações de segurança,
então te diria para postar essas mesmas perguntas e indagações no javaranch, e ver as respostas que eles irão te responder.

johnny quest:

Eu respondi as suas perguntas, com o intuito de te ajudar, mas mesmo assim parece que não foi suficiente.
E com certeza não foi por não falar claramente.

Eh, eu já vi que a discussão tomou outro rumo, que não é o de discutir sobre segurança da aplicação.
Foram respondidas claramente sim, mas não abrangentemente, por exemplo, já é a terceira vez que eu cito sobre outras dúvidas, e ninguem dá a sua opnião…

Mas também não vou tomar mérito, como a explicação sobre as restrições de recursos e autenticação e fato de ser possível linkar um cadastro de usuários com o realm de um banco legado.

johnny quest:

Se você não conseguiu entender o funcionamento e o porque vale a pena das declarações de segurança,
então te diria para postar essas mesmas perguntas e indagações no javaranch, e ver as respostas que eles irão te responder.

Eu entendi sim o funcionamento, e deixer claro isso no post, o problema são as limitações e dúvidas, que eu citei acima.

E Diabo Loiro, legal o seu post, mais não abrange nada mais do que o que está no livro. O que eu procuro é algo além, o que se é usado no dia a dia, por exemplo: ao invés de declarar os usuários no XML como o livro faz, é melhor colocar os usuários no banco e fazer o realm procurá-los lá.

Sim cara não tem aplicação em produção que cadastre usuários no XML, e isso ja foi citado varias vezes, o realm é padrão, ou ele pega os usuario de um banco de dados, ou de outro lugar por exemplo um LDAP que são os usuarios do windows por exemplo e usa eles.

A segurança declarativa tbm é padrão se não for por JAAS é por algum outro framework que geralmente trabalha de forma declarativa.

Realmente não está clara a sua duvida, mais como o pessoal estamos tentando explicar.

O assunto é bem simples e se resume a configurar uma vez as permissões e deixar que o container cuide das sessões, de verificar se o usuário logado é autorizado a ver a pagina entre outros.

bom mais agora vou deixar para o pessoal tentar.