Return-Path: Delivered-To: apmail-shiro-user-archive@www.apache.org Received: (qmail 27081 invoked from network); 23 Dec 2010 17:34:17 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 23 Dec 2010 17:34:17 -0000 Received: (qmail 10241 invoked by uid 500); 23 Dec 2010 17:34:17 -0000 Delivered-To: apmail-shiro-user-archive@shiro.apache.org Received: (qmail 10211 invoked by uid 500); 23 Dec 2010 17:34:17 -0000 Mailing-List: contact user-help@shiro.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@shiro.apache.org Delivered-To: mailing list user@shiro.apache.org Received: (qmail 10203 invoked by uid 99); 23 Dec 2010 17:34:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Dec 2010 17:34:16 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of nicolas.antoniazzi@gmail.com designates 209.85.216.45 as permitted sender) Received: from [209.85.216.45] (HELO mail-qw0-f45.google.com) (209.85.216.45) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 23 Dec 2010 17:34:09 +0000 Received: by qwk4 with SMTP id 4so6816431qwk.32 for ; Thu, 23 Dec 2010 09:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=30xkla3XF9vAL30FKUCVzqH51QlPKD0te3eQk98YP6k=; b=EdNQfhRpn0ZFALNpQq79+/pofW8mqJof4evjf6mKG8JubUmSA43wZIfg+UNqV/BljY S2LKMN6wiAU1xDwUcvh6DQp8uL76ApBQSQT/J/ek5PWPLxsfq7nG5CdK9qydA/hkNi++ e1lNQk9q7dG8wdJ7a3ONHzYkZxCcXqUekcnqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=J1sWIfBNlb5Vgc/kSdn8NceCbohyYCkQkR05LTcZEKfOTYk3UYd5T0Pxm3R1XVbSF3 eWWczLQ2JElpSCnbRJe8abWOOHD8ycGt7mH0RN0L1SYpWH13ae823h1eAFIGKn97yiAq uyoCsZ9vjzEsr1Syzlfagy96xQ2fovqM0KQVQ= Received: by 10.224.73.207 with SMTP id r15mr7686558qaj.289.1293125628663; Thu, 23 Dec 2010 09:33:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.84.11 with HTTP; Thu, 23 Dec 2010 09:33:28 -0800 (PST) In-Reply-To: References: From: Nicolas Antoniazzi Date: Thu, 23 Dec 2010 18:33:28 +0100 Message-ID: Subject: Re: Permission on instance To: user@shiro.apache.org Content-Type: multipart/alternative; boundary=0015175cf7c0bf1a0a0498174534 X-Virus-Checked: Checked by ClamAV on apache.org --0015175cf7c0bf1a0a0498174534 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Jared, It's interresting. This was my first idea, but how to handle the fact that severals users have access to the same permission on the item. 1 - user that is the original creator of document can delete it (ok with your code) 2 - admin user should be allowed to delete the document too (so, you have t= o add this case in the code)... 3 ... Maybe other roles should have the right of deleting it too... It could become a bit hard to maintain. 2010/12/23 Jared Bunting > I can tell you what I am currently doing to handle this situation, but I > too am curious if there is a better way. > > I have two slightly different situations that I am handling differently. > > In the first, we=92ll call the item =93dataStore=94 - there are only a fe= w of > them (but still created dynamically by the application), and users have > different access to individual ones depending on if they=92re added as da= ta > consumers or data creators (read/write). For this, I have simply > customized my realm logic to build permissions based on a separate table. > For any users in the data_store_reader table, they get the permission: > dataStore:read:id1,id2,id5 =96 where the ids are the names of datastores = that > they have access to. > > In the second, we=92ll call the item =93document=94. There are lots of t= hem, > they=92re created and deleted all the time. Only the original creator ha= s > access to them. For this situation, I have ignored the concept of > permissions altogether. In the item methods themselves (either directly,= or > via aop, I haven=92t decided which is best, it probably depends on the ex= act > situation) I simply do something along the lines of: > > If(!SecurityUtils.getSubject().isAuthenticated()) { > throw new UnauthenticatedException(=93User must be logged in to access > documents.=94); > } else > If(!this.getOwner().equals(SecurityUtils.getSubject().getPrincipal()) { > throw new UnauthorizedException(=93Document =93 + this.getId() + =93 is= not > owned by =93 + SecurityUtils.getSubject().getPrincipal()); > } > > I=92d be happy to further discuss any techniques and would love to hear f= rom > anyone else regarding other/better ways of approaching this sort of > situation. > > Thanks, > Jared > > > On 12/23/10 7:39 AM, "Nicolas Antoniazzi" > wrote: > > Hello, > > I am using shiro for the server side of a gwt application. I did not find= a > clear explanation in the documentation about instance permission handling= . > My permissions are stored in a database. With a users_roles table and a > roles_permissions table. > > The doc says that we can use instance level for permission > ("item:delete:13") with the WildcardPermission default system, where 13 i= s > the ID of the item. > > Now, my question is : > 1 - how to associate levels to permissions ? Do I have to store the > permission name + the level (edit, create, delete, ...) in the > roles_permissions table ? > example : > admin | item:create > admin | item:delete > admin | item:edit > > 2 - how to set up the instance access ? > If I grant access to everything, I suppose that I could something like : > (if previous example is correct) > admin | item:create:* > admin | item:delete:* > admin | item:edit:* > > But if I only want to grant edit access on an item to users that have > created this item, how can I do ? I suppose that there should have a meth= od > to overload somewhere but I am a bit lost. > > Thanks, > Nicolas. > > --0015175cf7c0bf1a0a0498174534 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Thanks Jared,

It's interresting. This was my first i= dea, but how to handle the fact that severals users have access to the same= permission on the item.
1 - user that is the original creator of= document can delete it (ok with your code)
2 - admin user should be allowed to delete the document too (so, you h= ave to add this case in the code)...
3 ... Maybe other roles shou= ld have the right of deleting it too...
It could become a bit har= d to maintain.=A0

2010/12/23 Jared Bunting <jared.bunting@digitalreasoning.com>
I can tell you what I am currently doing to handle this situation, bu= t I too am curious if there is a better way.

I have two slightly different situations that I am handling differently. = =A0

In the first, we=92ll call the item =93dataStore=94 - there are only a few = of them (but still created dynamically by the application), and users have = different access to individual ones depending on if they=92re added as data= consumers or data creators =A0(read/write). =A0For this, I have simply cus= tomized my realm logic to build permissions based on a separate table. =A0F= or any users in the data_store_reader table, they get the permission: dataS= tore:read:id1,id2,id5 =96 where the ids are the names of datastores that th= ey have access to.

In the second, we=92ll call the item =93document=94. =A0There are lots of t= hem, they=92re created and deleted all the time. =A0Only the original creat= or has access to them. =A0For this situation, I have ignored the concept of= permissions altogether. =A0In the item methods themselves (either directly= , or via aop, I haven=92t decided which is best, it probably depends on the= exact situation) I simply do something along the lines of:

If(!SecurityUtils.getSubject().isAuthenticated()) {
=A0=A0throw new UnauthenticatedException(=93User must be logged in to acces= s documents.=94);
} else If(!this.getOwner().equals(SecurityUtils.getSubject().getPrincipal()= ) {
=A0=A0throw new UnauthorizedException(=93Document =93 + this.getId() + =93 = is not owned by =93 + SecurityUtils.getSubject().getPrincipal());
}

I=92d be happy to further discuss any techniques and would love to hear fro= m anyone else regarding other/better ways of approaching this sort of situa= tion.

Thanks,
Jared =A0


On 12/23/10 7:39 AM, "Nicolas Antoniazzi" <nicolas.antoniazzi@gmail.com= > wrote:

Hello,

I am using shiro for the server side of a gwt application.=A0I did not find= a clear explanation in the documentation about instance permission handlin= g.
My permissions are stored in a database. With a users_roles table and a rol= es_permissions table.

The doc says that we can use instance level for permission ("item:dele= te:13") with the WildcardPermission default system, where 13 is the ID= of the item.

Now, my question is :=A0
1 - how to associate levels to permissions ? Do I have to store the permiss= ion name + the level (edit, create, delete, ...) in the roles_permissions t= able ?
example :
admin | item:create
admin |=A0item:delete
admin |=A0item:edit

2 - how to set up the instance access ?
If I grant access to everything, I suppose that I could something like : (i= f previous example is correct)
admin | item:create:*
admin |=A0item:delete:*
admin |=A0item:edit:*

But if I only want to grant edit access on an item to users that have creat= ed this item, how can I do ? I suppose that there should have a method to o= verload somewhere but I am a bit lost.

Thanks,
Nicolas.


--0015175cf7c0bf1a0a0498174534--