<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I've started moving the permissions
classes back into the base module however haven't added any tests
for them yet, they are planned for beta4 though so there shouldn't
be any impediments as far as I know.<br>
<br>
On 23/05/13 00:04, Anil Saldhana wrote:<br>
</div>
<blockquote cite="mid:519CD05B.4010305@redhat.com" type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
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 align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject:
</th>
<td>Re: [security-dev] Authorization constructs in
PicketLink3</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date:
</th>
<td>Wed, 08 May 2013 08:26:54 +1000</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From:
</th>
<td>Shane Bryzak <a moz-do-not-send="true"
class="moz-txt-link-rfc2396E"
href="mailto:sbryzak@redhat.com"><sbryzak@redhat.com></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
<td><a moz-do-not-send="true"
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 moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:Anil.Saldhana@redhat.com"><Anil.Saldhana@redhat.com></a>
>>> To: <a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:Anil.Saldhana@redhat.com"><Anil.Saldhana@redhat.com></a> > To:
>>>> <a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:Anil.Saldhana@redhat.com"><Anil.Saldhana@redhat.com></a> >>>> To: <a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:Anil.Saldhana@redhat.com"><Anil.Saldhana@redhat.com></a> >>>>> To:
>>>>>>>> <a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
> <a moz-do-not-send="true" 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 moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:security-dev@lists.jboss.org">security-dev@lists.jboss.org</a>
<a moz-do-not-send="true" 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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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>
</blockquote>
<br>
</body>
</html>