<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
I need to bring this up again. Are there any impediments to
securing<br>
Timo completely using PicketLink 2.5beta4 (soon)?<br>
<div class="moz-forward-container"><br>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Subject:
</th>
<td>Re: [security-dev] Authorization constructs in
PicketLink3</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">Date: </th>
<td>Wed, 08 May 2013 08:26:54 +1000</td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">From: </th>
<td>Shane Bryzak <a class="moz-txt-link-rfc2396E" href="mailto:sbryzak@redhat.com"><sbryzak@redhat.com></a></td>
</tr>
<tr>
<th nowrap="nowrap" valign="BASELINE" align="RIGHT">To: </th>
<td><a class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a></td>
</tr>
</tbody>
</table>
<br>
<br>
<pre>+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" <a class="moz-txt-link-rfc2396E" href="mailto:Anil.Saldhana@redhat.com"><Anil.Saldhana@redhat.com></a>
>>> To: <a class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
>>> 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" <a class="moz-txt-link-rfc2396E" href="mailto:Anil.Saldhana@redhat.com"><Anil.Saldhana@redhat.com></a> > To:
>>>> <a class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a> > 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
>>>>> <a class="moz-txt-link-rfc2396E" href="mailto:Anil.Saldhana@redhat.com"><Anil.Saldhana@redhat.com></a> 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"
>>>>>>> <a class="moz-txt-link-rfc2396E" href="mailto:Anil.Saldhana@redhat.com"><Anil.Saldhana@redhat.com></a> >>>> To: <a class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
>>>>>>>>>>> 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" <a class="moz-txt-link-rfc2396E" href="mailto:Anil.Saldhana@redhat.com"><Anil.Saldhana@redhat.com></a> >>>>> To:
>>>>>>>> <a class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a> >>>>> 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
> <a class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
> <a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/security-dev">https://lists.jboss.org/mailman/listinfo/security-dev</a>
_______________________________________________
security-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/security-dev">https://lists.jboss.org/mailman/listinfo/security-dev</a></pre>
<br>
<br>
</div>
<br>
</body>
</html>