On Mon, Jan 25, 2010 at 9:50 AM, Emond Papegaaij <emond.papega...@topicus.nl> wrote: > I think a good security framework needs to provide an API that allows, but not > require, fine-grained control. >
Exactly! That's what I'm looking for. For the folks who want to get down-and-dirty and really tighten the screws on their authorization, they can do that. But, for me and my somewhat limited authorization concerns, I'd like to use something simple. > Most of the complicated stuff is from SWARM, which indeed requires a lot of > configuration. The difference between WASP and SWARM is not quite clear from > the documentation, nor is the separation of the two. Some of the naming could > use some improvement indeed :). The HiveMind manages the Hives used in the VM. > A Hive contains all principals and permissions of an application and > ultimately determines if a permission is granted or not. However, the Hive > (and mind) are part of SWARM and should not be part of a general API. > > The main elements of WASP are: > - A set of secure components > - Several security checks > - The ActionFactory, with a set of default actions > - The WaspAuthorizationStrategy, which implements IAuthorizationStrategy > > With this, WASP only provides an interface to make you Wicket application > secure. It has no implementation what-so-ever on how to check the security. > Therefore, I think it is a good starting point for creating a general security > API for Wicket. > So, what does WASP add to wicket-auth-roles that it doesn't have already? Is it generic enough that we should just put it into wicket-auth-roles (or a new wicket-security module)? I really don't like the name WASP. I think wicket-security is intuitive enough (and follows the other names already out there wicket-ioc, wicket-spring, etc.). I really don't like the fact that when folks ask questions about wicket-auth-roles, the usual answer is "wicket-auth-roles is only a demonstration" or something to that effect. There really should be a sanctioned/preferred (and pluggable) security framework for Wicket that we can all get behind. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
