Return-Path: Delivered-To: apmail-incubator-shiro-user-archive@www.apache.org Received: (qmail 26318 invoked from network); 23 Feb 2010 16:22:18 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 23 Feb 2010 16:22:18 -0000 Received: (qmail 48937 invoked by uid 500); 23 Feb 2010 16:22:17 -0000 Delivered-To: apmail-incubator-shiro-user-archive@incubator.apache.org Received: (qmail 48919 invoked by uid 500); 23 Feb 2010 16:22:17 -0000 Mailing-List: contact shiro-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: shiro-user@incubator.apache.org Delivered-To: mailing list shiro-user@incubator.apache.org Received: (qmail 48910 invoked by uid 99); 23 Feb 2010 16:22:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Feb 2010 16:22:17 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of brian.demers@gmail.com designates 209.85.210.187 as permitted sender) Received: from [209.85.210.187] (HELO mail-yx0-f187.google.com) (209.85.210.187) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 23 Feb 2010 16:22:10 +0000 Received: by yxe17 with SMTP id 17so138882yxe.32 for ; Tue, 23 Feb 2010 08:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=HMBFvi3/uSzq0yt6b8RtFZAlJcN95fgblhb0Er6pJSI=; b=c+l3ATVD0/aSzRqMvplpYYUIOt/p9uQLLsxNBaQygNUtdZgbc3zdYHRCoMtNH7KdfH DGnQUYLSXbet5JYkEguazn6dyposhxnP8KwnJbSi+13UM7APX3hUtkwrsC/qWxkyFqdO WC9OIiSH22MIs9SjOf87X8+dZApk6oZEb2Buk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mdEwcc3y8+OwemQYs/bLMIMCgIQXyBpL5ZFmQEmeVjnDgc0VHs/rre8jYwXkExyqdC s+/A1ygGwFlj+0Z3S6i310Ozec5tqGTzEMVHPxQVN2eZrL1VTi0GyWV4jh/XrGauvt/z /ATT3S7pdxQRiUzNLPP2XZFOFUAlqj73WYhy4= MIME-Version: 1.0 Received: by 10.150.127.29 with SMTP id z29mr337163ybc.39.1266942109411; Tue, 23 Feb 2010 08:21:49 -0800 (PST) In-Reply-To: <44b57a611002230710h7798b89pc393e12001eef27a@mail.gmail.com> References: <1266885715575-4616037.post@n2.nabble.com> <44b57a611002230627l66ac86a2oa35baac4d4904308@mail.gmail.com> <7281ca711002230651t464fb494v8ba065ae8c4ffd43@mail.gmail.com> <44b57a611002230710h7798b89pc393e12001eef27a@mail.gmail.com> Date: Tue, 23 Feb 2010 11:21:49 -0500 Message-ID: Subject: Re: permission everything but this item From: Brian Demers To: shiro-user@incubator.apache.org Content-Type: multipart/alternative; boundary=000e0cd71ede61e917048046f24d --000e0cd71ede61e917048046f24d Content-Type: text/plain; charset=ISO-8859-1 I had a few discussions internally about similar annotations. We need to fill a hole in the JSR 331 annotations when it comes to security. We need similar annotations. So in the example of: @Path( "/example/{path-param}/foo/{another-param}" ) @Produces( { "application/xml", "application/json" } ) @Consumes( { "application/xml", "application/json" } ) we would need something like: @RequirePermission( "authcBasic,perms[app:example]" ); We _might_ need to add the permission path also, in the example above it would be simple to figure out: /example/*/foo/* but I also have a few paths that would need to be something like /example/*/foo/**, ( /example/one/foo/bar/hello/something-else) which could not be generated. Any ideas? I don't want to mix web apps and non web apps here, but I figured I would throw out the question. -Brian On Tue, Feb 23, 2010 at 10:10 AM, Les Hazlewood wrote: > I agree - the default for morst secure apps should be deny all unless > allowed. This is safer in that it often catches unexpected holes that > you had no idea would be open otherwise. > > Shiro's behavior is already to deny access to everything unless > explicitly granted access, but yes, it does require the declaration of > an annotation or URL chain to trigger the checking behavior. We'd > probably just need to add some AOP support to prevent all invocations > unless there is the presence of an annotation. > > You're right in that it wouldn't incur a performance hit - you'd only > actually do the role/permission check if you come across an annotation > and just deny everything else. > > I think the existing RequiresRoles/RequiresPermissions annotations > would work fine in this context. It would probably just be a > configuration issue to turn on or off the 'deny all if not annotated' > behavior. > > Les > > On Tue, Feb 23, 2010 at 9:51 AM, Kalle Korhonen > wrote: > > But I've often thought that the whole security should be based on > > allowing nothing until you explicitly do so. If we had a set of > > @AllowRole, @AllowPermission,... it'd simple to deny access to any > > resources that didn't have the annotation without incurring a > > performance hit. Just a thought at this point... > > > > Kalle > > > > > > On Tue, Feb 23, 2010 at 6:32 AM, Brian Demers > wrote: > >> I see how they would be handy some times, but.... we try to avoid them > like > >> the plague ;) > >> > >> On Tue, Feb 23, 2010 at 9:27 AM, Les Hazlewood > >> wrote: > >>> > >>> No, 'negative' permissions are not supported out of the box due to the > >>> complexity and performance hit it would probably incur. You're more > >>> than welcome to open a feature request in Jira however. > >>> > >>> Regards, > >>> > >>> Les > >>> > >>> On Mon, Feb 22, 2010 at 7:41 PM, jobiwan11 > >>> wrote: > >>> > > >>> > If you have a permission like "printer:print:*" is there a way to say > >>> > you're > >>> > not allowed to print to "lpd7" without getting rid of the > >>> > "printer:print:*" > >>> > and listing out individual permissions per printer? > >>> > Thanks, > >>> > --jim > >>> > -- > >>> > View this message in context: > >>> > > http://n2.nabble.com/permission-everything-but-this-item-tp4616037p4616037.html > >>> > Sent from the Shiro User mailing list archive at Nabble.com. > >>> > > >> > >> > > > --000e0cd71ede61e917048046f24d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I had a few discussions internally about similar annotations.=A0 We nee= d to fill a hole in the JSR 331 annotations when it comes to security.=A0 W= e need similar annotations.

So in the example of:

@Path( &q= uot;/example/{path-param}/foo/{another-param}" )
@Produces( { "application/xml", "application/json" } )<= br>@Consumes( { "application/xml", "application/json" }= )

we would need something like:
@RequirePermission( "authcB= asic,perms[app:example]" );

We _might_ need to add the permission path also, in the example above i= t would be simple to figure out: /example/*/foo/*
but I also have a few = paths that would need to be something like /example/*/foo/**, ( /example/on= e/foo/bar/hello/something-else) which could not be generated.

Any ideas?=A0 I don't want to mix web apps and non web apps here, b= ut I figured I would throw out the question.

-Brian



<= br>
On Tue, Feb 23, 2010 at 10:10 AM, Les Hazlewo= od <lhazlewoo= d@apache.org> wrote:
I agree - the def= ault for morst secure apps should be deny all unless
allowed. =A0This is safer in that it often catches unexpected holes that you had no idea would be open otherwise.

Shiro's behavior is already to deny access to everything unless
explicitly granted access, but yes, it does require the declaration of
an annotation or URL chain to trigger the checking behavior. =A0We'd probably just need to add some AOP support to prevent all invocations
unless there is the presence of an annotation.

You're right in that it wouldn't incur a performance hit - you'= d only
actually do the role/permission check if you come across an annotation
and just deny everything else.

I think the existing RequiresRoles/RequiresPermissions annotations
would work fine in this context. =A0It would probably just be a
configuration issue to turn on or off the 'deny all if not annotated= 9;
behavior.

Les

On Tue, Feb 23, 2010 at 9:51 AM, Kalle Korhonen
<kalle.o.korhonen@gmail.co= m> wrote:
> But I've often thought that the whole security should be based on<= br> > allowing nothing until you explicitly do so. If we had a set of
> @AllowRole, @AllowPermission,... it'd simple to deny access to any=
> resources that didn't have the annotation without incurring a
> performance hit. Just a thought at this point...
>
> Kalle
>
>
> On Tue, Feb 23, 2010 at 6:32 AM, Brian Demers <brian.demers@gmail.com> wrote:
>> I see how they would be handy some times, but.... we try to avoid = them like
>> the plague ;)
>>
>> On Tue, Feb 23, 2010 at 9:27 AM, Les Hazlewood <lhazlewood@apache.org>
>> wrote:
>>>
>>> No, 'negative' permissions are not supported out of th= e box due to the
>>> complexity and performance hit it would probably incur. =A0You= 're more
>>> than welcome to open a feature request in Jira however.
>>>
>>> Regards,
>>>
>>> Les
>>>
>>> On Mon, Feb 22, 2010 at 7:41 PM, jobiwan11 <james.s.obrien@gmail.com>
>>> wrote:
>>> >
>>> > If you have a permission like "printer:print:*"= is there a way to say
>>> > you're
>>> > not allowed to print to "lpd7" without getting = rid of the
>>> > "printer:print:*"
>>> > and listing out individual permissions per printer?
>>> > Thanks,
>>> > --jim
>>> > --
>>> > View this message in context:
>>> > http://n2.nabble.com/p= ermission-everything-but-this-item-tp4616037p4616037.html
>>> > Sent from the Shiro User mailing list archive at Nabble.c= om.
>>> >
>>
>>
>

--000e0cd71ede61e917048046f24d--