Hi Dan, I think your design of the security framework is first rate. What I am not sure about, and as I said before it probably related to my lack of clear understanding of JAAS, is that your framework (can) effectively "wrap" JAAS. If Sun is pushing JAAS as their "security" architecture, wouldn't it be better for your framework to effectively _BE_ the JAAS implementation. That way Turbine could be seen to be JAAS compatible (always nice to promote standards), and your framework is the actual guts of it.
Put in another way, the J2EE spec is the framework that all developers code against, and JBoss is a specific implementation of that framework that you use, then JAAS is the framework, and your code is the bits that are actually used. Hope I make sense, but probably am I off the mark. I am keen to discuss this whole concept further and explore because Turbine could really benefit from a nicely separated security architecture. cheers, Paul Smith > -----Original Message----- > From: Dan Diephouse [mailto:[EMAIL PROTECTED]] > Sent: Friday, 10 January 2003 5:21 PM > To: [EMAIL PROTECTED] > Subject: Re: New Security Service [was RE: TurbineUser - Extending it? > May be you should not have to.] > > > What is your judgement on my framework? I tried to design it > so anyone > can use whatever method they want. Hopefully it is application > agnostic. I would like to have that any application might be able to > use, not just Turbine. > > Think about this. If you wanted to use my framework and JAAS with > turbine, we might want to authenticate against a "web page" resource > type. You would first want to register your implementation of the > ResourceAccessController class with the ResourceManager, like so > > DefaultResourceManager myResourceManager = new > DefaultResourceManager(); > myResourceManager.register("webpagetype", > myJAASResourceAccessController); > > where myJAASResourceAccessController is a class you would > design (well, > actually, we would have several default implementations of > this class - > I already designed a basic XML one. Please see my docs). In your > applications code, which would be a valve in the > TurbinePipline for T3, > you woudl find this "Resource"'s ResourceAccessController this way: > > ResourceAccessController controller = > myResourceManager.lookup("webpagetype"); > > this controller with be an implementation that you registered earlier > with the DefaultResourceManager. You can than test for a specific > credential like so: > > controller.hasCredential( userEntity, new > BasicCredential("read"), new > WebPageResource("/store/buy.html"); > > In fact, we can even develop custom resource types, for if we > wanted to > not only base resources on the webpage name, but on the current > "project" or "group" of the user (most people - like the original > turbine code, made the mistake of thinking that groups are a > credential > when they are really a *resource*). We would do this like so: > > ResourceAccessController projectcontroller = > myResourceManager.lookup("projectwebpagetype"); > controller.hasCredential( userEntity, new > BasicCredential("read"), new > ProjectPageResource("/store/buy.html", "Project1034"); > > Do you see how this all works now? I went into more depth in this > message so everyone can get a feel for it. Please see the docs too! > Remember, those ResourceAccessControllers can be either an > implementation that comes boxed - such as a database > implementation, or > your own custom implementation, like a JAAS one. > > Cheers, > > - Dan Diephouse > > > Paul Smith wrote: > > Hi All, > > > > What ever the security mechanism is that is chosen, I think > it should be a > > number #1 priority to fit into Sun's JAAS model (it's in > JDK 1.4 now so we > > can't hide from it). NOw I am no expert on JAAS, but IMHO > that will enable > > people to integrate a bit easier into other Java related > technologies (i.e. > > J2EE). It still amazes me that everyone keeps having to > roll their own > > security layers into their apps (not just in Turbine, and > hey, I've just > > done this myself in the last 12 months). The more > integration with already > > proven technologies the best chance of success, and shorter > time to release > > (possibly a bold statement). > > > > cheers, > > > > Paul Smith > > > > > >>-----Original Message----- > >>From: Colin Chalmers [mailto:[EMAIL PROTECTED]] > >>Sent: Wednesday, 8 January 2003 5:00 AM > >>To: Turbine Developers List > >>Subject: Re: New Security Service [was RE: TurbineUser - > Extending it? > >>Maybe you should not have to.] > >> > >> > >>Would it be able to plug into other systems? ie Tomcat's > >>Realm or Suns JAAS? > >> > >>The discussion surrounding security was quite lively about a > >>year ago (was > >>it really a year ago?) with some good suggestions on > >>improving the current > >>service. > >> > >>Should we perhaps re-waken this discussion and see if we get > >>any further? > >> > >>/c > >> > >> > >> > >>>>Speaking of this topic, I had an idea one night about > >> > >>security. After a > >> > >>>>couple hours I came up with this: > >>>> > >>>>http://dan.envoisolutions.com/jasf/ > >>>> > >>>>It seems to be pretty flexible, but I'm not sure everyone > >> > >>would like > >> > >>>>using it. I wanted something where I could authenticate not only > >>>>webpages, but other resources - such as access to various > >> > >>components in > >> > >>>>my system. I even wrote a XML user and permission based > >> > >>system for it. > >> > >>>>Thoughts? > >>> > >>>I like it. How do you specify the controllers you want to use? I'm > >>>thinking from the point of view of a Turbine security service, you > >>>would probably want to configure that from the properties file. > >>> > >>>In fact, I think it works pretty much like the thing I > came up with. > >>>Good work! ;-) > >>> > >>> > >>>>- Dan Diephouse > >>> > >>>Regards, > >>> > >>> > >>>-- > >>>Gonzalo A. Diethelm > >>>[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]>
