The ldap portion is under development. It will be a bit. My code is a struts centric security at this point. I am experimenting with extending it to support ldap. I can still show you the code for the security if you would like.
Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 [EMAIL PROTECTED] http://www.phase.ws -----Original Message----- From: Dr. BaTien Duong [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 11, 2001 5:53 PM To: Struts Developers List Subject: Re: role based actions Brandon: I am interested in your code as we are working on Struts, ldap, and Java single SignOn technology. [EMAIL PROTECTED] ----- Original Message ----- From: "Phase Communcations" <[EMAIL PROTECTED]> To: "Struts Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, December 11, 2001 4:43 PM Subject: RE: role based actions > One last thing. When a security check happens and the user is forwarded to > the login. Their desired destination is stored and once their security is > verified they are forwarded on to that page. > > -----Original Message----- > From: Phase Communcations [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, December 11, 2001 4:40 PM > To: Struts Developers List > Subject: RE: role based actions > > > In my code I extended the action class (not the action servlet) and required > that group access be established on a per extended action class basis. > > Defined within my struts-config file in my action class definitions I use an > extra attribute(s): > > <set-property property="group" value="agroup" /> > > There is a security check within the extended action class that uses an > extended ActionMapping to retrieve the "group" property and checks it > against the users information (in a database). If the user belongs to the > proper group or one of the groups defined then it allows them access to that > action/area with their assigned role and permissions. If the security check > fails, they are routed to a login page. > > The other thing that it does is it stores role and permission information in > a bean so that security information can be used to define the view as well. > > I opted out of the container managed security because I was working under > Tomcat 3.2.3 and am trying to create a more independent security model. This > model also works well for me because I use the command line url format for > mapping to my action classes and none of my views are available but through > action classes (except index.jsp). > > I would be happy to share my code if anyone is interested. I think it is > flexible enough that it could be incorporated into an ldap system. I have > been confeing with a colleague who is working on struts interacting with > ldap for security and profile management. > > Anyways if you like the idea of security being managed from the action class > and don't expose your views but through action mappings. This might be a > good solution > > Brandon Goodin > Phase Web and Multimedia > P (406) 862-2245 > F (406) 862-0354 > [EMAIL PROTECTED] > http://www.phase.ws > > > -----Original Message----- > From: craigmcc@localhost [mailto:craigmcc@localhost]On Behalf Of Craig > R. McClanahan > Sent: Tuesday, December 11, 2001 10:16 AM > To: Struts Developers List > Subject: Re: role based actions > > > > > On Tue, 11 Dec 2001 [EMAIL PROTECTED] wrote: > > > Date: Tue, 11 Dec 2001 10:27:52 -0500 > > From: [EMAIL PROTECTED] > > Reply-To: Struts Developers List <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: role based actions > > > > > > I am a struts "newbie" so I apologize in advance if this topic has already > > beaten to death... > > > > ~~~ > > > > I noticed role-based actions on the pending tasks list. > > Adding this (and a few of the other recent enhancements) to Struts 1.1 is > definitely on *my* list. I will have some time to do so between Christmas > and New Years. > > Craig McClanahan > > > > > Can anyone comment on the status and scope of this effort? (link was a > dead > > end) > > > > The description points to role being driven by security, seems the role > will > > be detected and then dispatches to the proper action? points to assoc'd > form > > through config? > > > > Is this intended to be used for personalization to the extent where a > person > > of one role gets a different view, can user customize their view? > > > > Does this provide a place holder for that kind of functionality v. any > > particular "built in" functionality? > > > > Thanks, sorry if the questions were a little obtuse. > > > > -Rick Vaillancourt > > > > > > -- > > 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]> > > -- 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]>
