Hi Ashima, Finally I get chance to get back to my CAS project, and I tested your ThrottledSubmissionByIpAddrUsernameHandlerInterceptorAdapter, it works very very nicely. I really think you could send the code to Scott Battaglia or someone in charge so that they could integrate this interceptor in the next release of CAS server. I am sure lots of people could make use of it.
To log logins in a database table, I used the following impmementation: http://www.ja-sig.org/wiki/display/CASUM/Auditing+and+Statistics+Via+Inspektr. In this implementation, the COM_AUDIT_TRAIL keeps track of every single CAS action, inclduing AUTHENTICATION, VALIDATEION, Creating Ticket-Granting-Ticket, creating Service-Ticket, etc. I create a trigger for this table, which will log only login success/failure with user name, remote IP, etc to antoher table. I am curious how you implement this component in your project, do you mind sharing that? In your implementation do you only log failed login to the database, or do you log both fail and success login? Thanks a have a good day, Xuejin Ashigl wrote: > > Hi > > I implemented this approach for our CAS implementation. I am attaching the > code file here. Let me know if you have any questions. > > Addition in cas-servlet.xml :- > > <bean id="handlerMappingB" > class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> > <property > name="mappings"> > <props> > <prop > key="/login">loginController</prop> > </props> > </property> > <property > name="interceptors"> > <list> > <ref > bean="tamuThrottledSubmissionHandlerInterceptorAdapter" > /> > <ref bean="localeChangeInterceptor" /> > </list> > </property> > </bean> > > <bean > id="tamuThrottledSubmissionHandlerInterceptorAdapter" > > class="org.jasig.cas.web.support.TamuThrottledSubmissionHandlerInterceptorAdapter"> > <property name="failureThreshhold" value="3" /> > <property name="failureTimeout" value="60"/> > <property name="blockTimeout" value="5"/> > </bean> > > > > We have now implemented this approach using a database to store failed > attempts, let me know if you need to refer that approach too. > > Thanks > Ashima > > On Wed, Jul 29, 2009 at 11:44 AM, Xuejin Ruan <[email protected]> > wrote: > >> >> Hi Andrew, >> >> Thanks so much for the reply. Yes, I did look at >> ThrottledSubmissionByUpAddressHandlerInterceptorAdapter, however, this >> approach has a potential problem that it will shut out an entire IP >> address >> with potentially many users behind it. And I saw a proporal for an >> enhancement to this approach, something like >> "ThrottledSubmissionByIpAddressAndNetidHandlerInterceptorAdaptor". The >> proposal was brougth up in March 2009. Anybody has any ideas whether it >> is >> implemented already? >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> This Jira issue documents a proposed enhancement for CAS3. >> >> CAS has existing support for failed login attempt throttling via the >> ThrottledSubmissionByIpAddressHandlerInterceptorAdapter.java >> >> Sometimes it is desirable to throttle not only by IP address but by the >> (IP >> Address, NetId) tuple. This avoids shutting out an entire NATed IP >> address >> with potentially many users behind it (e.g., some campus wireless >> networks >> are NATed) on the basis of one user behind that NAT triggering the >> throttling behavior. At the cost of not throttling a few failed login >> attempts per user across many users, throttling based on the tuple (IP >> Address, NetID) will still throttle dictionary attacks against a >> particular >> user. >> >> The enhancement here proposed is to add a >> ThrottledSubmissionByIpAddressAndNetidHandlerInterceptorAdaptor >> >> The interceptor login preemptive failure behavior should be activated by >> a >> sufficient number of failed login attempts by a (NetId, IP Address) tuple >> during sufficiently short interval of time, with the threshold quantity >> and >> duration (or rate of "forgetting" failed attempts) configurable. >> >> When the preemptive login blocking behavior is activated, it should block >> attempts by the triggering tuple for a configurable duration of time. It >> should >> >> The interceptor should store its log of failed login attempts into an >> RDBMS >> (presumably via JPA, support for MySQL is desired) so that failed login >> attempts can be tracked and responded to across clustered CAS instances. >> >> The interceptor should log the IP address, timestamp, and NetId for both >> the >> triggering of the preemptive failure and for all login attempts during >> preemptive failure state. >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> >> Xuejin, >> >> You should look into the >> ThrottledSubmissionByUpAddressHandlerInterceptorAdapter as a potential >> solution if not a basis for a customized solution to your problems. >> >> HTH, >> A- >> >> REFERENCES: >> >> >> https://www.ja-sig.org/svn/cas3/tags/cas-3-3-3-final/cas-server-core/src/mai >> >> n/java/org/jasig/cas/web/support/ThrottledSubmissionByIpAddressHandlerInterc<https://www.ja-sig.org/svn/cas3/tags/cas-3-3-3-final/cas-server-core/src/mai%0An/java/org/jasig/cas/web/support/ThrottledSubmissionByIpAddressHandlerInterc> >> eptorAdapter.java >> >> >> On 7/29/09 1:20 PM, "Xuejin Ruan" <[email protected]> wrote: >> >> > >> > Hi Ole, >> > >> > I need to implement something exactly like what you described below. >> Have >> > you created such a filter already? >> > >> > Thanks, >> > >> > Xuejin >> > >> > >> > ole ersoy wrote: >> >> >> >> I've been toying with the idea of making a filter as well. I think it >> >> could be done by creating a CAS ServletContextLister that creates a >> data >> >> structure for storing: >> >> >> >> - user >> >> - number of attempts >> >> - time of last attempt >> >> >> >> The filter then grabs this data structure from the CAS ServletContext >> and >> >> uses it like this: >> >> >> >> If a user has made an attempt to login within say the last 15 minutes, >> >> the >> >> number of attempts is incremented, given that it's not already at the >> >> max. >> >> If it's at the max then the user gets a message saying that they have >> to >> >> wait X minutes before trying to login again. If the user has made a >> >> login >> >> attempt before, but the attempt was made more than 15 minutes ago, >> then >> >> the filter resets the number of attempts to 1, and the cycle starts >> over >> >> again. >> >> >> >> If this were made as a component to CAS it should probably be an >> Action >> >> that is invoked before the initialFlowSetup. So if user is allowed to >> >> attempt to login, then the next step is the initialFlowSetup, >> otherwise >> >> it's the too many attempts view-state. >> >> >> >> Cheers, >> >> - Ole >> >> >> >> -- >> View this message in context: >> http://www.nabble.com/ThrottledSubmissionByIpAddressAndNetidHandlerInterceptorAdaptor----tp24725254p24725254.html >> Sent from the CAS Users mailing list archive at Nabble.com. >> >> >> -- >> You are currently subscribed to [email protected] as: >> [email protected] >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-user >> > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- View this message in context: http://www.nabble.com/ThrottledSubmissionByIpAddressAndNetidHandlerInterceptorAdaptor----tp24725254p24850342.html Sent from the CAS Users mailing list archive at Nabble.com. -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
