Return-Path: Delivered-To: apmail-jakarta-struts-user-archive@apache.org Received: (qmail 14175 invoked from network); 2 Apr 2002 22:00:25 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 Apr 2002 22:00:25 -0000 Received: (qmail 27582 invoked by uid 97); 2 Apr 2002 22:00:04 -0000 Delivered-To: qmlist-jakarta-archive-struts-user@jakarta.apache.org Received: (qmail 27559 invoked by uid 97); 2 Apr 2002 22:00:03 -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 27542 invoked from network); 2 Apr 2002 22:00:03 -0000 Date: Tue, 2 Apr 2002 13:59:55 -0800 (PST) From: "Craig R. McClanahan" To: Struts Developers List cc: Struts User , Subject: RE: Security Solution In-Reply-To: Message-ID: <20020402134857.G53443-100000@icarus.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: localhost 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N See intermixed comments below. On Tue, 2 Apr 2002, Phase Web and Multimedia wrote: > Date: Tue, 2 Apr 2002 13:23:35 -0700 > From: Phase Web and Multimedia > Reply-To: Struts Developers List > To: Struts Dev , > Struts User , michaelm@consultech.net.au > Subject: RE: Security Solution > > Greetings Michael, > > I don't believe it has to be struts specific. But, I have never used it > anywhere but struts. There many other features I would like to add to it. > Specifically an ldap realm for authorization and perhaps add some hooks that > will provide EJB conectivity. Do to my EJB ignorance I don't even know if it > is possible. > Such an approach to application-managed security (but with a pluggable implementation of the user database) would probably be pretty popular. In fact, what you are describing is pretty similar to how Tomcat itself implements container managed security (you might want to snoop the Tomcat 4 sources for ideas). However, there are some restrictions -- most of which you've already identified -- in the scope of this effort. > One thing to note. Because a webapp has limited access to the server scope > this security solution is context specific for now. This is why I want to > add some of the afformentioned hooks. I also imagine it would be possible to > store the security xml file so that it can be cross context and provide a > single security config for multiple contexts under a host. > It seems unlikely to me that a server-wide (or virtual-host-wide) implementation of application managed security can be created that is portable across servlet containers. You pretty much have to hook in to container-specific facilities to pull it off. That being said, solving the problem for a particular webapp is still a very useful scenario. > Another thing to note is that many of the apis that are out there (ie tiles, > jsp, servlet) take advantage of the container managed security by checking > roles. These are all container specific. I've chosen to abandon all of those > niceties to gain greater flexibility in other areas. I have sacrificed the > standard convention that these mechanisms provide. I feel it is a good > decision for my niche. > > I will be providing mechanisms equal to the isUserInRole(), getRemoteUser(), > and getUserPrincipal(). But these objects will be context-session specific. > Faking the values returned by these methods is pretty easy in a Servlet 2.3 environment, where you can create a request wrapper. That would be sufficient for dealing with what Struts-ish things like tiles needs. > My solution should be able to work as an app level link to a larger security > system that bypasses tomcat security all-together. > > I have heard some speak about ejb as thought they need the container-managed > security. This might be so. I don't know. I am hoping that someone might be > able to provide that functionality. > The EJB layer *absolutely* requires container managed security. In the absence of using container managed security at the web layer, you'd need to figure out some other mechanism for converting your own notion of user identity into a user and role set that is recognized by the EJB tier. A couple of options include: * The web container runs completely separate from the EJB container, and appears to be a standard J2EE application client. (This probably means you lose pretty badly on performance, however). * In Servlet 2.3 there is the notion of the "run-as" identity assigned to all web tier code that has not been authenticated via container-managed security. If your application design will let you share a single EJB-user identity, you can probably get away with this approach. > If you would like to look at my code I am more than happy to pass it on. > But, it is narrow in scope to my application. This has become apparent to me > as I read some email regarding what I have developed. I believe the code and > concept to be a good starting point to provide a better security framework. > > The strongest part of the code it the SecurityFilter and MulitpleLogin > configuration options. > > Let me know, > Brandon Goodin > Phase Web and Multimedia > P (406) 862-2245 > F (406) 862-0354 > mail@phase.ws > http://www.phase.ws > Craig McClanahan -- To unsubscribe, e-mail: For additional commands, e-mail: