Just a few thoughts. Binary authorization is not always good enough. It would not be too hard to come up with an example that uses authorization to decide if a text field should be editable or not. Also about the executed I agree that most of the time a component you don't allow to be executed is not displayed, but what if we do allow it to be displayed but don't want it to execute. For example a button is displayed disabled or an image map who only allows a few of the possible area's to be accessible for the current user.
________________________________ Maurice Marrink www.topicus.nl -----Original Message----- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: dinsdag 25 oktober 2005 18:02 To: wicket-develop@lists.sourceforge.net Subject: Re: [Wicket-develop] integrating authorization Jonathan and I have been doing a bit of discussion and came up with the following interface: public interface IAuthorizationStrategy { /** * Gets whether the given component may be rendered. * * @param c * the component * @return whether the given component may be rendered */ boolean allowRender(Component c); /** * Checks whether the given component may be created. * * @param c * the component * @return whether the given component may be created */ boolean allowCreation(Component c); } Concerning my first email... whether a component may be 'executed' follows from whether it can be rendered. Take for instance a link. You'll never want to render a link when it is not allowed to be accessed. So, before any event method on a component is called, the check allowRender has to be true. The whole part described as point 3 is nonense. Forget that I wrote that. The method allowCreation is another beast. It's primary purpose is to prevent illegal access to bookmarkable pages. If it should not be allowed in a given context that a page is displayed, you generally don't want any code to execute, including any constructor code. Possibly this might be of use for other uses, which is why we propose to have it at the component level. Concerning Maurice's email. I can see it will work, but my concern is that it is too tightly bound to one specific implementation (being working with 'rights' bits etc). My proposal is to build something like that on top of an interface like we propose, and ship it as a usuable implementation. Another implementation (one that I would like to ship as a wicket-stuff project, and that I intend to use in the project I'm working on now) would be based on annotations and would be binary in nature (either you have access, or you haven't). A final remark, partially based on a patch Maurice just sent me offline, and which I include with this email for the discussion, is that I would like to keep authorisation and authentication seperately. These are conceptually different things, and it is very well possible to have, say, a JAAS based authentication implementation working together with a annotations based authorisation implementation. I didn't give authentication much thought yet, but I don't think there should be any authentication checks by components itself. What I can see working is that any authorisation implementation uses/ depends on a authentication provider to get the right principal. Not sure about how that'll look, but that's for the next email :) Eelco On 10/25/05, Maurice Marrink <[EMAIL PROTECTED]> wrote: > > Johan and i have been working on a generic security framework to allow > various implementations. > For now we only have a jaas implementation but perhaps Eelco can > provided us with an aesgi implementation. > I don't want to give out too much detail just yet but it will feature > > 1. Component visibility > 2. Component execution (2b is implemented like checkaccess) > 3. Data visibility / execution > > Each component will be able to specify which rights it needs (currently > we have specified access,inherit,read,write,execute but users can append > there own rights) and if those rights need to be applied to the > component itself or the components data. > As you might have guessed by the 'inherit' components may inherit rights > from their parents. > Each page has an additional check (like checkaccess) this allows the > entire page to be disabled if one component / model does not allow > access > Links (and other components with listeners) are also checked before > execution. > Pages will automaticly redirect users to the login page if they detect > that the user has not yet logged in, this can be turned off offcourse :) > > Users can customize the security check of components without the need to > know the details of the current security implementation. > We have not (yet) specified the login procedure this is likely going to > be implementation specific (so this would be the only place where the > user actually knows of the specific implementation) this allows login > procedures other then plain username and password to be used. For > example a cipher key or an iris scan. > > Nothing is final yet, but I hope this satisfies your curiosity for now. > > ________________________________ > > Maurice Marrink > www.topicus.nl > > > -----Original Message----- > From: Eelco Hillenius [mailto:[EMAIL PROTECTED] > Sent: dinsdag 25 oktober 2005 1:02 > To: Wicket Develop List > Subject: [Wicket-develop] integrating authorization > > There's a couple of us working on integrating/ further enhancing > authorization in Wicket. With this email, I'd like to start a > (hopefully short) discussion to get things really clear. For the > framework, we should be concerned to have the basic support there > without actually implementing one specific solution. Like checkAcces > is now. > > For authorization, we roughly have to following scenarios: > > 1. Component visibility. Components should only be rendered when they > are allowed to be rendered. Example: you can have a page with a number > of panels, of which you only want to render the subset that is > available to the current user. > > This can be done now by overriding isVisible. I'd prefer a more > specialized manner for authorization, so that it can easily be used as > e.g. a pluggable strategy. > > 2. Component execution. 'Component code' should only be executed when > allowed. > a) Event methods like Link.onClick. This can be done by a method > like the recently added beforeCallComponent. I'd prefer not to use > that method, but to introduce a new one that is executed just before > 'beforeCallComponent', so that we keep 'beforeCallComponent' clean > (and thus users don't have to worry about calling > super.beforeCallComponent).. > b) Construction time. That's a hard one. Makes sense for e.g. > bookmarkable pages, but would not be good for constructions like > setPage(new SomePage()). Currently, Page.checkAccess is called first > thing in onRender. Imo, that's the wrong place conceptually, as it > should have been called much earlier. E.g. when a bookmarkable page is > accessed by a users that shouldn't, all the construction code is > executed - possibly executing stuff you don't want to execute in case > a user doesn't have access to the page. Practically, this might be the > only place where it makes sense using methods like we do now, as we > can't call virtual methods from constructors. > > 3. References to components. Components/ resources should only be > rendered when they reference allowed resources. Example: a link should > not be rendered when it references a page that the current user > doesn't have access to. Probably the only 'enforcement point' is to > put checks in all urlFor methods that we have. These are a bit > scattered, and it couldn't prevent users from constructing e.g. links > without calling urlFor, but it covers all normal behaviour. > > Now, to sum up, the cases I sketched above are very different. It can > not be one simple method that covers all. I think the most elegant > would be to come up with a interface that enables users to plug in > their own strategy for authentication. The methods of the interface > should cover the above cases. In the case of 1 and 3, it should just > return a boolean, so that checking is cheap and quick; I can't think > of an actual case where you want to bubble up a message on why access > was not allowed. In the case of 2, I think such an access checking > method should throw a checked exception, possibly providing a reason > for dissalowing access. Case 2 should be relatively rare (really an > exception so to speak), and represents a case that, while not > recoverable, potentially requires information to be bubbled up (that's > why it needs a checked exception). Having such an interface will not > give users an out-of-the-box working solution for authorization in > Wicket. My idea is however, that this should enable for building > working implementations for specific situations, like combined with > annotations, Spring Acegi, etc. > > I'm still in thinking mode, so maybe I forgot implications, and I > don't have a concrete idea about the interface yet, but I hope this > email is a good start. > > Eelco > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Wicket-develop mailing list > Wicket-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wicket-develop > ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
