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" <Anil.Saldhana(a)redhat.com&gt; To: 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.

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" <Anil.Saldhana(a)redhat.com&gt; To: security-dev(a)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" <Anil.Saldhana(a)redhat.com&gt; > To: 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. >

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 <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" <Anil.Saldhana(a)redhat.com&gt; >> To: security-dev(a)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" <Anil.Saldhana(a)redhat.com&gt; >>> To: 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. >>> >>>

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" <Anil.Saldhana(a)redhat.com&gt; To: 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 <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" <Anil.Saldhana(a)redhat.com&gt; >>> To: security-dev(a)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" <Anil.Saldhana(a)redhat.com&gt; >>>> To: 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. >>>> >>>> >>>>

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:security-dev@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&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&quot;&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:security-dev@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 security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

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" <Anil.Saldhana(a)redhat.com&gt; To: security-dev(a)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" <Anil.Saldhana(a)redhat.com&gt; > To: 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 <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" <Anil.Saldhana(a)redhat.com&gt; >>>> To: security-dev(a)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" <Anil.Saldhana(a)redhat.com&gt; >>>>> To: 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. >>>>> >>>>> >>>>> >>>>>

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" <Anil.Saldhana(a)redhat.com&gt; >> To: security-dev(a)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" <Anil.Saldhana(a)redhat.com&gt; > To: >>> 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 >>>> <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" >>>>>> <Anil.Saldhana(a)redhat.com&gt; >>>> To: security-dev(a)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" <Anil.Saldhana(a)redhat.com&gt; >>>>> To: >>>>>>> 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 security-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/security-dev

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