<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 22 October 2015 at 10:50, Marek Posolda <span dir="ltr">&lt;<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class="">
    <div>On 22/10/15 08:30, Stian Thorgersen
      wrote:<br>
    </div>
    <blockquote 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">&lt;<a href="mailto:b.hansmann@alphaapps.de" target="_blank"></a><a href="mailto:b.hansmann@alphaapps.de" target="_blank">b.hansmann@alphaapps.de</a>&gt;</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&#39;m not
              actually sure if service accounts use the brute force
              protection atm, they should - Marek can you confirm?</div>
          </div>
        </div>
      </div>
    </blockquote></span>
    nope, the client authentication in general is not tracked with
    BruteForceProtector now. Do you want me to create JIRA?<br></div></blockquote><div><br></div><div>Yes, please</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
    <br>
    Marek<br>
    <blockquote 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"><span class="">
              <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></span>
              to localhost:8080 because my web service contacts keycloak
              locally onlogFailure<span class=""><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
              &quot;Added root<br>
              URL to clients&quot; in the just released 1.6.0 version makes
              this workaround<br>
              obsolete?<br>
            </span></blockquote><span class="">
            <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 href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a><br>
              <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
            </blockquote>
          </span></div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div></div>