[keycloak-user] Brute force protector and service accounts/Login actions URI
sthorger at redhat.com
Thu Oct 22 05:49:00 EDT 2015
On 22 October 2015 at 10:50, Marek Posolda <mposolda at redhat.com> wrote:
> On 22/10/15 08:30, Stian Thorgersen wrote:
> On 21 October 2015 at 14:21, Benjamin Hansmann [alphaApps] <
> <b.hansmann at alphaapps.de>b.hansmann at alphaapps.de> wrote:
>> great to see rapid progress on keycloak and regular releases with new
>> features added.
>> I am on Keycloak 1.4.0 and have two questions regarding 2 recently added
>> - The service accounts introduced in 1.5.0 and the possibility to
>> autenticate them with certificates in 1.6.0 is a great feature. I am
>> asking myself if these will be excluded from the brute force protection
>> mechanism. I would like to use a service account in my app when a user
>> is not logged in (which is now just a regular account). If this account
>> will be subject to get locked out after a few consecutive failed login
>> attempts, all users will not be able to use the features which do not
>> require an active user session but rely on the service account. So
>> someone could deliberately lock the service account.
> Same argument can be made for user accounts. I'm not actually sure if
> service accounts use the brute force protection atm, they should - Marek
> can you confirm?
> nope, the client authentication in general is not tracked with
> BruteForceProtector now. Do you want me to create JIRA?
>> - I was having trouble with keycloak-services
>> (Urls.java:loginActionsBase): I have a rest web service which also acts
>> as a keycloak facade for registration, reset password, resend
>> verification email etc... From within my web service I use the keycloak
>> admin-client to e.g. trigger a reset-password-email or registration. The
>> problem was that emails sent by keycloak then contained links referring
>> to localhost:8080 because my web service contacts keycloak locally
>> the server. I worked around this issue by patching the loginActionsBase
>> methdo in Urls.java to replace hostname, scheme and port of the returned
>> URI. This seemed ugly to me and I am asking if the feature "Added root
>> URL to clients" in the just released 1.6.0 version makes this workaround
> Why not just use the theme support and modify the pages directly in KC?
> Seems much simpler and better ;)
> We actually have others that have a similar issue where they contact KC
> internally on one hostname. So we may add some sort of alias mechanism or a
> fixed hostname option for KC.
>> Best regards,
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the keycloak-user