Try changing that to:
We've already tryed this.. but did not work either.
Should we open an issue for Jboss 5.1.0.GA?
Anyway, thanks for you help.
P.S.: any workaround will be apreciated... We've selled container authentication on jboss 5 for this client, and there is no way to make it work. :-(
I've done what you asked.
Follows two attached files.
- One is using login-module flag="requisite" (i.e. MyClient-login-config-requisite.txt)
- Another using login-module flag="required" (i.e. MyClient-login-config-required.txt)
this will not work any longer in JBoss 5.x:
See Security FAQ ( http://community.jboss.org/wiki/SecurityFAQ ), question 10, for more details. You will need a different login approach.
First of all, thanks for your help.
I read the FAQ's question 10 and all related links. Actually the solution seems to work (I will try it tomorrow), but login is not the only problem here. The biggest problem is security. I don't want to expose my EJBs for anyone who wants to use it. I want only authenticated users being able to use my services.
However, as we could notice, Jboss 5.1.0.GA does not obligate a user to be logged on, even when it is configured for that. In other words, If you lookup an EJB using the code I provided in this thread you will be able to use it, even if the given principal/credentials are incorrect. So, or I'm doing something completly wrong or this is a serious jboss security issue.
Please, let me know if I'm saying something nonsense.
it seems that the log snippets doesn't match the config snippets you posted before, so it is hard to say what's wrong ;-)
The security domain in your config snippets is called "myPolicy", but I don't find this name in the log snippet where "login-config.xml" is parsed. But if there was a typo in your security-domain value, JBoss should fallback to the security config "other" and should deny EJB access. So I would guess hat JBoss does not recognize that you secured your EJBs.
One more guess: your jboss.xml does not declare a DTD/XSD, so it might default to an older DTD version where the security feature is different. Use something like this instead:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jboss PUBLIC
"-//JBoss//DTD JBOSS 5.0//EN"
How do you configure security in the EJB layer? Could you post the annotations (or ejb-jar.xml snippets)?
Sorry, my fault. I didn't want to expose my client, then a replace its name with "myClient". But the name of the application policy configured in loging-config.xml is exactly the same the one used in the security domain defined in jboss.xml (which is inside of my deployed jar). For example:
<login-module code="br.com.xxx.jboss.security.MyLoginModule" flag="required" >
<module-option name = "dsJndiName">java:/OracleDS</module-option>
- META-INF/jboss.xml inside my myEjbJar.jar
About the first guess (Jboss not recognizing that I secured my EJB). That is exactly what I think it is happening. Because, even configuring jboss.xml OR using @SecurityDomain("myClient") annotation, it is not using my MyLoginModule configured.
About the second guess (the DTD/XSD declaration). I've tryied that already. but to be sure I retryied it right now and, unfortunatly, it does not worked. :-(
About the configuration.
1) Firts, I defined the application policy in the loging-config.xml
2) Second, I configured the jboss.xml (which is inside the META-INF of my deployed jar) with the exact name used in the application policy.
2.1) Also, I've tryied to annotate all EJBs implementation with @SecurityDomain("myClient").
About your suggestion (question 10 of Security FAQ). I've been able to make it log in, but the se security issue I've mentioned before is still going.
how did you declare your EJB security definitions (either the "@DeclareRoles" and "@RolesAllowed" annotations or the snippets of ejb-jar.xml)? But I don't assume that there is something wrong, because you wrote that it worked with AS4.
Also note that the annotation "@SecurityDomain" changed the package: in AS4.x, it was "@org.jboss.annotation.security.SecurityDomain", but with AS5, it is "@org.jboss.ejb3.annotation.SecurityDomain" (not really a good idea to change this...).
My problem is only authentication, not authorization. In other words, once a user has been authenticated in the container he/she is authorized to execute any method published in any remote interface.
Even knowing that, I just tested to add @RolesAllowed("admin") in my EJBs. In this case the container has rejected my remote method call once the user is "anonymous" (container does not executed my logging module "MyLoggingModule").
But it seems to be a workaround for my problem. I can log the user in using the solution of provided in question 10 of Security FAQ and give him the "admin" role. Doing that, the the logged in user will be able to execute any methods. However, if someone is trying to lookup my ejbs without using the solution provided in question 10, he/she will be "anonymous" and will not have permission to execute a single method.
I'll will do that right now. After deliver this project I will do some more tests to understand what is going on. I'm planing to get a clean verison of jboss and put only one echo EJB on it.. soh I can give you the code if something strange happens.
Again.. Thanks for your help.. and.. If you come to Brazil I'll pay you some beer.. ;-)
so your security worked in JBoss 4.x without using any "@RolesAllowed" declarations, you could secure your beans by simply declaring a security domain?
Well, I think the JavaEE standard forces you to secure your EJBs at class or method level, there is no "secure the whole deployment" method - probably it was more or less an "error" in AS4 ;-).
The way from Germany to Brazil is quite long, so I fear you will have to drink the beer yourself ;-).
About the jboss 4.x.. Exactly.
About the beer.. I would suggest you to come down here in Brazil to see Germany lose the final match against Brazil, of course, in the next world cup. So I would pay you a hundred of beers for consolation. hehehe.. ;-)
Being serious.. thank you very much..
P.S.: just joking around, you know..
In 2014, the young German team of 2010 will be at full strength - so take care ;-).
But better 100 beer for me than a world cup for others :-)