On Monday 25 January 2010 13:02:05 James Carman wrote: > On Mon, Jan 25, 2010 at 6:11 AM, Emond Papegaaij > > <emond.papega...@topicus.nl> wrote: > > I do think this is a good idea, however it will be difficult to > > implement. WASP/SWARM already provides this setup. WASP defines the > > interface, where SWARM is the implementation of that interface. I do not > > know about Shiro, but I don't think it is implemented on top of WASP. So > > should SWARM be build on top of the abstractions provided by Shiro (does > > it even have those abstractions?) or should Shiro be build on top of > > WASP? Either way will require a lot of work. > > Shiro shouldn't have to know anything about WASP. What should happen > is Wicket-Security (or whatever we're going to call it) would declare > a "SPI" interface that could be implemented to adapt any security > framework (spring-security, shiro, etc.) to the Wicket-Security API. > The security frameworks themselves wouldn't necessarily (most likely > they would not) implement the interface; there would be an integration > library (e.g. wicket-security-shiro) that bridges the gap.
That sounds a bit overkill to me. I don't think anyone will ever want to use SWARM in a non-Wicket application. Naturally, this is a bit different for Shiro and spring-security, because these are existing projects (if I'm not mistaken), which can also be used without Wicket. WASP (Wicket Abstract Security Platform) is what could serve as a basis for what you call 'the Wicket-Security API'. It will require some work to make it more generic and less 'SWARM'-like, but I think the concept is quite good. This can then serve as a basis to build security providers, such as wicket- security-shiro, wicket-security-spring and SWARM. Emond Papegaaij --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
