Return-Path: Delivered-To: apmail-jakarta-struts-user-archive@apache.org Received: (qmail 68347 invoked from network); 1 Apr 2002 21:02:35 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 1 Apr 2002 21:02:35 -0000 Received: (qmail 11927 invoked by uid 97); 1 Apr 2002 21:02:21 -0000 Delivered-To: qmlist-jakarta-archive-struts-user@jakarta.apache.org Received: (qmail 11900 invoked by uid 97); 1 Apr 2002 21:02:21 -0000 Mailing-List: contact struts-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Struts Users Mailing List" Reply-To: "Struts Users Mailing List" Delivered-To: mailing list struts-user@jakarta.apache.org Received: (qmail 11888 invoked from network); 1 Apr 2002 21:02:20 -0000 From: "Phase Web and Multimedia" To: "Struts Users Mailing List" , Subject: RE: Security Solution Date: Mon, 1 Apr 2002 14:03:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3CA8C394.7040204@interlink.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Importance: Normal X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N In reponse: 1) The use of this security solution is confined (at this point) to a context in a host. Most of the time there is only one context per host. 2) It is a non-standard way of providing security checks. Many of the built in role checking that is in struts/tiles and the programmatic security checking would not be available. Although syntactically it would function the same it would have no ties to the container managed security. 3) A servlet 2.3 compliant container with struts is necessary. It uses a filter as the url guardian. I am sure the filter could be extracted and tweaked to work in other situations other than struts. 4) There are a few options. There is container based security or you can roll your own. Security has been (imho) a severly neglected area. As a designer/developer I find it to be a pain in the butt that one is limited to a single login page for all security constraints. This is the imposed standard. Much of the way security is set up flys in the face of easy end user interaction. Container managed security lacks the ability to login or remain logged in. This is fairly absured imho. Others have developed front end checks that work in conjunction with container managed security which perform slight of hand logins. For example. if you want to use container managed security you could initially redirect to a secure url that forwards to an struts action or a servlet which first checks to see if a cookie exists, then gathers u/p from the cookie and logs in and forwards to the homepage. If a login is not found you can wait until someone hits a secure url and forward them to the action login page. This smells like hackage. 5) If you want a list of competitive features read the other emails I have posted to the list and read the servlet 2.3 spec. I am trying to get some people thinking about intuitive security. I don't claim to have the answer in my group of classes. I just claim to have a bit more flexibility. I don't have any EJB or cross context fuctionality. Which other features do and of course is of high value to many. So, I believe you can get a good idea for what I have done by reading other posts with the same title as this article. Let me know what you learn. If you have any contributions suggestions. I would appreciate it. I don't claim to know anything much less everything :-) Hope this helps, Brandon Goodin Phase Web and Multimedia P (406) 862-2245 F (406) 862-0354 mail@phase.ws http://www.phase.ws -----Original Message----- From: Neil Pitman [mailto:npitman@interlink.net] Sent: Monday, April 01, 2002 1:31 PM To: Struts Users Mailing List Cc: Struts Developers List Subject: Re: Security Solution Hello Brandon, This might be interesting to me, but then I'm a newbie so I'm not sure whether I should be interested. As an alternative to posting sources here, you could create a project on SourceForge.net. It would relieve this list of the specific traffic. One aspect of documentation that I find particularly lacking is an "appropriateness" section. I expect it to be missing in commercial documentation (because no one wants to lose a sale). I have been searching open source for the last few months. I really have to dig into each project to understand whether it is appropriate. Could you provide: 1) indications for use 2) contra-indications against use 3) known complementary technologies (those it depends upon, those that depend on it, those with a synergistic relationship) 4) known competative technologies (ones where I have to choose the one feature set or another) 5) a comparative feature list (including versions of competitors). Ok, it sounds like I want a month of the marketing department. A line or two would suffice. Indeed, "unknown" would help - it would at least tell me that I'm on my own. Phase Web and Multimedia wrote: > Greetings, > > I wanted to offer some code if anyone is interested. I have seen many > discuss security on archives and wanted to offer an alternative to container > managed security. > > I spent some time weighing out whether to use container managed security or > not and came to the conclusion that I would use a filter for security. There > were several inflexibilities in the spec for container managed security. I > wrote a security filter that functions very similar to container managed > security. It has an xml config file that is used to protect urls. There are > a few differences in the config and how you define protected areas and where > you are directed. > > Basically there are three areas of greater flexibility. > > 1) you can define several security-constraint groups with different login > pages. > 2) you can login easily without having to hit a secure page first > 3) you can set up an app specific security realm. (This can also be > considered a limitation if you are maintaining cross context security, but > you could easily tie into a larger security system if this is needed) > > Anyways, it is not the "standard" but it functions well and gives greater > freedom. I found container managed security to be a greater "hack" job when > I wanted to accomplish my goals. If anybody is interested I can post it for > review. It is certainly not mature and the code is fit for my current > situation with an eye to greater flexibility. I think that it could provide > a good starting point for a cross-container simple alternate solution to the > current container managed security. > > P.S. I have to improve the documentation :-) > > Thanks for your time, > Brandon Goodin > Phase Web and Multimedia > P (406) 862-2245 > F (406) 862-0354 > mail@phase.ws > http://www.phase.ws > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > -- Neil Pitman npitman@interlink.net +1.514.863.5465 -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: