[prev in list] [next in list] [prev in thread] [next in thread]
List: keycloak-user
Subject: [keycloak-user] Brut force attack questions
From: alexander.chriztopher () gmail ! com (Alexander Chriztopher)
Date: 2014-11-26 13:17:33
Message-ID: CAJfT+OpuezZg8SF8PuT6tQ+WpaQpMGbS2iCUeEtx61s1K_Dc0g () mail ! gmail ! com
[Download RAW message or body]
thank you for this ! i'll have a look at infinispan ..
On Wed, Nov 26, 2014 at 12:01 PM, Stian Thorgersen <stian at redhat.com> wrote:
>
>
> ----- Original Message -----
> > From: "Alexander Chriztopher" <alexander.chriztopher at gmail.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: "Bill Burke" <bburke at redhat.com>, keycloak-user at lists.jboss.org
> > Sent: Wednesday, 26 November, 2014 11:46:21 AM
> > Subject: Re: [keycloak-user] Brut force attack questions
> >
> > i think we will go for Infinispan or jpa for roadmap reasons !
> >
> > how would we access the infinispan data ?
>
> You'll need to use 1.1.0.Beta1 as it's not available in 1.0.x. Have a look
> at
> http://docs.jboss.org/keycloak/docs/1.1.0.Beta1/userguide/html/clustering.html#d4e1662
>
> You can inject the cache into your own application with:
>
> @Resource(lookup="java:jboss/infinispan/Keycloak")
> private CacheContainer container;
>
> You'll want to remove/change entries in the loginFailures cache. Look at
> the source for model/sessions-infinispan for more info on how the
> Infinispan userSession provider works.
>
> Have a look at
> www.mastertheboss.com/jboss-frameworks/infinispan/develop-a-clustered-application-with-infinispan-data-grid
> for more info on using the Infinispan subsystem from your app.
>
> >
> > are there any documents on this integration aspect within keycloak ?
>
> What integration aspect are you referring to? The work around proposed
> with accessing JPA or Infinispan directly is not recommended so won't be
> documented.
>
> >
> > On Wed, Nov 26, 2014 at 11:02 AM, Stian Thorgersen <stian at redhat.com>
> wrote:
> >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Alexander Chriztopher" <alexander.chriztopher at gmail.com>
> > > > To: "Stian Thorgersen" <stian at redhat.com>
> > > > Cc: "Bill Burke" <bburke at redhat.com>, keycloak-user at lists.jboss.org
> > > > Sent: Wednesday, 26 November, 2014 10:51:11 AM
> > > > Subject: Re: [keycloak-user] Brut force attack questions
> > > >
> > > > nice !
> > > >
> > > > is there a way to play with this via rest -regardless to wether am
> jpa,
> > > > infinispan or in-memory ?
> > >
> > > Afraid not, that's what we'll need to add. Not sure when we get time
> > > though. If you're up for it we would be more than happy to accept a
> > > contribution, I can give you some pointers on how to do it.
> Alternatively,
> > > you can create your own app that uses JAX-RS and either JPA or the
> > > Infinispan subsystem to remove login-failure entries.
> > >
> > > >
> > > > On Wed, Nov 26, 2014 at 10:39 AM, Stian Thorgersen <stian at redhat.com
> >
> > > wrote:
> > > >
> > > > > By default user sessions (and login failures) are stored in-memory
> not
> > > in
> > > > > the database. Unless you specify JPA for the userSession provider
> those
> > > > > tables will stay empty.
> > > > >
> > > > > You could either do what you're trying to do, which should work if
> you
> > > use
> > > > > the jpa userSession provider. The other if you're worried about the
> > > > > performance of storing user sessions in the db is to use the
> Infinispan
> > > > > provider, then you can manually delete login failures from the
> > > userSession
> > > > > cache from another application.
> > > > >
> > > > > We should add a mechanism to both view and remove login-failure
> > > entries to
> > > > > the admin console though.
> > > > >
> > > > > ----- Original Message -----
> > > > > > From: "Alexander Chriztopher" <alexander.chriztopher at gmail.com>
> > > > > > To: "Bill Burke" <bburke at redhat.com>,
> keycloak-user at lists.jboss.org
> > > > > > Sent: Wednesday, 26 November, 2014 9:45:42 AM
> > > > > > Subject: Re: [keycloak-user] Brut force attack questions
> > > > > >
> > > > > > Am to find a workaround in order to be able to unlock a user
> > > account. So
> > > > > far
> > > > > > i have tried to disable then enable the user account but this
> does
> > > not do
> > > > > > the trick apparently.
> > > > > >
> > > > > > I have also tried to tweek the database but it looks like the
> lock
> > > > > > information is not stored in the db even though there is the
> table :
> > > > > > USERNAME_LOGIN_FAILURE. Is it normal that this table stays empty
> > > even on
> > > > > > login failures ?
> > > > > >
> > > > > > Do you think of any other good workaround ?
> > > > > >
> > > > > >
> > > > > > On Tue, Nov 25, 2014 at 11:03 PM, Alexander Chriztopher <
> > > > > > alexander.chriztopher at gmail.com > wrote:
> > > > > >
> > > > > >
> > > > > > Nice ! Again, thank you.
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On 25 Nov 2014, at 21:39, Bill Burke < bburke at redhat.com >
> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > On 11/25/2014 3:27 PM, Alexander Chriztopher wrote:
> > > > > > > > Hi Bill and thanks.
> > > > > > > >
> > > > > > > > Do you think we will be able to have this within a short
> period of
> > > > > time
> > > > > > > > (4-6 weeks) or is it going to be planned for the long run ?
> > > > > > >
> > > > > > > Not sure on the priority of this. We have face to face
> meetings in
> > > a
> > > > > couple
> > > > > > > of weeks to discuss priority, then of course, its christmas
> > > vacation.
> > > > > > >
> > > > > > > > When is the value of max wait used as there is already a wait
> > > > > increment
> > > > > > > > out there ?
> > > > > > >
> > > > > > > Correct. It will increase the wait after each failure until the
> > > max is
> > > > > hit.
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > On 25 Nov 2014, at 20:05, Bill Burke < bburke at redhat.com >
> > > wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > On 11/25/2014 12:32 PM, Alexander Chriztopher wrote:
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I have a some question with regards to Brut Force Attack
> > > Protection
> > > > > >
> > > > > > > > > >
> > > > > > > > > > # 1 / When brut force attack protection is enabled is there
> a
> > > way to
> > > > > > > > > > know when a user account is locked ? I am thinking about the
> > > admin
> > > > > > > > > > console.
> > > > > > > > > >
> > > > > > > > > > # 2 / When a user account is locked is there a way to
> unlock it
> > > > > from the
> > > > > > > > > > admin console ?
> > > > > > > > >
> > > > > > > > > Unfortunately no for the above. I'll log a jira.
> > > > > > > > >
> > > > > > > > > > # 3 / What is the difference between wait increment (When
> > > failure
> > > > > > > > > > threshold has been met, how much time should the user be
> locked
> > > > > out?)
> > > > > > > > > > and max wait (Max time a user will be locked out.).
> > > > > > > > >
> > > > > > > > > correct on both.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Bill Burke
> > > > > > > > > JBoss, a division of Red Hat
> > > > > > > > > http://bill.burkecentral.com
> > > > > > > > > _______________________________________________
> > > > > > > > > keycloak-user mailing list
> > > > > > > > > keycloak-user at lists.jboss.org
> > > > > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > > > > >
> > > > > > > --
> > > > > > > Bill Burke
> > > > > > > JBoss, a division of Red Hat
> > > > > > > http://bill.burkecentral.com
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > keycloak-user mailing list
> > > > > > keycloak-user at lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-user
> > > > >
> > > >
> > >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20141126/dde80502/attachment.html \
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic