Olá GUJ! 
Eu tenho algumas dúvidas sobre o uso do LDAP.
- É possivel usar o LDAP para definir níveis de permissões de acesso? Como?
- Alguém já fez Sigle Sign-On (em aplicação Web) com Oracle, JASS e LDAP e tem algum material para me passar?
Obrigado
furutani,
Trabalho com OpenLdap mas é só para autenticação simples mesmo, infelizmente não vou pode ajudar com suas dúvidas. Mas segue 2 links que uso com referência:
http://www.ldapguru.com/
http://www.openldap.org/
ASOBrasil
Olá ASOBrasil,
Para fazer autenticação simples não vejo grandes dificuldades, o problema mesmo é o esquema de permissões.
Obrigado
Sim, é possível fazer controle de nível de acesso. Eu utilizo grupos do notes para definir os níveis. Tenho isso feito utilizando jboss e struts. Posso te passar o código que utilizei no login-config.xml e no web.xml, outro código não tenho permissão de ceder.
Sobre single sign-on, não sei como isso funciona, poderia explicar?
Se você puder me passar eu agradeceria.
O que faz esse outro código?
[quote=soaresinfo]
Sobre single sign-on, não sei como isso funciona, poderia explicar?[/quote]
É uma tecnica onde o usuário se autentica em apenas um lugar e todos os outros serviços usam essa autenticação, assim o usuario não precisa ficar digitando a senha para cada serviço.
No wikipedia tem uma descrição mais detalhada.
No meu caso eu precisava fazer isso com oracle, pois usuário que vai logar na aplicação web deve ser o mesmo usuário do banco.
Obrigado
Esse aqui é o código no login-config.xml
<authentication>
<login-module code = "org.jboss.security.auth.spi.UsersRolesLoginModule"
flag = "required" />
</authentication>
</application-policy>
<application-policy name="MEU-REALM">
<authentication>
<login-module code="br.com.inovar.realm.OpenLdapNotesModule" flag="required">
<module-option name="java.naming.factory.initial">com.sun.jndi.ldap.LdapCtxFactory</module-option>
<module-option name="java.naming.provider.url">ldap://10.32.8.137:389/</module-option>
<module-option name="java.naming.security.authentication">simple</module-option>
<module-option name="principalDNPrefix"></module-option>
<module-option name="principalDNSuffix"></module-option>
<module-option name="rolesCtxDN"></module-option>
<module-option name="roleAttributeID">CN</module-option>
<module-option name="uidAttributeID">member</module-option>
<module-option name="matchOnUserDN">false</module-option>
<module-option name="ctxSearchUserForRole">O=<Empresa aqui>,C=BR</module-option>
<module-option name="attributeUserID">uid</module-option>
<module-option name="attributeInUserForRole">creatorname</module-option>
<module-option name="attributeThatDefineUser">objectclass</module-option>
<module-option name="attributeValueThatDefineUser">dominoPerson</module-option>
<module-option name="attributeThatDefineRole">objectclass</module-option>
<module-option name="attributeValueThatDefineRole">dominoGroup</module-option>
</login-module>
</authentication>
</application-policy>Modifiquei o código em ctxSearchUserForRole, pois depende da configuração do notes na empresa. O código que te falei que não podia passar é a item OpenLdapNotesModule, essa classe estende a classe LdapLoginModule do jboss, na verdade ele é só um backup caso a configurações acima falhem.
Configurando o web.xml:
<login-config>
<auth-method>FORM</auth-method>
<realm-name>MEU-REALM</realm-name>
<form-login-config>
<form-login-page>/Login.do?dispatch=login</form-login-page>
<form-error-page>/Login.do?dispatch=erro</form-error-page>
</form-login-config>
</login-config>**Coloque o nome do realm do login-config
Agora para definir o nível de acesso das páginas eu utilizei as seguintes configurações no web.xml, eu escrevo uma definição para cada grupo do notes como segue exemplo:
<security-role>
<description>Perfil de Acesso para os Cooperados</description>
<role-name>NOME-DO-GRUPO-NO-NOTES</role-name>
</security-role>Para definir quem pode acessar cada página, coloque uma definição para cada action (suponho que uma action faz uma funcionalidade completa independente de quantas páginas use):
<security-constraint>
<web-resource-collection>
<web-resource-name>Acesso a Ver Operações em Equipamentos </web-resource-name>
<url-pattern>/app/VerLogOperacoes.do</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>MEU-GRUPO1</role-name>
<role-name>MEU-GRUPO2</role-name>
<role-name>MEU-GRUPO2</role-name>
</auth-constraint>
</security-constraint>Apesar do topico ja ser antigo e eu estar ressucitando.
SIM é possível essa solução. Ja utilizei o sistema de login baseado em JAAS e ja implementado pela maioria dos AS que conheço. Ja utilizei e testei no tomcat um sistema conectando ao OpenLDAP e com diversos níveis de permissão. Outra característica foi a implementação do Single Sign On, que é bem fácil de ser implementado no tomcat.
Creio que o link abaixo possa ajudar:
Eu acabei implementando na mão tanto a autenticação quanto o controle de permissões através de grupos.
Foi bem mais traalhoso que usar o AS, mas ficou um tanto mais flexível aos sistemas internos aqui.
[quote=Rafael Nunes]Eu acabei implementando na mão tanto a autenticação quanto o controle de permissões através de grupos.
Foi bem mais traalhoso que usar o AS, mas ficou um tanto mais flexível aos sistemas internos aqui.[/quote]
É da mais trabalho mesmo, porem consegue atender a necessidades específicas. Mas na maioria do caso o módulo dos ASs dão conta do recado e ganham bastante tempo.
Em geral o desenvolvimento de sistemas de autenticação baseado em JAAS além de ser padrão é bem mais ágil e flexível que os outros, seja ele o do AS, uma versão customizada ou mista. Não sei porque só a minoria das pessoas usam.
[quote=J.E.Z]
Em geral o desenvolvimento de sistemas de autenticação baseado em JAAS além de ser padrão é bem mais ágil e flexível que os outros, seja ele o do AS, uma versão customizada ou mista. Não sei porque só a minoria das pessoas usam.[/quote]
Para mostrar uma outra visão interessante também: J2EE Security: Container versus Custom
Tem colocações muito pertinentes nesse artigo… Estou em um projeto de Single Sign-On para aplicações Java e sofremos um diabo com esse JAAS, tanto que abandonamos para fazer da maneira Custom… é mais trabalhoso mas o JAAS nao dá conta da flexibilidade necessária no nosso caso.
Valeu!
Abs
Os dois principais problemas que me fizeram desistir do JAAS foi a falta de flexibilidade para diversos cenários que eu tenho e também replicação em clusters e tiers diferentes.
Não entendi. No final ele conclui que há espaço para autenticação por container (ou JAAS), ou seja, ele não descarta JAAS.
Pq sofreu!? Qual a necessidade que vc tinha que JAAS não atendia!?
Taz, eu nao disse que JAAS é descartável… é que no outro post a galera disse “não sei porque tem gente que nao usa JAAS”… essa é uma visão que o artigo citado contraria, dizendo que tanto a autenticação via container e a customizada tem seu espaço.
Uma série de coisas cara… a primeira delas foi que o Web Service que autentica (e que portanto devia ser chamado do método login()) não se contenta com nome e senha, precisa também do nome do usuário logado atualmente na máquina (que pode ser diferente do informado no form de login) e o domínio Windows do mesmo, além do IP da máquina cliente. O JAAS para J2EE só possui nativamente o NameCallback e PasswordCallback, o que me quebrou as pernas… consegui dar uma volta nele usando o JAZNContextCallback que é proprietário da Oracle no servidor dela, o OC4J, e acabei conseguindo o IP, mas o resto necas…
Outra coisa que nao consegui foi empacotar a implementação do JAAS com a aplicação, já que os meus servidores ficam todos nos Estados Unidos, e não temos acesso para instalar o LoginModule localmente, precisamos que cada aplicação mande o LoginModule no WEB-INF/lib. Neste caso, tomei um pau feio dos descritores da Oracle, o orion-application.xml e o jazn-data.xml… não faz deploy nem com reza.
Abraços!