<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 22/10/15 08:30, Stian Thorgersen
wrote:<br>
</div>
<blockquote
cite="mid:CAJgngAcF-MBBDd=Z4BYo79CQauamnYO7No+GQkfLPODJnGpJPw@mail.gmail.com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 21 October 2015 at 14:21, Benjamin
Hansmann [alphaApps] <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:b.hansmann@alphaapps.de" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:b.hansmann@alphaapps.de">b.hansmann@alphaapps.de</a></a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
great to see rapid progress on keycloak and regular
releases with new<br>
features added.<br>
<br>
I am on Keycloak 1.4.0 and have two questions regarding 2
recently added<br>
features:<br>
<br>
- The service accounts introduced in 1.5.0 and the
possibility to<br>
autenticate them with certificates in 1.6.0 is a great
feature. I am<br>
asking myself if these will be excluded from the brute
force protection<br>
mechanism. I would like to use a service account in my app
when a user<br>
is not logged in (which is now just a regular account). If
this account<br>
will be subject to get locked out after a few consecutive
failed login<br>
attempts, all users will not be able to use the features
which do not<br>
require an active user session but rely on the service
account. So<br>
someone could deliberately lock the service account.<br>
</blockquote>
<div><br>
</div>
<div>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?</div>
</div>
</div>
</div>
</blockquote>
nope, the client authentication in general is not tracked with
BruteForceProtector now. Do you want me to create JIRA?<br>
<br>
Marek<br>
<blockquote
cite="mid:CAJgngAcF-MBBDd=Z4BYo79CQauamnYO7No+GQkfLPODJnGpJPw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- I was having trouble with keycloak-services<br>
(Urls.java:loginActionsBase): I have a rest web service
which also acts<br>
as a keycloak facade for registration, reset password,
resend<br>
verification email etc... From within my web service I use
the keycloak<br>
admin-client to e.g. trigger a reset-password-email or
registration. The<br>
problem was that emails sent by keycloak then contained
links referring<br>
to localhost:8080 because my web service contacts keycloak
locally onlogFailure<br>
the server. I worked around this issue by patching the
loginActionsBase<br>
methdo in Urls.java to replace hostname, scheme and port
of the returned<br>
URI. This seemed ugly to me and I am asking if the feature
"Added root<br>
URL to clients" in the just released 1.6.0 version makes
this workaround<br>
obsolete?<br>
</blockquote>
<div><br>
</div>
<div>Why not just use the theme support and modify the pages
directly in KC? Seems much simpler and better ;)</div>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Best regards,<br>
Benjamin<br>
<br>
_______________________________________________<br>
keycloak-user mailing list<br>
<a moz-do-not-send="true"
href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/keycloak-user"
rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>