<div dir="ltr">Hey Bill, thanks for the clarification, I didn't realize that the cookie was Http-only, neat!<div><br></div><div>We are building a pure HTML5 client that is also hosted separately from the REST-backends. The thing is that we use a reverse proxy so for the browser it all looks like one app since everything comes from different paths in the same domain.</div>
<div><br></div><div>I'll try to clarify the last part of my last mail: We are currently using <span style="color:rgb(0,0,0)">org.jboss.resteasy.skeleton.key.as7.OAuthAuthenticationServerValve (skeleton-key-as7) in our REST-backend modules. If I'm not mistaken, some parts of the code base and concepts are the same as in keycloak, right?</span></div>
<div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">So far, in the AngularJS application we've been adding bearer tokens to the HTTP Authorization header. Since the backend uses JAX-RS/ RestEasy, the verification of the bearer tokens was done transparently by </span><span style="color:rgb(0,0,0)">OAuthAuthenticationServerValve and RESTEasy automatically added the roles etc. to the HttpServletRequest. Now in the REST backend of the admin app in keycloak you're doing the same thing (validating the tokens and extracting the roles) manually with the AuthenticationManager (</span>authenticateSaasIdentityCookie(...)<span style="color:rgb(0,0,0)">). So </span><span style="color:rgb(0,0,0)">I was just wondering whether you are planning to make that process more transparent in the future?</span></div>
<div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">I think it would be nice to be able to write REST services with @RolesAllowed etc.</span></div><div><span style="color:rgb(0,0,0)"><br>
</span></div><div><span style="color:rgb(0,0,0)">Does that make more sense?</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">Cheers!</span></div><div><span style="color:rgb(0,0,0)">Nils</span></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 30, 2014 at 2:30 PM, Bill Burke <span dir="ltr"><<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"><div class="im"><br>
<br>
On 1/30/2014 6:24 AM, Nils Preusker wrote:<br>
> Hi,<br>
><br>
> I looked at the admin console and examined the HTTP requests and<br>
> redirects and, as far as I can see, you are using a cookie<br>
> (KEYCLOAK_SAAS_COOKIE) to exchange the authentication information (OAuth<br>
> token) between the JavaScript client app and the REST services.<br>
><br>
> Is there a specific reason you chose to use a cookie instead of a bearer<br>
> token in an authorization header?<br>
><br>
<br>
</div>The cookie, if you see, is Http-only. So, the browser app has no access<br>
to the token and can't be hit with Javascript attacks. This is all very<br>
specific to the admin console which assumes that it is not running in a<br>
servlet container and getting a HttpSession.<br>
<br>
For servlet apps (and those with a http session), token can be stored in<br>
the HTTP session and the browser app just makes rest invocations that<br>
are validated against the http session.<br>
<br>
This of course, doesn't quite work well if the browser needs to make<br>
CORS requests. So, there's also a REST invocation that you can turn on<br>
in the adapter that allows the client to get the token. Or, you can<br>
just use the pure Javascript lib that Stian wrote for pure HTML5 clients.<br>
<div class="im"><br>
> Also, are you planning to integrate the cookie mechanism as<br>
> transparently as bearer tokens (transparently validating by configuring<br>
> web.xml, adding user and roles to HttpServletRequest etc.)?<br>
><br>
<br>
</div>Not sure what you mean by that.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<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">keycloak-user@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</div></div></blockquote></div><br></div>