[security-dev] Authorization constructs in PicketLink3
Anil Saldhana
Anil.Saldhana at redhat.com
Tue May 7 15:40:50 EDT 2013
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 at redhat.com>
>> >To:security-dev at 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 at redhat.com> 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 at redhat.com>
>>>>> >>>>To:security-dev at 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 at redhat.com>
>>>>>> >>>>>To:security-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/security-dev/attachments/20130507/7216f73f/attachment.html
More information about the security-dev
mailing list