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]>
