Hi,

To the original question (what to do when a PageRequest is not allowed). I'd also vote for #2, navigating to another page. This seems to be the most flexible and customizable approach. 

As for the interface and hasPermission, I think we should keep this more generic and not tie it to Page or PageRequest. There are many potential use cases for checking permissions. If we add a mechanism to register SecurityProviders/PermissionValidators (or whatever we want to call something that can verify permissions) we can keep this nice and extensible. Then, when calling hasPermission (user, page) the provider for verifying pages is looked up and used but when calling hasPermission (user,  someCustomActivity) the provider for custom activities is looked up. In that way we really get fine grained security.

I think keeping our security module independent of whatever server-side security framework is used was a good decision. However, duplicating a lot of API that's already available in PicketLink might be a problem. I don't know the PicketLink API well enough to make a call there.

Cheers,
Christian


On 2013-06-24, at 4:13 AM, Erik Jan de Wit <edewit@redhat.com> wrote:

Hi,

On Jun 20, 2013, at 5:39 PM, Jonathan Fuerth <jfuerth@redhat.com> wrote:

This PageRequest interface is really similar to something Johannes Barop just contributed, but his was a private inner class of Navigation. The fact that this has cropped up twice in the past two days indicates that something is missing from the public API :)

But! Couldn't we just express the hasPermission method like this:

PermissionStatus hasPermission(User user, Page page);

We could create the Page widget instance itself, write the @PageState fields to it, and then ask the permission resolver if we should be allowed to show it. This may be more convenient in many cases because of the type coercion that the framework does when writing page state fields. Does this make sense?

Currently we don't have a Page class only a Page Annotation, do you mean Page as the whole component? If so there is a lot more to serialise than just that state. Wouldn't it be more optimal to introduce the Request object like Johannes also has?


Going even further, why not use the exact same PermissionResolver interface as PicketLink? Then we can stick them in the shared package and reuse them between client and server. Since they're created by the bean manager, there's tons of stuff we could share between client and server simply by injecting the contextual information we need in order to make the decision.

If we go for exactly the same api as picket link we should rethink what we have now. Because now I made it to be more security framework independent, that is also why I make this interface in the first place to make easy to understand and specific for errai. If we go and use the picket link interface in this case we can remove a lot of code, but then it also makes sense to remove the abstraction for security frameworks. Do you agree?


I'm not saying they have to be shareable in all cases, but in many cases it should be possible. "Write it once!" is one of the Errai design principles--at least according to the marketing segment of our conference talks. ;-)

-Jonathan

On 2013-06-20, at 5:48 AM, Erik Jan de Wit wrote:

Hi,

So I've worked some more on fine grained security and I've come up with the following inspired by picket link:

public interface RequestPermissionResolver {
 
  public enum PermissionStatus {
    ALLOW, DENY, NOT_APPLICABLE
  }
 
  /**
   * Tests if the currently authenticated user has permission to 'see' the specified page request.
   *
   * @param user the user to validate the pageRequest for
   * @param pageRequest The pageRequest for which the permission is required
   * @return ALLOW if the current user has the permission DENY or NOT_APPLICABLE.
   */
  PermissionStatus hasPermission(User user, PageRequest pageRequest);

The PageRequest contains the name of the page and the state. By implementing this interface the user can create logic if he wants to show the page that is about to get shown to the user or not.

The only problem I have now is what should we do when the user decides not to show the page? I can see 4 possibilities:

1. Create a message that is shown on the interface somewhere
The problems with this are, what message to show should be translatable and where / how to show it, must 
also be customisable. Could also be helpful as a general error message framework?

2. Navigate to other page
We could navigate to an other page, with a role SecurityError or something like that. This will mean the user
has full control of what will be shown when security errors occur.

3. We redirect to the login page
This is kinda strange because one is already logged in and if there is no message this is not really helping

4. Throw an exception
This is also not really helping as there is no way for the user to do something at this point.

What do you guys think?

Cheers,
Erik Jan


_______________________________________________
errai-dev mailing list
errai-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev

_______________________________________________
errai-dev mailing list
errai-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev

_______________________________________________
errai-dev mailing list
errai-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/errai-dev