I see. The servlet would be a bit of security validation server set up as an app itself. It's job would be to receive validation requests from various apps. When validation is returned true (to the calling app) then the calling app would login the user to its local container managed security. This would allow for several apps on seperate containers to have a single sign on of sorts. This has some problems with it though. It has to be able to tie into the local security. If a username and a role id is returned there is no way to get that into the container managed security.
When I think of it, though. There may be another way to accomplish this. I am assuming we are using a database or ldap server. I haven't looked into it, but, you should be able to set up a realm in Tomcat. This realm would use a remote database or ldap server to validate against. Within this server you can map users to roles. I believe that most containers should be able to do this. Therefore the validation remains at the app level. But the database or ldap can be located on another server and used by any app as long as it is specified as the realm (or whatever other containers call it). The trick is creating a pseudo single sign-on for various apps on differing containers or servers. I have some ideas on how this could be accomplished. But, we can discuss that later. P.S. I should be getting the code into the cvs at sourceforge today or tommorrow. Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -----Original Message----- From: Struts-dev Newsgroup [mailto:@[EMAIL PROTECTED]] Sent: Tuesday, April 16, 2002 11:55 AM To: [EMAIL PROTECTED] Subject: Re: struts security Subject: Re: struts security From: Vic Cekvenich <[EMAIL PROTECTED]> === I was thinking... a centralized servlet, that any app would call. It would be sent user id and password, and it would reuurn user Name and RoleID. Let's e-mail offline next week. Vic Phase Web and Multimedia wrote: > That could be accomplished but it would have to use a u/p stored in a cookie > on the browser to accomplish. In other words. In the same container you can > set up single sign on. If it is visiting another container there is no way I > know to have a logged in state for another container. That would be a > security risk. But, if the u/p was stored in a cookie then it could be > retrieved by the app and sent to verify against the container. This still > seems like a security risk. > > Perhaps there is a safer way. Do you have any suggestions? > > Brandon Goodin > Phase Web and Multimedia > P (406) 862-2245 > F (406) 862-0354 > [EMAIL PROTECTED] > http://www.phase.ws > > > -----Original Message----- > From: Struts-dev Newsgroup > [mailto:@[EMAIL PROTECTED]] > Sent: Tuesday, April 16, 2002 5:10 AM > To: [EMAIL PROTECTED] > Subject: Re: struts security > > > Subject: Re: struts security > From: Vic Cekvenich <[EMAIL PROTECTED]> > === > What about single login? (to multiple applications on different containers?) > Ex: a central servlet that gets called by a struts app to autethicate a > user and then stores this? > If you add this, I will try it. (else I have to write my own). > Vic > > Phase Web and Multimedia wrote: > > >>Greetings, >> >>I am nearing the completion of the code and it should be on sourceforge in >>the next day or two. I will be following it up with documentation and >>examples over the next week. >> >>FYI - I am finishing up an overhaul on the code so that it fits into the >>container managed security and yet provides the neccessary flexibility >> > that > >>many of us need (i.e multiple login pages, prelogin capabilities, and >>maintained logins). >> >>I have accomplished this by creating a plugin of sorts. This plugin uses >> > two > >>mechanisms a Filter Class and a Servlet Class. I have named the Servlet >>Class "Security Controller Servlet" because it handles the validation >>against the conatiner managed security by receiving the form calls and >>preparing the container to validate. The filter works to identify >> > protected > >>urls which are specified in the security.xml file. >> >>Set up should be pretty easy: >> >>Within your web.xml you set up a "bogus" security-constraint that uses the >>"Security Controller Servlet" as it's error page and login page. Also, the >>"SCS"(Security Controller Servlet) is set as the 403 error page (forbidden >>error). >> >>You also set up the SecurityInit class to initialize upon app start in the >>web.xml. >> >>Also set up is a security.xml file that defines various Security >> > Constraints > >>that map to different login pages. So that if someone request >>www.mydomain.com/shopping/ it takes them to the shopping login page versus >>if someone request www.mydomain.com/admin/ it would take them to the admin >>login page. Another convienience is that you can login from any page you >>want to. You don't have to hit a secure url first. You can have a >> > login/pass > >>on your homepage or even an auto login that uses cookies. >> >>When you start your app up the security.xml file is read into an >> > Application > >>scope bean that provides the info for the URL Filter class to screen >>protected URLS. >> >>The nice thing about this is that all of the programmatic methods are >>available to do container based role checking. >> >>This is good because many api's like "tiles" and "struts menu" are looking >>to take advantage of these methods more and more. >> >>I have not tested this code on other containers. It uses RequestDispatcher >>and response.sendRedirect() classes and methods inconcert with a Filter. >> > So, > >>behavior may be different on various containers. I am testing it now on >>Tomcat 4.0.3. A Servlet 2.3 container is neccessary. Other dependencies >> > are > >>commons-digester from Jakarta. >> >>This security is not struts specific. But, is developed to fit into a >> > struts > >>app. >> >>Anyhow, I'm working hard to get this up and I hope it suits many peoples >>needs. I am sure there are many other features that we could add to it. I >>have been working in a vaccuum on this so when it is realeased things may >>need to change. I look forward to hearing back from you. >> >>Thanks, >>Brandon Goodin >>Phase Web and Multimedia >>P (406) 862-2245 >>F (406) 862-0354 >>[EMAIL PROTECTED] >>http://www.phase.ws >> >> >>-----Original Message----- >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >>Sent: Monday, April 15, 2002 4:49 PM >>To: [EMAIL PROTECTED] >>Subject: struts security >> >> >>Good evening Brandon, >> >>I read of your work on the archives and I would like to check out your >>solution. I've been looking for a clear cut security solution but have >> > not > >>found one yet. Please >>let me know when I can get a hold of your code and any examples you may >>have. >> >>Thanks much. >> >> >> >> >>-- >>To unsubscribe, e-mail: >> > <mailto:[EMAIL PROTECTED]> > >>For additional commands, e-mail: >> > <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
