Re: [jsecurity-dev] JSecurityFilter URL processing

[Les Hazlewood <le...@hazlewood.com>]

I've committed pretty much all the changes to enable this last night,
but it is _not_ tested.  Please feel free to jump in and see how it
works.  I'll be doing more testing in the next few days, but I'm
interested in any feedback about the architecture and how it works.

On Wed, Jun 11, 2008 at 8:34 PM, Tim Veil <tj...@gmail.com> wrote:
> I agree.  Sounds great.
>
> Tim
>
> On Jun 11, 2008, at 7:08 PM, Jeremy Haile wrote:
>
>> Good - I agree.  Love the simplicity of Solution #1.  Allowing
>> overlapping rules also runs the risk of things like this:
>> /app/* = authc
>> ! /app/blah = anon
>>
>> Which one wins?
>>
>> Luckily with solution #1, since only one rule ever applies - this
>> situation never occurs.  The slight loss of flexibility is greatly
>> surpassed by the simplicity and intuitiveness.
>>
>> I will work on implementing solution #1 later tonight unless anyone
>> speaks out against it.  Peter? Tim?  You guys agree with that?
>>
>> Jeremy
>>
>>
>> On Wed, 11 Jun 2008 18:54:01 -0400, "Les Hazlewood" <le...@hazlewood.com>
>> said:
>>>
>>> Solution #1 is definitely my favorite and the least surprise for
>>> end-users.  It is the easiest to understand.
>>>
>>> I think overlapping rules, although nice in concept, will cause more
>>> problems then they are worth.  For example, if you introduce a new url
>>> pattern that overlaps a few others (maybe unknowingly), it could be a
>>> real pain to figure out which one of the rules or combinations thereof
>>> caused potentially unexpected behavior.  I'd prefer to ignore that
>>> possibility entirely if we could.
>>>
>>> So, if they can't overlap, they'd have to repeat, which in all
>>> honesty, I don't see as being too much of a problem.  Its not as 100%
>>> concise as it could be, but it is more self documenting and eliminates
>>> the potential for the confusing mixups described above.  So, to
>>> achieve what you gave as an example, you'd have to redefine them as
>>> follows:
>>>
>>> /app/*.gif = roles[user, imageViewer]
>>> /app/** = roles[user]
>>>
>>> I think this is the closest to the KISS principle, IMO, and I'd like
>>> to go this route unless there are any objections...
>>>
>>> On Wed, Jun 11, 2008 at 5:14 PM, Jeremy Haile <jh...@fastmail.fm> wrote:
>>>>
>>>> Said another way, "anon" is the exclusion rule whereas "authc" is the
>>>> rule
>>>> stating that authentication is specifically required.
>>>>
>>>> URLs that don't match any rules would by default allow anonymous access.
>>>>  Of
>>>> course, developers could add a catch-all rule like /** = authc
>>>>
>>>>
>>>>
>>>>
>>>> On Jun 11, 2008, at 5:11 PM, Jeremy Haile wrote:
>>>>
>>>>> Yeah, it's details like that that make me not like using Acegi.
>>>>>
>>>>> I do like the idea of being able to say /app/help=anon, but to me that
>>>>> doesn't mean I'm authenticated as an anonymous user - rather it is an
>>>>> authorization rule that states that anonymous users (i.e.
>>>>> unauthenticated
>>>>> users) are allowed to access the /app/help URL.
>>>>>
>>>>> The way I'm currently thinking about it, the
>>>>> AuthenticationWebInterceptor
>>>>> would process the "anon" rules by not requiring authentication to
>>>>> access
>>>>> those URLs.
>>>>>
>>>>> On Jun 11, 2008, at 4:54 PM, Les Hazlewood wrote:
>>>>>
>>>>>> This is so incredibly absolutely stupid:
>>>>>>
>>>>>> /**=IS_AUTHENTICATED_ANONYMOUSLY
>>>>>>
>>>>>> Authentication is the act of _verifying you are who you say you are_,
>>>>>> which has absolutely no application for _anonymous_ users.
>>>>>>
>>>>>> That just makes me cringe, sorry ;)
>>>>>>
>>>>>> On Tue, Jun 10, 2008 at 12:39 PM, Jeremy Haile <jh...@fastmail.fm>
>>>>>> wrote:
>>>>>>>
>>>>>>> By the way, just for context.  I believe the way acegi handles this
>>>>>>> is
>>>>>>> that
>>>>>>> each interceptor always runs, but the anonymous interceptor basically
>>>>>>> authenticates you as an anonymous user with an anonymous role (which
>>>>>>> you
>>>>>>> can
>>>>>>> configure)
>>>>>>>
>>>>>>> Then each URL can be mapped to require anonymous authentication,
>>>>>>> remembered
>>>>>>> authentication, or full authentication.  So exclusionary rules can
>>>>>>> work
>>>>>>> like
>>>>>>> this:
>>>>>>>
>>>>>>> /secure/admin/**=ROLE_SUPERVISOR
>>>>>>> /secure/**=IS_AUTHENTICATED_REMEMBERED
>>>>>>> /**=IS_AUTHENTICATED_ANONYMOUSLY
>>>>>>>
>>>>>>> Not sure if that's how we want to handle things in a similar way or
>>>>>>> not,
>>>>>>> or
>>>>>>> how this maps to our implementation - but just some additional info
>>>>>>> to
>>>>>>> add
>>>>>>> to the fire.
>>>>>>>
>>>>>>>
>>>>>>> On Jun 10, 2008, at 12:24 PM, Jeremy Haile wrote:
>>>>>>>
>>>>>>>> I've been integrating JSecurity into a large application of mine,
>>>>>>>> and
>>>>>>>> I'm
>>>>>>>> currently working on setting up my URL configuration with the
>>>>>>>> JSecurityFilter.  This process has led me to find a few deficiencies
>>>>>>>> in
>>>>>>>> the
>>>>>>>> current URL mechanism that I think we need to address - the question
>>>>>>>> is
>>>>>>>> how
>>>>>>>> to address it.
>>>>>>>>
>>>>>>>> First of all, let me summarize the current filter behavior:
>>>>>>>> 1) Filter is configured with a list of interceptors.
>>>>>>>> 2) Each interceptor is called for EVERY request.
>>>>>>>> 3) Each interceptor examines the list of URL rules, and if one of
>>>>>>>> the
>>>>>>>> rules matches the filter processes it.
>>>>>>>> 4) Each interceptor can return true to continue processing or false
>>>>>>>> to
>>>>>>>> stop processing completely (for example, if the user is denied
>>>>>>>> authorization)
>>>>>>>>
>>>>>>>> This behavior means that if multiple URL rules match, each of those
>>>>>>>> filters will be invoked.  In the following case, accessing /app/test
>>>>>>>> would
>>>>>>>> require the superUser permission and the admin role.  accessing
>>>>>>>> /app/blah
>>>>>>>> would require just the admin role.  (note that the first example
>>>>>>>> uses
>>>>>>>> BOTH
>>>>>>>> rules)
>>>>>>>> /app/test = perms[superUser]
>>>>>>>> /app/** = roles[admin]
>>>>>>>>
>>>>>>>> The current implementation does have a few problems though:
>>>>>>>>
>>>>>>>> Problem #1 - Multiple rules that match the same interceptor
>>>>>>>> /app/test = roles[admin1]
>>>>>>>> /app/** = perms[superUser], roles[admin2]
>>>>>>>>
>>>>>>>> You would think that this config would require both the roles admin1
>>>>>>>> and
>>>>>>>> admin2 along with the superUser permission in order to access
>>>>>>>> /app/test.
>>>>>>>> However, since each interceptor is executed only once - and the
>>>>>>>> interceptor
>>>>>>>> simply looks for a single matching path - this config only requires
>>>>>>>> admin1
>>>>>>>> and the superUser permission to access /app/test.
>>>>>>>>
>>>>>>>> It wouldn't be extremely confusing if it just required admin1.
>>>>>>>>  (user
>>>>>>>> would assume only the first matching rule applies)  But the fact
>>>>>>>> that
>>>>>>>> the
>>>>>>>> perms rule is applied and not the roles rule is extremely confusing
>>>>>>>> to
>>>>>>>> users.
>>>>>>>>
>>>>>>>>
>>>>>>>> Problem #2 - Exclusionary rules are impossible
>>>>>>>> /app/test = anon
>>>>>>>> /app/** = authc
>>>>>>>>
>>>>>>>> This config is attempting to say that /app/test allows anonymous
>>>>>>>> access
>>>>>>>> while everything else under the /app directory requires
>>>>>>>> authentication.
>>>>>>>> Since all interceptors are executed and each interceptor
>>>>>>>> independently
>>>>>>>> determines if it should run, both of these rules will be executed.
>>>>>>>>  So
>>>>>>>> the
>>>>>>>> anon interceptor has no power to prevent the authc interceptor from
>>>>>>>> running
>>>>>>>> for the /app/test URL.
>>>>>>>>
>>>>>>>> Therefore it's impossible to do exclusion-based rules, where you
>>>>>>>> want
>>>>>>>> to
>>>>>>>> say "these URLs are ok for anyone, but restrict EVERYTHING else."
>>>>>>>>  You
>>>>>>>> might
>>>>>>>> also want to use this to say "allow the 'basicUser' role to access
>>>>>>>> these
>>>>>>>> URLs but require 'advancedUser' for all other URLs.  Currently these
>>>>>>>> are
>>>>>>>> impossible (or at least very difficult) to represent in the current
>>>>>>>> implementation.
>>>>>>>>
>>>>>>>>
>>>>>>>> So, how to fix.  A couple of solutions come to mind:
>>>>>>>>
>>>>>>>> Solution #1 - First matching rule is the only one executed
>>>>>>>> In this scenario, only the first matching URL rule runs.  This means
>>>>>>>> that
>>>>>>>> problem #1 never occurs because only one rule ever applies to any
>>>>>>>> URL.
>>>>>>>> Problem #2 also never occurs because the anon interceptor matches
>>>>>>>> first, so
>>>>>>>> the authc interceptor never runs.  The problem with this solution is
>>>>>>>> that it
>>>>>>>> prevents overlapping rules that can be useful in some situations.
>>>>>>>>  For
>>>>>>>> example:
>>>>>>>> /app/** = roles[user]
>>>>>>>> /app/*.gif = roles[imageViewer]
>>>>>>>>
>>>>>>>> In this case we're trying to say that everything under /app requires
>>>>>>>> the
>>>>>>>> user role.  But in addition, any gif images require the imageViewer
>>>>>>>> rule.
>>>>>>>> With Solution #1, these types of rule sets are impossible.
>>>>>>>>
>>>>>>>>
>>>>>>>> Solution #2 - Execute interceptors for every matching rule
>>>>>>>> In this scenario, each interceptor is executed for every rule that
>>>>>>>> matches
>>>>>>>> it.  This means problem #1 wouldn't occur because the Roles
>>>>>>>> interceptor
>>>>>>>> would be executed twice, once for the admin1 rule, once for the
>>>>>>>> admin2
>>>>>>>> rule.
>>>>>>>> However, this solution doesn't really address problem #2 - there's
>>>>>>>> still no
>>>>>>>> way to do exclusionary rules that prevent other rules from
>>>>>>>> executing.
>>>>>>>>
>>>>>>>>
>>>>>>>> Solution #3 - Some combination of the above
>>>>>>>> I think the ultimate solution is some combination of the above, but
>>>>>>>> I'm
>>>>>>>> looking to this mailing list for suggestions.
>>>>>>>>
>>>>>>>> One idea (my current favorite is to only execute the first matching
>>>>>>>> rule,
>>>>>>>> but allow some rules to specify they should always run:
>>>>>>>>
>>>>>>>> /app/test = anon
>>>>>>>> /app/** = authc
>>>>>>>> ! /app/*.gif  = roles[imageViewer]
>>>>>>>>
>>>>>>>> Note the exclamation point at the beginning of the third rule.  This
>>>>>>>> indicates that the rule should always execute even if another rule
>>>>>>>> matches.
>>>>>>>>
>>>>>>>> Another idea is to have it be the opposite default - all matching
>>>>>>>> rules
>>>>>>>> execute, but they execute from top-to-bottom, and certain rules or
>>>>>>>> maybe
>>>>>>>> interceptors could indicate that processing should stop at that rule
>>>>>>>> if
>>>>>>>> it
>>>>>>>> matches.
>>>>>>>>
>>>>>>>>
>>>>>>>> What do you guys think?  What sort of rule combinations are you
>>>>>>>> currently
>>>>>>>> using?  What types of things would you like to use these rules for?
>>>>>>>> Any
>>>>>>>> other solution ideas?
>>>>>>>>
>>>>>>>>
>>>>>>>> Jeremy Haile
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>>
>>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe from this list, please visit:
>>>>>>>
>>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe from this list, please visit:
>>>>>>
>>>>>> http://xircles.codehaus.org/manage_email
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe from this list, please visit:
>>>>>
>>>>> http://xircles.codehaus.org/manage_email
>>>>>
>>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this list, please visit:
>>>>
>>>>  http://xircles.codehaus.org/manage_email
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>   http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>