Sorry for attaching the war with the wrong context.xml After several tests, I ended up testing a custom realm. I've reverted it to a previous version which uses a JaasSecurityRealm, and the login module, as stated on the issue description. Also, when removing the initial context factory property, I think I get a standard tomcat initial context, because it doesn't find the ejb. Thanks.
Luis Fernando Planella Gonzalez [EMAIL PROTECTED] Dain Sundstrom escreveu: > [I attached this comment to the JIRA issue > (https://issues.apache.org/jira/browse/OPENEJB-901), but I think > everyone may be interested, so I'm reposting it here] > > I modified the OpenEJB ejb-examples for Tomcat to use a custom realm > and it is working for me. Attached is the ejb-examples.war file and > realm.jar. Place the war in the Tomcat webapps director and realm.jar > in the Tomcat lib directory, and then visit > http://localhost:8080/ejb-examples URL. Click the secure link and > enter the user name manager with password manager. > > Here is the code for my CustomRealm: > > package org.superbiz.servlet; > > import java.security.Principal; > import java.util.Arrays; > > import org.apache.catalina.realm.RealmBase; > import org.apache.catalina.realm.GenericPrincipal; > > public class CustomRealm extends RealmBase { > protected String getName() { > return "CustomRealm"; > } > > protected String getPassword(String user) { > System.out.println("CustomRealm.getPassword(" + user + ")=" + > user); > return user; > } > > protected Principal getPrincipal(String user) { > GenericPrincipal principal = new GenericPrincipal(this, user, > user, Arrays.asList(user, "user")); > System.out.println("CustomRealm.getPrincipal(" + user + ")=" + > principal); > return principal; > } > } > > Basically, any user is allowed and the password is the same as the > user name. The user is granted the role "user" and a role that has the > same name as the user name. > > The only modification I made to the ejb-example code was to add <Realm > className="org.superbiz.servlet.CustomRealm"/> to the context.xml > file. You can find the code for ejb-examples at > https://svn.apache.org/repos/asf/openejb/trunk/openejb3/examples/webapps/ejb-examples > > > > If you are still having problems, I will need your CustomRealm class. > > -dain > > On Aug 23, 2008, at 2:07 PM, Dain Sundstrom wrote: > >> I couldn't get he example to run because it is missing the >> CustomRealm class. One issue I see it the use of the OpenEJB >> LocalInitialContextFactory. When integrated into Tomcat JNDI ejb >> references and @EJB injection work automatically, so there is no need >> to use the LocalInitialContextFactory. This is unlikely the cause of >> the security problems you are seeing unless you try to login using >> the context. I'd just remove all the JNDI code and rely on >> injection... it will just work. >> >> On Aug 22, 2008, at 4:13 PM, Dain Sundstrom wrote: >> >>> Sorry, I haven't responded earlier... been kinda off the grid lately. >>> >>> This is really weird. The code is designed to pickup the real >>> associated the web app and propagate it to the EJB container (see >>> TomcatSecurityService.enterWebApp(Realm realm, Principal principal, >>> String runAs). The defaultRealm in the code is only used for EJB >>> calls from a remote VM. >>> >>> As you mentioned TomcatSecurityService should override >>> isCallerInRole() which is part of the problem you are seeing, but >>> I'm not sure it is all of it. >> >> After further reading, the TomcatSecurityService shouldn't override >> isCallerInRole. This code is very tricky, but is required by the >> JACC JEE spec to be implemented this way. Here is the code for the >> isCallerInRole method: >> >> public boolean isCallerInRole(String role) { >> if (role == null) throw new IllegalArgumentException("Role >> must not be null"); >> >> ThreadContext threadContext = ThreadContext.getThreadContext(); >> SecurityContext securityContext = >> threadContext.get(SecurityContext.class); >> >> try { >> CoreDeploymentInfo deployment = >> threadContext.getDeploymentInfo(); >> >> securityContext.acc.checkPermission(new >> EJBRoleRefPermission(deployment.getEjbName(), role)); >> } catch (AccessControlException e) { >> return false; >> } >> return true; >> } >> >> This method redirects the isCallerInRole to a VM security check for >> the permission EJBRoleRefPermission. The trick is we have installed >> a JACC compliant java.security.Policy. When the security >> checkPermission method is executed, the call is redirected to >> BasicPolicyConfiguration.implies(ProtectionDomain, Permission) which >> in turn call back into the TomcatSecurityService getLogicalRoles >> method. This trip through the VM security lay is required by the >> JACC spec and gives the user a spec-compliant way to completely >> replace the authroization system. >> >> The net effect is we call >> user.getRealm().hasRole(user.getTomcatPrincipal(), logicalRole) to >> determine if a user has a role. The realm is the realm we received >> in the OpenEJBValve when the application was entered. >> >> >> I'm going to play with the security ejb-examples we have for Tomcat >> to see if I can reproduce the error you are seeing. >> >> -dain >> >> > >
