Dan, I too have different users and permissions for various applications in our intranet. If I understand you correctly, basically all your apps run in the same ServletContext as the framework application, and you define an application using its controller servlet. Is that correct? If so, then a user logged in to, say, the Mail app would be able to switch to a Calendar app without being required to log in again. Using one ServletContext would definitely solve the shared login problem and make central app administration possible. I would definitely like to study anything you can send me privately on your framework application (code, documentation). Thank you very much for your help! Larry Rogers Software Engineer MerCruiser USA Daniel Lopez <[EMAIL PROTECTED]> wrote : <snip> What I've done, basically, is a framework that allows a controller servlet to restrict access to applications depending on a definition that can be dynamically loaded from "anywhere". I did so because, unfortunately, in our architecture, every application usually has its own users and permissions so I thought that I wanted a flexible way to specify security. We are trying to migrate towards the "one-user-2 environment but due to the diferent nature of the multiple applications, we are not there, yet. However, for our internal applications it would be a great thing and we are almost there. So, mixing both things, following the controller servlet approach you could specify that this "anywhere" is your central security application and then configure a proxy, to get the appropriate settings, for every web application that is controlled by this framework. Regarding the implementation, we are not putting the security settings in the user session because that way we would be forcing httpsessions to be used and because then a central control of the security would then be more difficult, as there's no way of retrieving "all the sessions defined in a context" that I know of. So what we do is store the user permissions in the controller servlet and store just the credentials of the user (realm, user, password) in the session. Everytime he performs a request, his credentials are checked against the information stored in the security cache in the controller servlet and permission is granted or denied accordingly. This allows central control of the security information as it is stored in one place, and central control of user sessions, as his session state is stored also in the controller servlet (well, not exactly in there because I distributed tasks between different members of the servlet, but you get the idea ;)) . To allow our users to be able to have one login for several applications we use different approaches. If you can view your set of applications as a whole (they start up together, share the same users, share some global resources like EJB Beans...) we define a Domain for each of these applications and then define the appropriate permissions for each Domain(= what you called application) They all share the same WebContext and one login gets into all of them. This works pretty well and we have it actually working now in our first real life implementation of the framework. On the other hand, if the apps are different but you want to have them share the same web context, you define two applications running under the same controller, if you specified that they are under the same Realm, then they would share the security settings and one login would also work. Right now, we haven't implemented this option as so far it's been enough with the first one but it wouldn't be too difficult to implement. Lastly, if your applications are completely different and you don't want to share the web context, then you could define two servlet controllers(just a new alias with different settings) but then you wouldn't be able to share the login. As you would have the credentials of the user in the user session, you might be able to share the login but as the session state is stored in the controller servlet you might get in trouble when you have two controllers. I think it could be done if the sessions is shared between servlet contexts but it would need some extra control. Note: When I talk about two servlets-two contexts I'm talking about JSDK2.2. If you are interested in our implementation of the controller servlet, I might be able to give some information as we are about to make it Free Software. It has not been done yet because I still have to finish the packaging and the documentation and I'm quite busy right now. But if you want to have a look at the not-yet-finished documentation that we have, let me know. Regards and thanks for your feedback, Dan =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". FAQs on JSP can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html
