shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject Re: SHIRO-283 design: supporting both Form & BASIC authc simultaneously
Date Tue, 20 Sep 2011 01:51:23 GMT
Also, seems related to
this discussion as well.

On Mon, Sep 19, 2011 at 6:49 PM, Les Hazlewood <> 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 <> 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
>> <> 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

View raw message