<div dir="ltr"><div><div><div><div><div><div>Marek, you 're a life saviour!<br><br></div>The concept worked perfect. <br><br></div>Btw, digging into BasicAuthRequestAuthenticator i noticed that whenever authenticate() is called, a request to the keycloak auth server is made to retrieve a token using username/password pair. So, it seems that in order to authenticate ANY request with Basic authentication credentials auth server need to be contacted. <br><br></div><div>Is my assumption correct ?<br></div><div><br></div>If that's the case it seems that the 'enable-basic-auth' lays a heavy burden on the auth server with this per-request operation. <br><br></div>It's of no value to me since i handle Basic authentication locally with a custom mechanism. I'm just asking for the record.<br><br><br></div>Best regards<br><br></div>Orestis<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 16, 2015 at 8:02 PM, Marek Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></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 16/09/15 16:38, Orestis Tsakiridis
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>Thanks Marek. <br>
<br>
Yes, you got the usecase right. <br>
<span style="background-color:rgb(255,255,255)"><br>
</span></div>
<span style="background-color:rgb(255,255,255)">Two
questions come to my mind if i follow this manual
approach:<br>
<br>
</span></div>
<span style="background-color:rgb(255,255,255)">1. Will this
take into account a KeycloakConfigResolver that's in place
and the deployment it creates ?
RSATokenVerifier.verifyToken() seems to get all info it
needs in the parameters so i guess not.<br>
</span></div>
</div>
</div>
</blockquote></span>
nope, it won't. This approach is about ignoring the official
adapter, which is triggered by security constraints from web.xml and
works at servlet layer. So in your case, request will be always
passed through servlet layer to REST endpoint when you need to do
programmatic authentication by yourself.<br>
<br>
So you may also need to read the keycloak.json file manually and use
KeycloakDeploymentBuilder.build to read KeycloakDeployment and read
publicKey and realmInfoUrl from there, so you can do
RSATokenVerifier.verifyToken by yourself.<span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div><span style="background-color:rgb(255,255,255)">2. Are
there any caches involved that won't be taken into account ?<br>
</span></div>
</div>
</blockquote></span>
Not sure what you mean. I am not aware of any caches.<span class=""><br>
<blockquote type="cite">
<div dir="ltr">3. What happens with 'enable-basic-auth' adapter
option? I suppose it needs further manual operation. This case
is probably handles by my custom auth so that doesn't seem like
a big problem.<span style="background-color:rgb(255,255,255)"><br>
</span></div>
</blockquote></span>
It will be ignored and you will again need to do Basic
Authentication by yourself if you want to support in addition to
Bearer authentication. See BasicAuthRequestAuthenticator for
inspiration. <br><span class="HOEnZb"><font color="#888888">
<br>
Marek</font></span><div><div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div><span style="background-color:rgb(228,228,255)"><span style="background-color:rgb(255,255,255)"><br>
</span><br>
</span></div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Sep 16, 2015 at 3:45 PM, Marek
Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></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">
<div>I though that's why you want programmatic access
because you want to have complete control? In that case
you can remove all security constraints from web.xml and
at your REST endpoints you would do the
authentication/authorization exactly how you want. So at
the beginning of REST endpoint you will do something
like:<br>
<br>
if (request.containsHeader("Authorization: Bearer")) {<br>
do-keycloak-authentication-with-keycloak-access-token();<br>
} else {<br>
do-legacy-authentication-or-whatever-based-on-yourAPI-keys-stuff();<br>
} <br>
<br>
Or maybe I don't understand the usecase?<span><font color="#888888"><br>
<br>
Marek</font></span>
<div>
<div><br>
<br>
On 16/09/15 11:36, Orestis Tsakiridis wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>Hi Marek,<br>
<span style="background-color:rgb(255,255,255)"><span style="color:rgb(0,0,0)"><br>
</span></span></div>
<span style="background-color:rgb(255,255,255)"><span style="color:rgb(0,0,0)">Yes, i'm talking
about securing REST endpoints. I saw the
BearerTokenRequestAuthenticator code.<br>
<br>
The problem is how to conditionally
authenticate requests using a custom
authentication method that does not rely on
keycloak users, roles, clients etc. Would a
custom MyCustomRequestAuthenticator do the
job? Are there any examples on that?
Ideally, an authenticator running inside the
adapter that would compare against values in
the application database wound to the job. <br>
<br>
</span></span></div>
<span style="background-color:rgb(228,228,255)"><span style="background-color:rgb(255,255,255)"><span style="color:rgb(0,0,0)">The idea is to be
compatible with an old security scheme that
relies on API Keys stored in the application
database. So i imagined some sort of dual
authentication for the REST endpoints.<br>
</span></span><br>
<br>
</span>
<div>
<div><br>
<br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Sep 16, 2015 at
11:35 AM, Marek Posolda <span dir="ltr"><<a href="mailto:mposolda@redhat.com" target="_blank"></a><a href="mailto:mposolda@redhat.com" target="_blank">mposolda@redhat.com</a>></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">
<div>If you're focused on security for REST
endpoints, I think it is quite easy to do
it programaticaly. You may just need to
parse the "Authorization" header from
request with bearer token and verify it
with RSATokenVerifier.<span style="background-color:#e4e4ff">verifyToken
from which you also retrieve AccessToken
. See BearerTokenRequestAuthenticator
class for the inspiration.<span><font color="#888888"><br>
<br>
Marek<br>
</font></span></span>
<div>
<div> <br>
On 16/09/15 09:04, Orestis Tsakiridis
wrote:<br>
</div>
</div>
</div>
<div>
<div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>Thanks Bill, <br>
<br>
</div>
I think i may tackle the issue
for now through the
KeycloakConfigResolver. Maybe
return an empty deployment if
the API Key is in the request.<br>
<br>
</div>
<br>
Regards<br>
<br>
</div>
Orestis<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Sep
16, 2015 at 2:39 AM, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank"></a><a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'll
eventually implement adapter as
a filter, but right now security<br>
constraints are required.<br>
<div>
<div><br>
On 9/15/2015 5:54 PM,
Orestis Tsakiridis wrote:<br>
> Hello,<br>
><br>
> Is it possible to apply
programmatic access control
i.e. retrieve<br>
>
KeycloakSecurityContext, get
token, roles etc, when the<br>
>
<security-contraint/>
elements have been removed
from web.xml?<br>
><br>
> The reason for that is
that when
<security-constraints/>
are present the<br>
> requests get dropped by
the keycloak adapter before
reaching the REST<br>
> endpoints
implementation in case they
are not carrying a token.
I'm<br>
> trying to support an
alternative authorization
mechanism using a custom<br>
> API Key parameter in
case the Oauth token header
is missing.<br>
><br>
><br>
> Regards<br>
><br>
> Orestis<br>
><br>
><br>
><br>
><br>
><br>
><br>
</div>
</div>
>
_______________________________________________<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>
><br>
<span><font color="#888888"><br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><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>
</font></span></blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
keycloak-user mailing list
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank">keycloak-user@lists.jboss.org</a>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a></pre>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>