Re: SHIRO-283 design: supporting both Form & BASIC authc simultaneously

[Les Hazlewood <lh...@apache.org>]

I'm revisiting this in an effort to resolve it for 1.2, but I have
some questions:

It is not readily apparent to me why the 'permissive' flag exists (it
has been a month, forgive me).  Doesn't it basically just ignore the
authc check and allow the request to pass through no matter what,
thereby invalidating its security purpose?  If so, what is the benefit
of doing this?

At the moment with my little understanding this has the feeling of a
workaround rather than a 'correct' solution (which is sometimes ok,
but I'd prefer to have the latter in an actual release if at all
possible).

Thanks,

Les

On Mon, Aug 15, 2011 at 10:51 AM, Jared Bunting
<ja...@peachjean.com> wrote:
> On 08/15/2011 11:48 AM, Les Hazlewood wrote:
>> It might also be helpful to think about this in a general sense,
>> without being too coupled to Form + BASIC.
>>
>> I believe the problem we're trying to solve is:
>>
>> 1.  I don't care how my user is authenticated - just that they are
>> authenticated.
>> 2.  If they're not authenticated yet, I want them to be authenticated
>> via one of X, Y or Z (or more) means.
>>
>> It might be better to come up with a mechanism for this rather than
>> focusing on Form + BASIC details specifically (e.g. throw X.509 into
>> the mix or something else).
> I agree on coming up with a more general solution.  I feel like this
> problem is a subset of another problem, and perhaps related to yet another.
>
> 3. At this particular filter level, I don't care if my user is
> authenticated.
>
> (I'm using AOP to do authorization in my application code, and there's a
> decent chance that certain required permissions are assigned to the
> anonymous-user or some functionality may not even have authorization
> requirements).
>
> I'm all for a general solution, and something composition-oriented
> sounds great.  I think what I'm interested in is separating the logic of
> "authenticate" from "guarantee user is authenticated".
>
> Thanks,
> Jared

Re: SHIRO-283 design: supporting both Form & BASIC authc simultaneously

[Jared Bunting <ja...@peachjean.com>]

Well, I thought that I had replied to this, but it doesn't appear that I
did.

The difference is that, if AUTH information is provided it is accepted. 
If it is not and the application later throws an "UnauthorizedException"
then the filter will perform the challenge method.

That being said, your explanation of the contract of the
AuthenticatingFilter makes sense.  Since I'm not really sure of a better
way of solving this without significant change to the filters, I'm fine
with removing this and revisiting with composition-based filters in a
later release.

Thanks,
Jared

On 09/19/2011 08:48 PM, Les Hazlewood wrote:
> I'm revisiting this in an effort to resolve it for 1.2, but I have
> some questions:
>
> It is not readily apparent to me why the 'permissive' flag exists (it
> has been a month, forgive me).  Doesn't it basically just ignore the
> authc check and allow the request to pass through no matter what,
> thereby invalidating its security purpose?  If so, what is the benefit
> of doing this?
>
> At the moment with my little understanding this has the feeling of a
> workaround rather than a 'correct' solution (which is sometimes ok,
> but I'd prefer to have the latter in an actual release if at all
> possible).
>
> Thanks,
>
> Les
>
> On Mon, Aug 15, 2011 at 10:51 AM, Jared Bunting
> <ja...@peachjean.com> wrote:
>> On 08/15/2011 11:48 AM, Les Hazlewood wrote:
>>> It might also be helpful to think about this in a general sense,
>>> without being too coupled to Form + BASIC.
>>>
>>> I believe the problem we're trying to solve is:
>>>
>>> 1.  I don't care how my user is authenticated - just that they are
>>> authenticated.
>>> 2.  If they're not authenticated yet, I want them to be authenticated
>>> via one of X, Y or Z (or more) means.
>>>
>>> It might be better to come up with a mechanism for this rather than
>>> focusing on Form + BASIC details specifically (e.g. throw X.509 into
>>> the mix or something else).
>> I agree on coming up with a more general solution.  I feel like this
>> problem is a subset of another problem, and perhaps related to yet another.
>>
>> 3. At this particular filter level, I don't care if my user is
>> authenticated.
>>
>> (I'm using AOP to do authorization in my application code, and there's a
>> decent chance that certain required permissions are assigned to the
>> anonymous-user or some functionality may not even have authorization
>> requirements).
>>
>> I'm all for a general solution, and something composition-oriented
>> sounds great.  I think what I'm interested in is separating the logic of
>> "authenticate" from "guarantee user is authenticated".
>>
>> Thanks,
>> Jared

Re: SHIRO-283 design: supporting both Form & BASIC authc simultaneously

[Les Hazlewood <lh...@apache.org>]

Also, https://issues.apache.org/jira/browse/SHIRO-321 seems related to
this discussion as well.

On Mon, Sep 19, 2011 at 6:49 PM, Les Hazlewood <lh...@apache.org> wrote:
> If possible, it would help me greatly if we could come up with a quick
> list of 'requirements' of what we'd like to solve.  Any ideas?
>
> Thanks again,
>
> Les
>
> On Mon, Sep 19, 2011 at 6:48 PM, Les Hazlewood <lh...@apache.org> wrote:
>> I'm revisiting this in an effort to resolve it for 1.2, but I have
>> some questions:
>>
>> It is not readily apparent to me why the 'permissive' flag exists (it
>> has been a month, forgive me).  Doesn't it basically just ignore the
>> authc check and allow the request to pass through no matter what,
>> thereby invalidating its security purpose?  If so, what is the benefit
>> of doing this?
>>
>> At the moment with my little understanding this has the feeling of a
>> workaround rather than a 'correct' solution (which is sometimes ok,
>> but I'd prefer to have the latter in an actual release if at all
>> possible).
>>
>> Thanks,
>>
>> Les
>>
>> On Mon, Aug 15, 2011 at 10:51 AM, Jared Bunting
>> <ja...@peachjean.com> wrote:
>>> On 08/15/2011 11:48 AM, Les Hazlewood wrote:
>>>> It might also be helpful to think about this in a general sense,
>>>> without being too coupled to Form + BASIC.
>>>>
>>>> I believe the problem we're trying to solve is:
>>>>
>>>> 1.  I don't care how my user is authenticated - just that they are
>>>> authenticated.
>>>> 2.  If they're not authenticated yet, I want them to be authenticated
>>>> via one of X, Y or Z (or more) means.
>>>>
>>>> It might be better to come up with a mechanism for this rather than
>>>> focusing on Form + BASIC details specifically (e.g. throw X.509 into
>>>> the mix or something else).
>>> I agree on coming up with a more general solution.  I feel like this
>>> problem is a subset of another problem, and perhaps related to yet another.
>>>
>>> 3. At this particular filter level, I don't care if my user is
>>> authenticated.
>>>
>>> (I'm using AOP to do authorization in my application code, and there's a
>>> decent chance that certain required permissions are assigned to the
>>> anonymous-user or some functionality may not even have authorization
>>> requirements).
>>>
>>> I'm all for a general solution, and something composition-oriented
>>> sounds great.  I think what I'm interested in is separating the logic of
>>> "authenticate" from "guarantee user is authenticated".
>>>
>>> Thanks,
>>> Jared

Re: SHIRO-283 design: supporting both Form & BASIC authc simultaneously

[Les Hazlewood <lh...@apache.org>]

If possible, it would help me greatly if we could come up with a quick
list of 'requirements' of what we'd like to solve.  Any ideas?

Thanks again,

Les

On Mon, Sep 19, 2011 at 6:48 PM, Les Hazlewood <lh...@apache.org> wrote:
> I'm revisiting this in an effort to resolve it for 1.2, but I have
> some questions:
>
> It is not readily apparent to me why the 'permissive' flag exists (it
> has been a month, forgive me).  Doesn't it basically just ignore the
> authc check and allow the request to pass through no matter what,
> thereby invalidating its security purpose?  If so, what is the benefit
> of doing this?
>
> At the moment with my little understanding this has the feeling of a
> workaround rather than a 'correct' solution (which is sometimes ok,
> but I'd prefer to have the latter in an actual release if at all
> possible).
>
> Thanks,
>
> Les
>
> On Mon, Aug 15, 2011 at 10:51 AM, Jared Bunting
> <ja...@peachjean.com> wrote:
>> On 08/15/2011 11:48 AM, Les Hazlewood wrote:
>>> It might also be helpful to think about this in a general sense,
>>> without being too coupled to Form + BASIC.
>>>
>>> I believe the problem we're trying to solve is:
>>>
>>> 1.  I don't care how my user is authenticated - just that they are
>>> authenticated.
>>> 2.  If they're not authenticated yet, I want them to be authenticated
>>> via one of X, Y or Z (or more) means.
>>>
>>> It might be better to come up with a mechanism for this rather than
>>> focusing on Form + BASIC details specifically (e.g. throw X.509 into
>>> the mix or something else).
>> I agree on coming up with a more general solution.  I feel like this
>> problem is a subset of another problem, and perhaps related to yet another.
>>
>> 3. At this particular filter level, I don't care if my user is
>> authenticated.
>>
>> (I'm using AOP to do authorization in my application code, and there's a
>> decent chance that certain required permissions are assigned to the
>> anonymous-user or some functionality may not even have authorization
>> requirements).
>>
>> I'm all for a general solution, and something composition-oriented
>> sounds great.  I think what I'm interested in is separating the logic of
>> "authenticate" from "guarantee user is authenticated".
>>
>> Thanks,
>> Jared

Re: SHIRO-283 design: supporting both Form & BASIC authc simultaneously

[Jared Bunting <ja...@peachjean.com>]

Sorry for the slow response.  I think we can clear this up quickly though.

The intent of the 'permissive' flag is to provide users with an
authentication mechanism while not requiring authentication.  The flag does
indeed ignore the authc check - this is essentially delegated to another
section of the application.  Maybe if I illustrate a particular use case for
this, it will make it more clear.  I have a server application that uses
http basic auth and has a pluggable "module" system.  The modules are
dynamically loaded at runtime, each to their own URL.  Each of these modules
defines its own security requirements via an AOP annotation.  For some, this
means requiring a specific permission.  But others are intended to be open
to anyone - even someone not logged in. Since modifying the shiro filter
mapping to only point the authcBasic filter at certain modules would
severely limit the flexibility of the module mechanism, the permissive flag
makes this possible.  Basically, with permissive set, the filter will log in
any user who provides login info.  All users will be forwarded to the
application.  Then, when the AOP authorization needs to do a permission
check, it does it.  If the user is not logged in, this permission check will
throw an UnauthenticatedException.  The filter (authc or authcBasic) will
catch this exception and then notify the user of the required authentication
(redirect to login page or 401 response, respectively).  Basically, this
allows the user to truly separate the authentication mechanism from the
decision of whether or not to require users to be authenticated.

Now, all that being said, after some thinking I'm not convinced that the
permissive flag is the right way to go about this.  I suspect that this
functionality could be much better provided with SHIRO-224 (which should
probably also resolve SHIRO-321).  I had hoped that this could solve
SHIRO-283, but it's really only a partial fix.  Again, SHIRO-224 could
likely open up simple avenues to solve SHIRO-283.

So all that being said, I suggest that we remove this functionality for 1.2
and talk about the use cases more with SHIRO-224.

Thanks,
Jared

On Mon, Sep 19, 2011 at 8:48 PM, Les Hazlewood <lh...@apache.org>wrote:

> I'm revisiting this in an effort to resolve it for 1.2, but I have
> some questions:
>
> It is not readily apparent to me why the 'permissive' flag exists (it
> has been a month, forgive me).  Doesn't it basically just ignore the
> authc check and allow the request to pass through no matter what,
> thereby invalidating its security purpose?  If so, what is the benefit
> of doing this?
>
> At the moment with my little understanding this has the feeling of a
> workaround rather than a 'correct' solution (which is sometimes ok,
> but I'd prefer to have the latter in an actual release if at all
> possible).
>
> Thanks,
>
> Les
>
> On Mon, Aug 15, 2011 at 10:51 AM, Jared Bunting
> <ja...@peachjean.com> wrote:
> > On 08/15/2011 11:48 AM, Les Hazlewood wrote:
> >> It might also be helpful to think about this in a general sense,
> >> without being too coupled to Form + BASIC.
> >>
> >> I believe the problem we're trying to solve is:
> >>
> >> 1.  I don't care how my user is authenticated - just that they are
> >> authenticated.
> >> 2.  If they're not authenticated yet, I want them to be authenticated
> >> via one of X, Y or Z (or more) means.
> >>
> >> It might be better to come up with a mechanism for this rather than
> >> focusing on Form + BASIC details specifically (e.g. throw X.509 into
> >> the mix or something else).
> > I agree on coming up with a more general solution.  I feel like this
> > problem is a subset of another problem, and perhaps related to yet
> another.
> >
> > 3. At this particular filter level, I don't care if my user is
> > authenticated.
> >
> > (I'm using AOP to do authorization in my application code, and there's a
> > decent chance that certain required permissions are assigned to the
> > anonymous-user or some functionality may not even have authorization
> > requirements).
> >
> > I'm all for a general solution, and something composition-oriented
> > sounds great.  I think what I'm interested in is separating the logic of
> > "authenticate" from "guarantee user is authenticated".
> >
> > Thanks,
> > Jared
>