Return-Path: 
 <avalon-dev-return-11761-qmlist-jakarta-archive-avalon-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org
Received: (qmail 62957 invoked from network); 29 Jun 2002 05:02:12 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by 209.66.108.5 with SMTP; 29 Jun 2002 05:02:12 -0000
Received: (qmail 7219 invoked by uid 97); 29 Jun 2002 05:02:29 -0000
Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org
Received: (qmail 7181 invoked by uid 97); 29 Jun 2002 05:02:28 -0000
Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:avalon-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:avalon-dev-help@jakarta.apache.org>
List-Post: <mailto:avalon-dev@jakarta.apache.org>
List-Id: "Avalon Developers List" <avalon-dev.jakarta.apache.org>
Reply-To: "Avalon Developers List" <avalon-dev@jakarta.apache.org>
Delivered-To: mailing list avalon-dev@jakarta.apache.org
Received: (qmail 7153 invoked by uid 98); 29 Jun 2002 05:02:27 -0000
X-Antivirus: nagoya (v4198 created Apr 24 2002)
Subject: RE: current state of security
From: Richard Wallace <rwallace@a--i--m.com>
To: "'Avalon Developers List'" <avalon-dev@jakarta.apache.org>
In-Reply-To: <001f01c21ea6$d84a2f20$ac00a8c0@Gabriel>
References: <001f01c21ea6$d84a2f20$ac00a8c0@Gabriel>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
X-Mailer: Ximian Evolution 1.0.5 
Date: 28 Jun 2002 22:02:15 -0700
Message-Id: <1025326936.13347.3.camel@rich>
Mime-Version: 1.0
X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N
X-Spam-Rating: 209.66.108.5 1.6.2 0/1000/N

If your interested in security components for avalon/phoenix check out
the project Larry McCay and I are have started at sourceforge (it's
there until we have something more substantial to put in cornerstone). 
The project is aaa4avalon and we're trying to create a good component
oriented architecture for Authentication, Authentication and Auditing. 
We're still in the very early stages (just getting done with the design
and initial implementation of some of the authen. components).  Take a
look and feel free to contribute if you want.

Rich

On Fri, 2002-06-28 at 06:22, Berin Loritsch wrote:
> > From: Adam Rossi [mailto:adam.rossi@platinumsolutions.com] 
> > 
> > Thanks for your response Steve. I have a few comments below.
> > 
> > <snip>
> > > 
> > > >What is Guardian?
> > > >
> > > 
> > > No idea.
> > 
> > Gaurdian was a class discussed in the "Developing with Apache 
> > Avalon" document. Here is a code snippet:
> > 
> >     public void compose(ComponentManager manager)
> >         throws ComponentException
> >     {
> >         if (this.manager == null)
> >         {
> >             this.manager = manager;
> >             myGuard = (Guardian) this.manager.lookup(Guardian.ROLE);
> >         }
> >     }
> > 
> >     /**
> >      * This is the method that uses the Guardian.
> >      */
> >     public void myMethod()
> >         throws SecurityException
> >     {
> >         this.myGuard.checkPermission(new BasicPermission("test"));
> 
> 
> >From the author of that guide:
> 
> Guardian, like all the components in that guide are merely discussion
> points.  It shows how you *might* implement security in a component
> oriented way.  There has been no formal (or informal) research in this
> direction as of yet.
> 
> If there are any interested parties in sponsering that research, I would
> be the first to offer my services.  My contracting fee is fairly
> reasonable
> ($40 USD an hour).
> 
> I was only half joking about that.  I really want to do it, but the day
> job kind of gets in the way.
> 
> 
> > > >What is Fortress?
> > > >
> > > 
> > > Nothing to do with security.
> > > Its basically a manager of components - (a container in Avalon 
> > > terminology).
> > 
> > I suspected that, but I could not check it out due to the web 
> > site reorganization. Is there a direct URL to a place where I 
> > can learn more about Fortress?
> 
> 
> We need to fix that.
> 
> BTW, did you know that we have a user's list?  It is more focused
> towards
> questions of this nature.  If you are interested, the list is:
> 
> avalon-users@jakarta.apache.org
> 
> You can subscribe by the following email address:
> 
> avalon-users-subscribe@jakarta.apache.org
> 
> 
> > > There is a lot of discussion going on at the mment concerning
> > > meta-models for components.  Today - our sucurity policy 
> > approach is 
> > > "application" centic - and I think it could be interesting 
> > to explore a 
> > > more component centric model for security policy 
> > declaration at the meta 
> > > level.
> > 
> > That would be very good. I would like to be able to assign 
> > security permissions to components through a central security 
> > manager, instead of having to code security calls directly 
> > into the component. Then, a container could be configured to 
> > enforce security on all components in a consistent fashion.
> 
> :)
> 
> That is the goal.  This would work with a combination of Meta Data,
> JAAS (with the improved classloader security support), and a number
> of cues from J2EE security models.
> 
> That is more the model I would prefer to design.
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>