Re: [keycloak-user] Brute force protector and service accounts/Login actions URI

On 21 October 2015 at 14:21, Benjamin Hansmann [alphaApps] <b.hansmann(a)alphaapps.de <mailto: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?

- 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(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user