JSecurity

Ok, I posted a new front-page 'story' with a diagram of the new 0.2 architecture. Lemme know if you have feedback.

Also, Jeremy, I'm going to work on the PropertyFilesRealm to get that to work asap. My idea is that I'd like to use that as the default realm implementation when the library is released.

Meaning, I want JSecurity to be so rediculously easy, that all a new user has to do to get a fully operational environment working is this:

SecurityManager securityManager = new DefaultSecurityManager();

That's it.

(or in a web environment, just define a single Filter that does the above for them).

Then they can adjust configuration as necessary. But on initial usage, they can at least start playing with it immediately. This has real appeal I think when reading about peoples' experiences w/ understanding and setting up Acegi configuration.

The only thing that prevents this from happening today is that the DefaultSecurityManager must have at least one realm injected into it.

If I default upon startup to using a PropertiesFileRealm using failsafe .properties files in jsecurity.jar, then there would be a fully functional (albeit not recommended for deployment) environment working out of the box. I've had people at work say this would be ideal, because it allows them to delve into configuration at their own pace - at least it would work immediately out of the box without any additional work.

So, to get that to work, I'll be playing w/ PropertiesFilesRealm today - please don't adjust that implementation until I get it checked in so we don't have to worry about merge conflicts. ;)

- Les