<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><span style="background-color:rgb(255,255,255)">2. Are there any caches involved that won't be taken into account ?<br></span></div>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><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 class="HOEnZb"><font color="#888888"><br>
<br>
Marek</font></span><div><div class="h5"><br>
<br>
On 16/09/15 11:36, Orestis Tsakiridis wrote:<br>
</div></div></div><div><div class="h5">
<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">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>