You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by "Holmes, Charles V." <ch...@mitre.org> on 2009/10/12 19:26:44 UTC
Declaratively Defining Authorization Rules based on URL method
I browsed through the ShiroFilter and DefaultFilterChainManager code, and I don't think this is supported. However, is there any way to declaratively limit a url resource based on how the url is requested via the web.xml file? I realize there are other ways to define this rule including custom filters and using Spring's annotations. However, I'm just trying to understand all options before I proceed.
For example, I want to allow any authenticated user to be able to retrieve a list of stocks, but I only want an admin to be able to create a new stock. Assuming this is exposed in a restful way, I want to allow anyone to issue GET requests against the URL, but I want to restrict POST requests to a specific role. A possible example is:
/data/stocks/** = authc, methods[get]
/data/stocks/** = authc, roles[admin], methods[post]
Thanks!
Charles
Re: Declaratively Defining Authorization Rules based on URL method
Posted by Brian Demers <br...@gmail.com>.
No objections.
We have a few other ideas and snippets to contribute, but that is for
another thread.
-Brian
On Tue, Oct 13, 2009 at 12:08 PM, Les Hazlewood <lh...@apache.org>wrote:
> Yeah, I forgot about that. I also much prefer using permissions as a
> means for doing this.
>
> So, to summarize, when you issue a GET request to /products/12345
>
> this really translates to a permission check to see if the current
> user can "read" the "product" with id 12345. Or via Shiro's Wildcard
> permission semantics: "product:12345:read"
>
> This is certainly a much cleaner way to check abilities than to
> tightly couple one's security model with web protocols.
>
> Thanks for sharing the code Brian - any objections to incorporating it
> into Shiro's codebase?
>
> - Les
>
> On Tue, Oct 13, 2009 at 11:35 AM, Brian Demers <br...@gmail.com>
> wrote:
> >
> > For Nexus we would not be able to manage the number of resources in a
> static
> > configuration (because of both the number of REST resources we have and
> the
> > plugin model).
> >
> > Our resources are self descriptive (loosely coupled to jsecurity)
> everything
> > is configured at runtime. So my thoughts are more geared to that.
> >
> > But here are some thoughts anyway:
> >
> > We use CRUD terms vs the HTTP methods so we do not couple our selves
> with
> > HTTP methods.
> > The operation should be part of the permission. So for
> > /rest/service/foobar should be mapped to the permission
> > application:foobar:read
> >
> > I am not sure the best way to do this type of mapping directly to a
> role. I
> > am partial to the permission model, where roles / groups are just buckets
> of
> > permissions.
> >
> > -Brian
> >
> >
> > On Tue, Oct 13, 2009 at 10:55 AM, Les Hazlewood <lh...@apache.org>
> > wrote:
> >>
> >> Oh cool - thanks for sharing Brian.
> >>
> >> Given what you have done for Nexus and what I just proposed in the
> >> ticket, do you have any suggestions on what you feel would be the best
> >> way to go about solving this?
> >>
> >> I'm trying to vet if what I recommended is 'ideal' or if you (or
> >> anyone else) might have a better idea.
> >>
> >> Thanks,
> >>
> >> Les
> >>
> >> On Tue, Oct 13, 2009 at 9:45 AM, Brian Demers <br...@gmail.com>
> >> wrote:
> >> >
> >> > Nexus (http://nexus.sonatype.org/ ) does something simalar to this.
> >> >
> >> > We basically have permissions tied to our REST resources, for example
> >> > "authcBasic,perms[nexus:repositories]' and based on the request
> method
> >> > (using a custom filter) we add the method to the end of the permission
> >> > so
> >> > nexus:repositories becomes
> >> > nexus:repositories:read - for a HEAD or GET
> >> > nexus:repositories:update - for PUT
> >> > nexus:repositories:create - for POST
> >> >
> >> > This is still using JSecurity 0.9 RC2 (at the moment)
> >> >
> >> >
> https://svn.sonatype.org/spice/trunk/plexus-security/security-system/src/main/java/org/sonatype/security/web/filter/authz/HttpVerbMappingAuthorizationFilter.java
> >> >
> >> > I figured I would share what has been working for us.
> >> > -Brian
> >> >
> >> >
> >> >
> >> > On Tue, Oct 13, 2009 at 9:27 AM, Les Hazlewood <lhazlewood@apache.org
> >
> >> > wrote:
> >> >>
> >> >> Hi Charles,
> >> >>
> >> >> No, we currently don't have a way of triggering chains based on the
> >> >> request method (post, get, put, delete) at the moment. This is an
> >> >> interesting idea though and shouldn't be too hard to implement. I
> >> >> think indicating the method along with the URL might be a little
> >> >> better though, since that would be part of the request matching logic
> >> >> (path + method) - maybe something like this:
> >> >>
> >> >> /data/stocks/**:post = authc, roles[admin]
> >> >> /data/stocks/** = authc
> >> >>
> >> >> A few people who use REST have raised similar questions. I've added
> >> >> it as a Jira issue so we don't lose the idea:
> >> >>
> >> >> https://issues.apache.org/jira/browse/SHIRO-107
> >> >>
> >> >> Regards,
> >> >>
> >> >> Les
> >> >>
> >> >> On Mon, Oct 12, 2009 at 1:26 PM, Holmes, Charles V. <
> cholmes@mitre.org>
> >> >> wrote:
> >> >> > I browsed through the ShiroFilter and DefaultFilterChainManager
> code,
> >> >> > and I
> >> >> > don’t think this is supported. However, is there any way to
> >> >> > declaratively
> >> >> > limit a url resource based on how the url is requested via the
> >> >> > web.xml
> >> >> > file? I realize there are other ways to define this rule including
> >> >> > custom
> >> >> > filters and using Spring’s annotations. However, I’m just trying
> to
> >> >> > understand all options before I proceed.
> >> >> >
> >> >> >
> >> >> >
> >> >> > For example, I want to allow any authenticated user to be able to
> >> >> > retrieve a
> >> >> > list of stocks, but I only want an admin to be able to create a new
> >> >> > stock.
> >> >> > Assuming this is exposed in a restful way, I want to allow anyone
> to
> >> >> > issue
> >> >> > GET requests against the URL, but I want to restrict POST requests
> to
> >> >> > a
> >> >> > specific role. A possible example is:
> >> >> >
> >> >> > /data/stocks/** = authc, methods[get]
> >> >> >
> >> >> > /data/stocks/** = authc, roles[admin], methods[post]
> >> >> >
> >> >> >
> >> >> >
> >> >> > Thanks!
> >> >> >
> >> >> > Charles
> >> >
> >> >
> >
> >
>
Re: Declaratively Defining Authorization Rules based on URL method
Posted by Les Hazlewood <lh...@apache.org>.
Yeah, I forgot about that. I also much prefer using permissions as a
means for doing this.
So, to summarize, when you issue a GET request to /products/12345
this really translates to a permission check to see if the current
user can "read" the "product" with id 12345. Or via Shiro's Wildcard
permission semantics: "product:12345:read"
This is certainly a much cleaner way to check abilities than to
tightly couple one's security model with web protocols.
Thanks for sharing the code Brian - any objections to incorporating it
into Shiro's codebase?
- Les
On Tue, Oct 13, 2009 at 11:35 AM, Brian Demers <br...@gmail.com> wrote:
>
> For Nexus we would not be able to manage the number of resources in a static
> configuration (because of both the number of REST resources we have and the
> plugin model).
>
> Our resources are self descriptive (loosely coupled to jsecurity) everything
> is configured at runtime. So my thoughts are more geared to that.
>
> But here are some thoughts anyway:
>
> We use CRUD terms vs the HTTP methods so we do not couple our selves with
> HTTP methods.
> The operation should be part of the permission. So for
> /rest/service/foobar should be mapped to the permission
> application:foobar:read
>
> I am not sure the best way to do this type of mapping directly to a role. I
> am partial to the permission model, where roles / groups are just buckets of
> permissions.
>
> -Brian
>
>
> On Tue, Oct 13, 2009 at 10:55 AM, Les Hazlewood <lh...@apache.org>
> wrote:
>>
>> Oh cool - thanks for sharing Brian.
>>
>> Given what you have done for Nexus and what I just proposed in the
>> ticket, do you have any suggestions on what you feel would be the best
>> way to go about solving this?
>>
>> I'm trying to vet if what I recommended is 'ideal' or if you (or
>> anyone else) might have a better idea.
>>
>> Thanks,
>>
>> Les
>>
>> On Tue, Oct 13, 2009 at 9:45 AM, Brian Demers <br...@gmail.com>
>> wrote:
>> >
>> > Nexus (http://nexus.sonatype.org/ ) does something simalar to this.
>> >
>> > We basically have permissions tied to our REST resources, for example
>> > "authcBasic,perms[nexus:repositories]' and based on the request method
>> > (using a custom filter) we add the method to the end of the permission
>> > so
>> > nexus:repositories becomes
>> > nexus:repositories:read - for a HEAD or GET
>> > nexus:repositories:update - for PUT
>> > nexus:repositories:create - for POST
>> >
>> > This is still using JSecurity 0.9 RC2 (at the moment)
>> >
>> > https://svn.sonatype.org/spice/trunk/plexus-security/security-system/src/main/java/org/sonatype/security/web/filter/authz/HttpVerbMappingAuthorizationFilter.java
>> >
>> > I figured I would share what has been working for us.
>> > -Brian
>> >
>> >
>> >
>> > On Tue, Oct 13, 2009 at 9:27 AM, Les Hazlewood <lh...@apache.org>
>> > wrote:
>> >>
>> >> Hi Charles,
>> >>
>> >> No, we currently don't have a way of triggering chains based on the
>> >> request method (post, get, put, delete) at the moment. This is an
>> >> interesting idea though and shouldn't be too hard to implement. I
>> >> think indicating the method along with the URL might be a little
>> >> better though, since that would be part of the request matching logic
>> >> (path + method) - maybe something like this:
>> >>
>> >> /data/stocks/**:post = authc, roles[admin]
>> >> /data/stocks/** = authc
>> >>
>> >> A few people who use REST have raised similar questions. I've added
>> >> it as a Jira issue so we don't lose the idea:
>> >>
>> >> https://issues.apache.org/jira/browse/SHIRO-107
>> >>
>> >> Regards,
>> >>
>> >> Les
>> >>
>> >> On Mon, Oct 12, 2009 at 1:26 PM, Holmes, Charles V. <ch...@mitre.org>
>> >> wrote:
>> >> > I browsed through the ShiroFilter and DefaultFilterChainManager code,
>> >> > and I
>> >> > don’t think this is supported. However, is there any way to
>> >> > declaratively
>> >> > limit a url resource based on how the url is requested via the
>> >> > web.xml
>> >> > file? I realize there are other ways to define this rule including
>> >> > custom
>> >> > filters and using Spring’s annotations. However, I’m just trying to
>> >> > understand all options before I proceed.
>> >> >
>> >> >
>> >> >
>> >> > For example, I want to allow any authenticated user to be able to
>> >> > retrieve a
>> >> > list of stocks, but I only want an admin to be able to create a new
>> >> > stock.
>> >> > Assuming this is exposed in a restful way, I want to allow anyone to
>> >> > issue
>> >> > GET requests against the URL, but I want to restrict POST requests to
>> >> > a
>> >> > specific role. A possible example is:
>> >> >
>> >> > /data/stocks/** = authc, methods[get]
>> >> >
>> >> > /data/stocks/** = authc, roles[admin], methods[post]
>> >> >
>> >> >
>> >> >
>> >> > Thanks!
>> >> >
>> >> > Charles
>> >
>> >
>
>
Re: Declaratively Defining Authorization Rules based on URL method
Posted by Brian Demers <br...@gmail.com>.
For Nexus we would not be able to manage the number of resources in a static
configuration (because of both the number of REST resources we have and the
plugin model).
Our resources are self descriptive (loosely coupled to jsecurity) everything
is configured at runtime. So my thoughts are more geared to that.
But here are some thoughts anyway:
- We use CRUD terms vs the HTTP methods so we do not couple our selves
with HTTP methods.
- The operation should be part of the permission. So for
/rest/service/foobar should be mapped to the permission
application:foobar:read
I am not sure the best way to do this type of mapping directly to a role. I
am partial to the permission model, where roles / groups are just buckets of
permissions.
-Brian
On Tue, Oct 13, 2009 at 10:55 AM, Les Hazlewood <lh...@apache.org>wrote:
> Oh cool - thanks for sharing Brian.
>
> Given what you have done for Nexus and what I just proposed in the
> ticket, do you have any suggestions on what you feel would be the best
> way to go about solving this?
>
> I'm trying to vet if what I recommended is 'ideal' or if you (or
> anyone else) might have a better idea.
>
> Thanks,
>
> Les
>
> On Tue, Oct 13, 2009 at 9:45 AM, Brian Demers <br...@gmail.com>
> wrote:
> >
> > Nexus (http://nexus.sonatype.org/ ) does something simalar to this.
> >
> > We basically have permissions tied to our REST resources, for example
> > "authcBasic,perms[nexus:repositories]' and based on the request method
> > (using a custom filter) we add the method to the end of the permission so
> > nexus:repositories becomes
> > nexus:repositories:read - for a HEAD or GET
> > nexus:repositories:update - for PUT
> > nexus:repositories:create - for POST
> >
> > This is still using JSecurity 0.9 RC2 (at the moment)
> >
> https://svn.sonatype.org/spice/trunk/plexus-security/security-system/src/main/java/org/sonatype/security/web/filter/authz/HttpVerbMappingAuthorizationFilter.java
> >
> > I figured I would share what has been working for us.
> > -Brian
> >
> >
> >
> > On Tue, Oct 13, 2009 at 9:27 AM, Les Hazlewood <lh...@apache.org>
> > wrote:
> >>
> >> Hi Charles,
> >>
> >> No, we currently don't have a way of triggering chains based on the
> >> request method (post, get, put, delete) at the moment. This is an
> >> interesting idea though and shouldn't be too hard to implement. I
> >> think indicating the method along with the URL might be a little
> >> better though, since that would be part of the request matching logic
> >> (path + method) - maybe something like this:
> >>
> >> /data/stocks/**:post = authc, roles[admin]
> >> /data/stocks/** = authc
> >>
> >> A few people who use REST have raised similar questions. I've added
> >> it as a Jira issue so we don't lose the idea:
> >>
> >> https://issues.apache.org/jira/browse/SHIRO-107
> >>
> >> Regards,
> >>
> >> Les
> >>
> >> On Mon, Oct 12, 2009 at 1:26 PM, Holmes, Charles V. <ch...@mitre.org>
> >> wrote:
> >> > I browsed through the ShiroFilter and DefaultFilterChainManager code,
> >> > and I
> >> > don’t think this is supported. However, is there any way to
> >> > declaratively
> >> > limit a url resource based on how the url is requested via the web.xml
> >> > file? I realize there are other ways to define this rule including
> >> > custom
> >> > filters and using Spring’s annotations. However, I’m just trying to
> >> > understand all options before I proceed.
> >> >
> >> >
> >> >
> >> > For example, I want to allow any authenticated user to be able to
> >> > retrieve a
> >> > list of stocks, but I only want an admin to be able to create a new
> >> > stock.
> >> > Assuming this is exposed in a restful way, I want to allow anyone to
> >> > issue
> >> > GET requests against the URL, but I want to restrict POST requests to
> a
> >> > specific role. A possible example is:
> >> >
> >> > /data/stocks/** = authc, methods[get]
> >> >
> >> > /data/stocks/** = authc, roles[admin], methods[post]
> >> >
> >> >
> >> >
> >> > Thanks!
> >> >
> >> > Charles
> >
> >
>
Re: Declaratively Defining Authorization Rules based on URL method
Posted by Les Hazlewood <lh...@apache.org>.
Oh cool - thanks for sharing Brian.
Given what you have done for Nexus and what I just proposed in the
ticket, do you have any suggestions on what you feel would be the best
way to go about solving this?
I'm trying to vet if what I recommended is 'ideal' or if you (or
anyone else) might have a better idea.
Thanks,
Les
On Tue, Oct 13, 2009 at 9:45 AM, Brian Demers <br...@gmail.com> wrote:
>
> Nexus (http://nexus.sonatype.org/ ) does something simalar to this.
>
> We basically have permissions tied to our REST resources, for example
> "authcBasic,perms[nexus:repositories]' and based on the request method
> (using a custom filter) we add the method to the end of the permission so
> nexus:repositories becomes
> nexus:repositories:read - for a HEAD or GET
> nexus:repositories:update - for PUT
> nexus:repositories:create - for POST
>
> This is still using JSecurity 0.9 RC2 (at the moment)
> https://svn.sonatype.org/spice/trunk/plexus-security/security-system/src/main/java/org/sonatype/security/web/filter/authz/HttpVerbMappingAuthorizationFilter.java
>
> I figured I would share what has been working for us.
> -Brian
>
>
>
> On Tue, Oct 13, 2009 at 9:27 AM, Les Hazlewood <lh...@apache.org>
> wrote:
>>
>> Hi Charles,
>>
>> No, we currently don't have a way of triggering chains based on the
>> request method (post, get, put, delete) at the moment. This is an
>> interesting idea though and shouldn't be too hard to implement. I
>> think indicating the method along with the URL might be a little
>> better though, since that would be part of the request matching logic
>> (path + method) - maybe something like this:
>>
>> /data/stocks/**:post = authc, roles[admin]
>> /data/stocks/** = authc
>>
>> A few people who use REST have raised similar questions. I've added
>> it as a Jira issue so we don't lose the idea:
>>
>> https://issues.apache.org/jira/browse/SHIRO-107
>>
>> Regards,
>>
>> Les
>>
>> On Mon, Oct 12, 2009 at 1:26 PM, Holmes, Charles V. <ch...@mitre.org>
>> wrote:
>> > I browsed through the ShiroFilter and DefaultFilterChainManager code,
>> > and I
>> > don’t think this is supported. However, is there any way to
>> > declaratively
>> > limit a url resource based on how the url is requested via the web.xml
>> > file? I realize there are other ways to define this rule including
>> > custom
>> > filters and using Spring’s annotations. However, I’m just trying to
>> > understand all options before I proceed.
>> >
>> >
>> >
>> > For example, I want to allow any authenticated user to be able to
>> > retrieve a
>> > list of stocks, but I only want an admin to be able to create a new
>> > stock.
>> > Assuming this is exposed in a restful way, I want to allow anyone to
>> > issue
>> > GET requests against the URL, but I want to restrict POST requests to a
>> > specific role. A possible example is:
>> >
>> > /data/stocks/** = authc, methods[get]
>> >
>> > /data/stocks/** = authc, roles[admin], methods[post]
>> >
>> >
>> >
>> > Thanks!
>> >
>> > Charles
>
>
Re: Declaratively Defining Authorization Rules based on URL method
Posted by Brian Demers <br...@gmail.com>.
Nexus (http://nexus.sonatype.org/ ) does something simalar to this.
We basically have permissions tied to our REST resources, for example
"authcBasic,perms[nexus:repositories]' and based on the request method
(using a custom filter) we add the method to the end of the permission so
nexus:repositories becomes
nexus:repositories:read - for a HEAD or GET
nexus:repositories:update - for PUT
nexus:repositories:create - for POST
This is still using JSecurity 0.9 RC2 (at the moment)
https://svn.sonatype.org/spice/trunk/plexus-security/security-system/src/main/java/org/sonatype/security/web/filter/authz/HttpVerbMappingAuthorizationFilter.java
I figured I would share what has been working for us.
-Brian
On Tue, Oct 13, 2009 at 9:27 AM, Les Hazlewood <lh...@apache.org>wrote:
> Hi Charles,
>
> No, we currently don't have a way of triggering chains based on the
> request method (post, get, put, delete) at the moment. This is an
> interesting idea though and shouldn't be too hard to implement. I
> think indicating the method along with the URL might be a little
> better though, since that would be part of the request matching logic
> (path + method) - maybe something like this:
>
> /data/stocks/**:post = authc, roles[admin]
> /data/stocks/** = authc
>
> A few people who use REST have raised similar questions. I've added
> it as a Jira issue so we don't lose the idea:
>
> https://issues.apache.org/jira/browse/SHIRO-107
>
> Regards,
>
> Les
>
> On Mon, Oct 12, 2009 at 1:26 PM, Holmes, Charles V. <ch...@mitre.org>
> wrote:
> > I browsed through the ShiroFilter and DefaultFilterChainManager code, and
> I
> > don’t think this is supported. However, is there any way to
> declaratively
> > limit a url resource based on how the url is requested via the web.xml
> > file? I realize there are other ways to define this rule including
> custom
> > filters and using Spring’s annotations. However, I’m just trying to
> > understand all options before I proceed.
> >
> >
> >
> > For example, I want to allow any authenticated user to be able to
> retrieve a
> > list of stocks, but I only want an admin to be able to create a new
> stock.
> > Assuming this is exposed in a restful way, I want to allow anyone to
> issue
> > GET requests against the URL, but I want to restrict POST requests to a
> > specific role. A possible example is:
> >
> > /data/stocks/** = authc, methods[get]
> >
> > /data/stocks/** = authc, roles[admin], methods[post]
> >
> >
> >
> > Thanks!
> >
> > Charles
>
Re: Declaratively Defining Authorization Rules based on URL method
Posted by Les Hazlewood <lh...@apache.org>.
Hi Charles,
No, we currently don't have a way of triggering chains based on the
request method (post, get, put, delete) at the moment. This is an
interesting idea though and shouldn't be too hard to implement. I
think indicating the method along with the URL might be a little
better though, since that would be part of the request matching logic
(path + method) - maybe something like this:
/data/stocks/**:post = authc, roles[admin]
/data/stocks/** = authc
A few people who use REST have raised similar questions. I've added
it as a Jira issue so we don't lose the idea:
https://issues.apache.org/jira/browse/SHIRO-107
Regards,
Les
On Mon, Oct 12, 2009 at 1:26 PM, Holmes, Charles V. <ch...@mitre.org> wrote:
> I browsed through the ShiroFilter and DefaultFilterChainManager code, and I
> don’t think this is supported. However, is there any way to declaratively
> limit a url resource based on how the url is requested via the web.xml
> file? I realize there are other ways to define this rule including custom
> filters and using Spring’s annotations. However, I’m just trying to
> understand all options before I proceed.
>
>
>
> For example, I want to allow any authenticated user to be able to retrieve a
> list of stocks, but I only want an admin to be able to create a new stock.
> Assuming this is exposed in a restful way, I want to allow anyone to issue
> GET requests against the URL, but I want to restrict POST requests to a
> specific role. A possible example is:
>
> /data/stocks/** = authc, methods[get]
>
> /data/stocks/** = authc, roles[admin], methods[post]
>
>
>
> Thanks!
>
> Charles