[errai-dev] fine grained security

[Christian Sadilek]

Hi,

Thanks for the summary!

One thought I had last week is that we should support @RequiresAuthentication and @RequiresRoles on pages. This is fine grained enough for many use cases. 

I think that sharing a link needs finer grained control especially for the page state (request parameters). What I think would be really useful here is an API to create a "shared public or private link". Errai could generate a URL including a secure token that can be validated against the users permissions when opened. So, the token would represent the page state plus the requirements to view the page (e.g. the user, group or role I want to share the link with).

Say I (as an admin) want to share a link to the following page (@RequiresAuthentication, @RequiresRoles({"Admin", "HR" })) with the actual employee:

http;//www.company.com/app/admin/#EmployeeDetailPage;employeeId=4711

If we had an utility to create a shared link which also allowed to specify the user/group/role that I intend to share the link with we could generate

http;//www.company.com/app/#Share;5dd43r19wcqrpme….

This would only open the page above if the security requirements are met (the user that opens the link is the user I specified when creating the link and has the corresponding permissions). Of course, this validation needs to happen on the server.

This is just an idea, but I had to implement features like this a couple of times already and think it would be a nice addition.

Cheers,
Christian

On 2013-06-18, at 7:52 AM, Erik Jan de Wit <edewit at redhat.com> wrote:

> Hi,
> 
> We (Jonathan and I) had a chat today with Shane Bryzak how we could implement fine grained security. To give a little context Jonathan felt a need for something like that when integrating errai-security into the TODO list demo. He wants users to be able to share their lists with others. Another use for this would be in navigation, when a user can be shown a page only, if the request parameters combination is allowed for the specific user.
> 
> PicketLink supports fine grained security when one implements a Service Provider Interface 
> 
> public interface PermissionResolver
> {
>     public enum PermissionStatus {
>         ALLOW, DENY, NOT_APPLICABLE
>     }
> 
>     PermissionStatus hasPermission(Object resource, String operation);
> 
>     PermissionStatus hasPermission(Class<?> resourceClass, Serializable identifier, String operation);
> }
> 
> Now the only thing we need to figure out is, a way to fit this into an api so that it's not PicketLink specific. And even better have it declarative, but it seems to be to fine grained to do that.
> 
> I've create some issues already to track work on these things.
> 
> Any thoughts,
> 	Erik Jan
> _______________________________________________
> errai-dev mailing list
> errai-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/errai-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/errai-dev/attachments/20130618/a0d4a1a1/attachment.html