restrict the number of login tries.

[Joseph Toussaint <to...@jakarta.apache.org>]

Hi i'd like to write a module that would restrict the number of times 
someone can login tomcat before their account is locked.  I realize that I 
could modify the realm that I am using - but I'd like to find a more robust 
solution that could be applied to all security realms without requiring 
users to re-compile.

Here is what I understand of the security role process

A controller class gets a list of all the Request Interceptors
If one of those interceptors is a security realm it calls the authenticate 
method
if it returns true, it breaks out of the loop - otherwise it moves on to 
the next interceptor.

Here is my thought on how to do this (although I see a problem with it)

have 1 interceptor at the top of the request interceptor list (singleton 
pattern)

have as many security realms as you want

have 1 interceptor at the end of the list (singleton pattern)


by the time I get to the last interceptor I know that all previous realms 
have failed - so I know this user has failed, I bump the counter.

the first interceptor asks the last interceptor if this user still has 
tries left - if they do return false, so the security realms will try to 
authenticate the user.

the problem comes when the user is out of 'tries'  the first interceptor 
returns false, but the controller still asks the other interceptors to 
authenticate the user.

I have 2 ideas on how to solve this problem.
	1. maybe if I set the username to null - it will flag something in the 
controller class and, so it won't ask the other realms to authenticate this 
user.
	2. throw an exception.

I'm not a big fan of runtime exceptions, so I'd prefer something along the 
lines of #1


I appreciate any suggestions, or even a new design!


thanks!


joe

Re: restrict the number of login tries.

[Bill Barker <wb...@wilshire.com>]

It's actually easier than that.  The realm can return:
BaseInterceptor.OK  -- user authenticated.
BaseInterceptor.DECLINED  -- I can't authenticate her, but maybe someone
else can
Other (my personal favorite is 403) -- user can't be authenticated and
nobody else should try.

Thus if the first interceptor returns 403, the user gets whatever is
configured for the Forbidden error page.  At a slight risk, you could also
use a currently un-assigned code and configure the error page for that to
tell the user that the maximum number of tries has been exceeded (if you
feel like being friendly to crackers).

----- Original Message -----
From: "Joseph Toussaint" <to...@jakarta.apache.org>
To: <to...@jakarta.apache.org>
Sent: Thursday, August 16, 2001 8:24 PM
Subject: restrict the number of login tries.


> Hi i'd like to write a module that would restrict the number of times
> someone can login tomcat before their account is locked.  I realize that I
> could modify the realm that I am using - but I'd like to find a more
robust
> solution that could be applied to all security realms without requiring
> users to re-compile.
>
> Here is what I understand of the security role process
>
> A controller class gets a list of all the Request Interceptors
> If one of those interceptors is a security realm it calls the authenticate
> method
> if it returns true, it breaks out of the loop - otherwise it moves on to
> the next interceptor.
>
> Here is my thought on how to do this (although I see a problem with it)
>
> have 1 interceptor at the top of the request interceptor list (singleton
> pattern)
>
> have as many security realms as you want
>
> have 1 interceptor at the end of the list (singleton pattern)
>
>
> by the time I get to the last interceptor I know that all previous realms
> have failed - so I know this user has failed, I bump the counter.
>
> the first interceptor asks the last interceptor if this user still has
> tries left - if they do return false, so the security realms will try to
> authenticate the user.
>
> the problem comes when the user is out of 'tries'  the first interceptor
> returns false, but the controller still asks the other interceptors to
> authenticate the user.
>
> I have 2 ideas on how to solve this problem.
> 1. maybe if I set the username to null - it will flag something in the
> controller class and, so it won't ask the other realms to authenticate
this
> user.
> 2. throw an exception.
>
> I'm not a big fan of runtime exceptions, so I'd prefer something along the
> lines of #1
>
>
> I appreciate any suggestions, or even a new design!
>
>
> thanks!
>
>
> joe
>
>