Re: [security-dev] Authorization constructs in PicketLink2.5

I need to bring this up again. Are there any impediments to securing Timo completely using PicketLink 2.5beta4 (soon)? -------- Original Message -------- Subject: Re: [security-dev] Authorization constructs in PicketLink3 Date: Wed, 08 May 2013 08:26:54 +1000 From: Shane Bryzak <sbryzak(a)redhat.com&gt; To: security-dev(a)lists.jboss.org +1, and we already support this pluggability via the permission resolver API. On 08/05/13 08:23, Anil Saldhana wrote: > Also I feel we should provide pluggable means for: > a) IDM based permission model (Shane) > b) Drools based Rules Open Ended Authorization > c) XACML based Open Ended Authorization (Anil) > > > On 05/07/2013 04:30 PM, Anil Saldhana wrote: >> I am supportive of your ideas, Pedro. >> >> Unlike authentication, we need to remember that authorization is >> pretty domain specific. There is no magic bullet for >> rules/permissions. Ideally, as discussed before we should provide the >> opportunity to plug in custom authorization schemes. >> >> On 05/07/2013 03:12 PM, Pedro Igor Silva wrote: >>> As I have replied before, maybe the same arguments used to put the >>> DIGEST/BASIC authc filter into picketlink-api are also valid for the >>> this filter. >>> >>> We also need to think how the configuration would be, because we need >>> to provide to the filter the URI patterns vs Roles mapping. >>> >>> As @pmuir said, the web.xml init-params should be avoided. As an >>> alternative, we can: >>> >>> - Provide a class like javax.ws.rs.core.Application where users >>> can override some methods to provide additional security config (we >>> can use that not only for authorization) >>> - Use a @Producer method to return a specific instance with the >>> authz configuration. >>> - Use a @Qualifier (or only some interface) in order to be able >>> to inject a specific bean that implements an interface with some >>> methods that can be used to obtain the configuration. >>> >>> Makes sense ? >>> >>> ----- Original Message ----- >>> From: "Anil Saldhana&quot;&lt;Anil.Saldhana(a)redhat.com&gt; >>> To:security-dev@lists.jboss.org >>> Sent: Tuesday, May 7, 2013 4:40:50 PM >>> Subject: Re: [security-dev] Authorization constructs in PicketLink3 >>> >>> Any objections to adding the access control filters to the core module? >>> >>> On 05/02/2013 11:38 AM, Anil Saldhana wrote: >>> >>> >>> >>> That is fine. Timo should be secured with PicketLink Core alone. Right >>> now, authz classes are the missing bits. >>> >>> On 05/02/2013 10:56 AM, Pedro Igor Silva wrote: >>> >>> >>> >>>> I remember Shane saying that he is going to take a look at the >>>> permissions api, mainly after the latest changes to the idm/core >>>> apis. > > I can start looking at that too, if necessary. Maybe >>>> providing some test cases to see the gaps (also provide some tests >>>> for the authentication stuff). > > ----- Original Message ----- > >>>> From: "Anil Saldhana&quot;&lt;Anil.Saldhana(a)redhat.com&gt; > To: &gt;&gt;&gt;&gt;security-dev(a)lists.jboss.org > Sent: Thursday, May 2, 2013 12:31:26 >>>> PM > Subject: Re: [security-dev] Authorization constructs in >>>> PicketLink3 > > Right Pete - I do mention in the thread. I was >>>> referring to users > wanting alternative authorization mechanisms >>>> such as > that driven by Drools (as in Seam2) and maybe XACML. :) >>>> Ideally, the > default authz mechanism by the rbac filter > should >>>> be the permissions module. > > On 05/02/2013 10:24 AM, Pete Muir wrote: >>> >>>>> Isn't this what the permissions module is for (API/SPI for >>>>> authorisation)? I know it's not finished, but I think we have time >>>>> to do that for 3.0... >> >> We then add things like the RBAC filter >>>>> delegating to it. >> >> On 2 May 2013, at 16:21, Anil Saldhana &gt;&gt;&gt;&gt;&gt;&lt;Anil.Saldhana(a)redhat.com&gt; wrote: >> >>> >>>>>> That is what I meant by pluggable. But we need to be aware of >>> >>>>>> dependencies getting pulled into core. We >>> do not want a >>>>>> dependency on drools, for example, to use core. If users >>> want >>>>>> some particular authz stuff, >>> they should be able to pull in >>>>>> those dependencies. >>> >>> I do not know yet how to get that >>>>>> done. ;) >>> >>> On 05/02/2013 09:54 AM, Pedro Igor Silva wrote: >>> >>>>>>> Maybe something we started with PicketBox, using Drools for >>>>>>> rule-based authz, pluggable authz managers, etc. >>>> >>>> JBoss >>>>>>> Seam 2 also supports Drools for authorization .... >>>> >>>> >>>>>>> ----- Original Message ----- >>>> From: "Anil Saldhana" &gt;&gt;&gt;&gt;&gt;&gt;&gt;&lt;Anil.Saldhana(a)redhat.com&gt; >>>> To:security-dev@lists.jboss.org >>>>>>>>>>> Sent: Thursday, May 2, 2013 11:38:40 AM >>>> Subject: Re: >>>>>>> [security-dev] Authorization constructs in PicketLink3 >>>> >>>> >>>>>>> We have to remember the permission model work using IDM. >>>> >>>>>>>>>>> I wonder if this filter can use pluggable authorization >>>>>>> mechanisms, then >>>> maybe the perfect start. >>>> >>>> On >>>>>>> 05/02/2013 09:36 AM, Pedro Igor Silva wrote: >>> >>>>>>>> I was looking at the >>>>>>>> org.picketlink.authentication.web.AuthenticationFilter. This >>>>>>>> class resides on core-api and we did it given some input from AG >>>>>>>> for DIGEST and BASIC authentication. >>>>> >>>>> Wondering if >>>>>>>> the authz filter we did for TIMO does not fit in the same case. >>>>>>>>>>>>>>>>>> ----- Original Message ----- >>>>> From: "Anil >>>>>>>> Saldhana&quot;&lt;Anil.Saldhana(a)redhat.com&gt; >>>>> To: &gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;security-dev(a)lists.jboss.org >>>>> Sent: Tuesday, April 30, 2013 >>>>>>>> 11:42:25 AM >>>>> Subject: [security-dev] Authorization >>>>>>>> constructs in PicketLink3 >>>>> >>>>> Shane/Pedro - we should >>>>>>>> start discussing the constructs for >>>>> authorization in PL3. >>>>>>>> We have a few options on the table. We need to >>>>> figure out >>>>>>>> what we need such that for PL3 users, we have some options. >>>>>>>>>>>>> Lets use this thread to figure out the various >>>>>>>> options/strategies. >>>>> >>>>> >>>>> >>>>>>>> > _______________________________________________ > security-dev mailing list &gt;security-dev(a)lists.jboss.org >https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev _______________________________________________ security-dev mailing list security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev