RE: -- Arved -- Can you please help me with servlet authentication?
Hi, Tim Our servlet has nothing whatsoever to do with Servlet-2.x style authentication. We only have one servlet, and our application model is not predicated on having umpteen JSPs and content pages to jump around to and set security constraints on. We don't use a jndi.properties for authentication. The servlet is dumb, and is primarily concerned with being there as a known point for receiving requests and issuing responses. There is no great mystery revealed by indicating that we have an event-based application; security is naturally event-based (i.e. "You in this role can either send this event or you can't") from the user viewpoint. Logging in is just another event - we typically use a form but _we_ create it, and the gathered username and password are just strings being passed further down into programmatic RoleManager code (roleManager.login(), in other words). Our approach to security, IOW, is along the style of isPrincipalInRole(), not EJB-style fine-grained method permissions. We consider this latter to be nice in theory but not much use in practice, since it doesn't correspond well to the granularity of what users do. Could we set method permissions? Of course - the user is always in some role, and we are controlling what role they are in. We just happen not to use this form of security. I might add that the interface to the servlet, because of an event-handling approach, exposes very few methods and they are not suitable for EJB-style method permissions type security control anyway. As far as the problem of N users hitting 1 servlet, if you're doing what we do then there is no confusion. You end up writing your session management anyway, to ensure that the servlet, for a given user, is handling off the requests to a valid and correct SB. The SB in question can retrieve the correct Principal as required, based on username, and do the role check. You'll understand that we are using 100% programmatic user management. Also, I think (in your last few paras) that you are close to answering your own question. If you've got multiple users and you cannot rely on a jndi.properties, then by exclusion you must rely on the users to supply their identity. We use a form to gather the username and password when we need them; client certs would also work. HTH, Arved -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres Sent: Tuesday, November 21, 2000 7:07 PM To: Orion-Interest Cc: Arved Sandstrom Subject: RE: -- Arved -- Can you please help me with servlet authentication? Hi Arved, Although we have a single servlet front-end, and do programmatic usermanagement (including login), the actual user manager and role manager stuff all happens down in EJB-land (in a session bean being referenced from the servlet). So we do not use JNDI properties at all for authentication, except for some secondary application clients. Are you saying that you simply ignore EJB-based permissions, and manage all of the access internally in your session beans? This is the approach that I want to take, but I want to be sure that only my servlets can actually get to the methods that establish the "user session" upon which all else depends. Or are you saying that the servlet hands requests to Session Beans, and then the SBs are changing the principal via RoleManager.login()? So I'm sorry if I gave the wrong impression. Based on user input, the servlet is telling the EJB (and dependents) when usermanager things need to be done; the servlet is not actually doing that itself. Again, are you using your own permission management, or are you using the EJB permissions? Or are you just talking about user "management" (add, remove, etc.)? I am trying to establish user method permissions, not managing users, and I can not get that to work at all. Incidentally, the JNDI lookup that works just fine here is precisely: roleManager = (RoleManager)new nitialContext().lookup( "java:comp/RoleManager" ); Ah! I will try that. Thanks. I might add that we are using the EJBUserManager, and we have found that the programmatic control of groups doesn't work properly, so we hacked a workaround (concern when updating or adding users). Otherwise everything described above is cool. Well, this now suggests to me that you are using EJB permissions. Are you calling RoleManager.login() to change the principal from what the servlet had established via jndi.properties? Assuming you figure out the jndi.properties thing, then you ought to be able to obtain the principal name and the credentials (password) from the environment, and pass that info into a session bean that can actually do the usermanager and role manager stuff. IMO. This is very confusing to me. If I have N users hitting 1 servlet, and that servlet is establishing the principal from jndi.properties, how in the world do I establish the user for EJB permissions? When that servlet
RE: -- Arved -- Can you please help me with servlet authentication?
You'll understand that we are using 100% programmatic user management. Also, I think (in your last few paras) that you are close to answering your own question. If you've got multiple users and you cannot rely on a jndi.properties, then by exclusion you must rely on the users to supply their identity. We use a form to gather the username and password when we need them; client certs would also work. Arved, Thanks for your help so far. I am down to one last problem. We are using Orion 1.4.0, and there appears to be some sort of bug in the InitialContext. I am setting up the environment in my servlet: Properties env = new Properties(); env.put( "java.naming.factory.initial", "com.evermind.server.ApplicationInitialContextFactory" ); env.put( "java.naming.provider.url", "ormi://localhost/appname" ); env.put( "java.naming.security.principal", "appuser" ); env.put( "java.naming.security.credentials", "password" ); InitialContext iCtx = new InitialContext( env ); No matter how I set up env, it does not work with respect to identity. When I print out the InitialContext, it has all of my ejb-ref's bound to it. HOWEVER, it does not have any "environment" established at all (IOW, iCtx.getEnvironment() gives back an empty Hashtable). And when I access my SB's, I am considered a 'guest' user. If I take permissions off the SB's, I am able to access and use them. As soon as I put the permissions back, I am rejected. It is ignoring my principal and credentials completely! Do you establish any identity via the InitialContext in your servlet? Is this a know bug? I can not find it anywhere in BugZilla, which has a very poor searching interface. tim.
RE: -- Arved -- Can you please help me with servlet authentication?
Although we have a single servlet front-end, and do programmatic usermanagement (including login), the actual user manager and role manager stuff all happens down in EJB-land (in a session bean being referenced from the servlet). So we do not use JNDI properties at all for authentication, except for some secondary application clients. Incidentally, the location of jndi.properties, and how it works, is dictated by Java (I think starting with JDK 1.2, but it could have been 1.3). If there exists a jndi.properties in your classpath, it will get read. So this behaviour is entirely independent of J2EE. So I'm sorry if I gave the wrong impression. Based on user input, the servlet is telling the EJB (and dependents) when usermanager things need to be done; the servlet is not actually doing that itself. Incidentally, the JNDI lookup that works just fine here is precisely: roleManager = (RoleManager)new nitialContext().lookup( "java:comp/RoleManager" ); I might add that we are using the EJBUserManager, and we have found that the programmatic control of groups doesn't work properly, so we hacked a workaround (concern when updating or adding users). Otherwise everything described above is cool. Assuming you figure out the jndi.properties thing, then you ought to be able to obtain the principal name and the credentials (password) from the environment, and pass that info into a session bean that can actually do the usermanager and role manager stuff. IMO. Hope this helps. Arved -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres Sent: Tuesday, November 21, 2000 3:45 PM To: Orion-Interest Subject: -- Arved -- Can you please help me with servlet authentication? Arved, Please excuse me for calling you out on this one, but you are the only one on the mailing list who claims to have succeeded in doing what I want. The documentation (surprise) is meaningless, and the mailing list archive is failing me. I have a servlet in a web-app that is deployed alongside my ejb application under Orion. Orion is the app server, web server, and servlet engine. Simple. I want to handle user authentication within my servlet, so I do not want any sort of "FORM based login page" or any other mechanism. I would like for the InitialContex that my servlet uses to establish the principal that is accessing my Session Beans, and then I perform finer access control within those as an extension to the EJB permissions. In certain instances, I would like to use RoleManager.login() to change the EJB user that is in force. First, I can not get Orion to read jndi.properties from anywhere. So, I am explicitly loading them myself. I now explicitly put them into the System properties and the values are: System.setProperty ( "java.naming.factory.initial", "com.evermind.server.ApplicationInitialContextFactory" ); System.setProperty ( "java.naming.provider.url", "ormi://localhost/appname" ); System.setProperty ( "java.naming.security.principal", "appuser" ); System.setProperty ( "java.naming.security.credentials", "password" ); I have defined 'appuser' in principals.xml, and I have put it in the 'administrators' group. I have added a custom UserManager to echo out what is going on just to give me some idea on what is happening, and all I see is a call to serManager.getGroup( "appuser" ). No matter what I have tried, I have these problems: 1) I am always considered a "guest". It appears that Orion ignores my principal setting in the jndi properties. I get no error messages anywhere about it. Yet, when a Java application uses the same settings in jndi.properties, it works. Even if I change the principal from 'appuser' to 'random', the calls to the UserManager still reference 'appuser', which is very confusing. 2) I can not get servlets to load any jndi.properties from anywhere on the CLASSPATH (WEB-INF/classes does not work, nor does WEB-INF). I have listed the ClassLoader tree, and WEB-INF/classes is the path for the servlet loader. 3) I can not get a RoleManager reference to save my life. No matter what I do in my code (using initCtx.lookup( "java:comp/env/RoleManager" ) ad nauseum) I get a NamingException saying RoleManager is not found. Yet, everyone talks about using it just that way! And lookups on my other names works. Do I need an ejb-ref for RoleManager? 4) I can not find any logging of any errors related to authentication... PLEASE, could you share in detail the steps you took to get your servlets to be able to login a user by direct login (RoleManager.login()), and how you got your jndi properties to be accepted so that you could specify your user credentials. I am just frustrated now. TIA, tim.
Re: -- Arved -- Can you please help me with servlet authentication?
Incidentally, the location of jndi.properties, and how it works, is dictated by Java (I think starting with JDK 1.2, but it could have been 1.3). If there exists a jndi.properties in your classpath, it will get read. So this behaviour is entirely independent of J2EE. this might also have to do with classloader problems that sometimes occur when properties (and other resources) are loaded from within jar files. I have seen cases where I could load the classes, but the classes werent able to load their properties (JavaMail provider is an example). The only way to resolve this was to either put the jar in the invocation classpath (java -cp all jars orion-startup-class), to modify orion.jar's manifest, or to copy files into JRE/lib/ext
RE: -- Arved -- Can you please help me with servlet authentication?
Hi Arved, Although we have a single servlet front-end, and do programmatic usermanagement (including login), the actual user manager and role manager stuff all happens down in EJB-land (in a session bean being referenced from the servlet). So we do not use JNDI properties at all for authentication, except for some secondary application clients. Are you saying that you simply ignore EJB-based permissions, and manage all of the access internally in your session beans? This is the approach that I want to take, but I want to be sure that only my servlets can actually get to the methods that establish the "user session" upon which all else depends. Or are you saying that the servlet hands requests to Session Beans, and then the SBs are changing the principal via RoleManager.login()? So I'm sorry if I gave the wrong impression. Based on user input, the servlet is telling the EJB (and dependents) when usermanager things need to be done; the servlet is not actually doing that itself. Again, are you using your own permission management, or are you using the EJB permissions? Or are you just talking about user "management" (add, remove, etc.)? I am trying to establish user method permissions, not managing users, and I can not get that to work at all. Incidentally, the JNDI lookup that works just fine here is precisely: roleManager = (RoleManager)new nitialContext().lookup( "java:comp/RoleManager" ); Ah! I will try that. Thanks. I might add that we are using the EJBUserManager, and we have found that the programmatic control of groups doesn't work properly, so we hacked a workaround (concern when updating or adding users). Otherwise everything described above is cool. Well, this now suggests to me that you are using EJB permissions. Are you calling RoleManager.login() to change the principal from what the servlet had established via jndi.properties? Assuming you figure out the jndi.properties thing, then you ought to be able to obtain the principal name and the credentials (password) from the environment, and pass that info into a session bean that can actually do the usermanager and role manager stuff. IMO. This is very confusing to me. If I have N users hitting 1 servlet, and that servlet is establishing the principal from jndi.properties, how in the world do I establish the user for EJB permissions? When that servlet accesses a session bean, the SB will see the user from jndi.properties, not the user that is driving the servlet. How do you work with that? RoleManager.login()? In my opinion, this is one of the most critical and least understood aspects of Orion, and the most poorly documented. I get the impression that no one is doing any serious user management. Or they are not sharing how... I would like to cut a check for Orion, but I need to confirm that it will support our needs, and permissions and performance are the last things I need to verify. Thanks again, tim.
