<div dir="ltr"><div>It makes sense.<br><br></div>Thanks for your help.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 17, 2015 at 7:54 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 17/09/15 16:25, Orestis Tsakiridis
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Marek, you 're a life saviour!<br>
<br>
</div>
The concept worked perfect. <br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></span>
Nice <span><span> :-) </span></span><br><span class="">
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div><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>
</div>
</div>
</div>
</blockquote></span>
Yes, it works how you described. The Basic authentication support
was added just for legacy applications support. It's not something
recommended.<span class="HOEnZb"><font color="#888888"><br>
<br>
Marek</font></span><div><div class="h5"><br>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<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>
<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><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><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><font color="#888888"> <br>
Marek</font></span>
<div>
<div><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"></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>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"></a><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"></a><a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" 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"></a><a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
_______________________________________________<br>
keycloak-user
mailing list<br>
<a href="mailto:keycloak-user@lists.jboss.org" target="_blank"></a><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"></a><a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" 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>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>