Hi Peter, On 4 August 2011 03:43, Peter Firmstone <[email protected]> wrote: > Dan, you're wise and I respect your view. >
Thank you equally be careful how much wiseness you attribute to me and thus how much respect you give me - nobody is perfect! :) > Security matters to me because I plan to deploy over insecure networks. > Yep, that's visible in your areas of focus in respect of River and given it's nasty stuff to play with I appreciate your focus. > Luckily security is mostly complete, Bob Scheifler's team achieved what they > set out to do, a very difficult task I might add. But this takes skill on > the application developers part to understand and utilise. > Agreed. > For an application developer, determining policy files and permissions is > often one of the big hurdles. > Agreed. > I get where you're coming from, deployment needs to be simpler and > installation / configuration needs to be automagic. > Quite - a routine problem is the selection of an interface that does multicast. > To make it possible to add in security later, requires the application > developer to follow certain rules and method calls. These are typically > very similar among different services. > Absolutely. > I'm wondering if it's possible to use annotations to hide these methods from > the application developer on the client side, so they can learn to develop > without worrying about security, perhaps using only reflective proxy's to > start with, then activate security later and start using smart proxy's when > ready? > Can I check I understand that annotations thing? I think you're saying that we'd use annotations on their code to identify methods we'd need to invoke for them or provide stub implementations for? Seems reasonable if that's the case. I would say reflective proxy's are the easy starting point, although if we're doing the annotations thing, maybe we can make it work reasonably for smart proxies too. In fact, maybe annotations are a way to make things nicer for all regardless of level of expertise. I think we'd have to allow things to work without annotations (lots of code out there already written) but.... > Typically we're talking proxy verification, dynamic permission grant's, > running as Subjects, using key stores and using method constraints. > Uh huh - I think the toughest of those for newbies are dynamic permission grants and proxy verification (at least in the smart proxy case), possibly Subjects too. > Cheers, > > Peter. > Two cents, Dan. > > Dan Creswell wrote: >> >> I recall Waldo saying some time ago that systems get harder and harder >> to do as you in order from: >> >> (1) Single-thread single machine. >> (2) Multi-thread single machine. >> (3) Multi-machine. >> (4) Multi-machine with security. >> >> On that basis, I'm tempted to say we should make our lives easier by >> setting something that limits the amount of heavy-lifting we need >> before we have anything to show for it/play with. Thus, I'd say we do, >> in order: >> >> (1) We should look at easing the admin burden - in terms of scooping >> up exceptions, logging, monitoring and such. >> (2) Sort out a bare bones out of the box experience - minimal configs, >> intelligent auto-setup for network interface selection. >> (3) Security for all the above. >> >> Now, I know and it's right to say on some levels, baking in security >> from the start often is what needs to be done but Jini itself managed >> without security early on and we probably ought to plan to "throw one >> away" (as per Mythical Man Month) as we figure these things out so I >> personally believe security can wait. >> >> +1 for doing as much through JMX as possible by default if that's >> practical (fear with multiple JVMs on one box a la simulating >> distributed services it might get tough). >> > >
