On 22/10/15 08:30, Stian Thorgersen wrote:
nope, the client authentication in general is not tracked with BruteForceProtector now. Do you want me to create JIRA?
On 21 October 2015 at 14:21, Benjamin Hansmann [alphaApps] <b.hansmann@alphaapps.de> wrote:
Hi,
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
features:
- 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?
Marek
- 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 onlogFailure
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
obsolete?
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,
Benjamin
_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user