<div dir="ltr">Hey Bill, <div><br></div><div>thanks for the clarification! We're also building a pure client side JavaScript application which calls a bunch of stateless REST services. I'm looking for the best way to secure those REST services and add a log-in mechanism to the UI. </div>
<div><br></div><div>Now I looked at the new example customer-app-js which will be included in the Alpha 3 release and saw that you are using bearer tokens there. So far, I thought that the HttpOnly cookie mechanism was the preferred way to handle OAuth in a pure client side app which uses stateless REST services. In that scenario, I was just going to add a request interceptor in my JS application, where I would handle unauthorized responses with either a refresh token or a redirect to the log-in page. What do you think?</div>
<div><br></div><div>Cheers,</div><div>Nils</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 11, 2014 at 2:14 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">The adapters do not set any cookies except the temporary OAUTH *state*<br>
cookie. The demo examples remember authenticated sessions by storing<br>
the token in the HttpSession.<br>
<br>
The admin console is really just a bunch of stateless REST services<br>
which is why it sets the Identity cookie. What you're seeing is a bug<br>
in Resteasy as the cookie is created with HttpOnly set to true.<br>
<br>
<a href="https://issues.jboss.org/browse/RESTEASY-1026" target="_blank">https://issues.jboss.org/browse/RESTEASY-1026</a><br>
<div class=""><br>
On 3/11/2014 8:59 AM, Nils Preusker wrote:<br>
> digging a bit deeper... I looked for usages of HttpFacade.setCookie and<br>
> noticed that HttpOnly always seems to be set to false... If I understood<br>
> the log-in mechanism for pure client side JavaScript applications<br>
> correctly, it was supposed to be based on a HttpOnly cookie, which makes<br>
> it impossible for scripts (so the JavaScript application) to access the<br>
> cookie.<br>
><br>
> Am I missing something?<br>
><br>
> Cheers,<br>
> Nils<br>
><br>
><br>
> On Tue, Mar 11, 2014 at 12:08 PM, Nils Preusker <<a href="mailto:n.preusker@gmail.com">n.preusker@gmail.com</a><br>
</div><div class="">> <mailto:<a href="mailto:n.preusker@gmail.com">n.preusker@gmail.com</a>>> wrote:<br>
><br>
> Hey guys,<br>
><br>
> I just looked at the login mechanism and the communication between<br>
> the admin console and the backend in the alpha 2 release again. If<br>
> I'm not mistaken, you used to use HTTP-only for the<br>
> KEYCLOAK_SAAS_IDENTITY cookie. Did something change about that in<br>
> alpha 2? When I look at the HTTP requests in the chrome developer<br>
> console, I don't see the HttpOnly flag anywhere.<br>
><br>
> Cheers,<br>
> Nils<br>
><br>
><br>
> On Thu, Jan 30, 2014 at 5:23 PM, Stian Thorgersen <<a href="mailto:stian@redhat.com">stian@redhat.com</a><br>
</div><div class="">> <mailto:<a href="mailto:stian@redhat.com">stian@redhat.com</a>>> wrote:<br>
><br>
><br>
><br>
> ----- Original Message -----<br>
</div><div><div class="h5">> > From: "Bill Burke" <<a href="mailto:bburke@redhat.com">bburke@redhat.com</a> <mailto:<a href="mailto:bburke@redhat.com">bburke@redhat.com</a>>><br>
> > To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
> > Sent: Thursday, 30 January, 2014 3:46:52 PM<br>
> > Subject: Re: [keycloak-user] Keycloak and OAuth 2.0 Resource<br>
> Owner Password Credentials Grant<br>
> ><br>
> ><br>
> ><br>
> > On 1/30/2014 9:29 AM, Nils Preusker wrote:<br>
> > > Hey Bill, thanks for the clarification, I didn't realize<br>
> that the cookie<br>
> > > was Http-only, neat!<br>
> > ><br>
> > > We are building a pure HTML5 client that is also hosted<br>
> separately from<br>
> > > the REST-backends. The thing is that we use a reverse proxy<br>
> so for the<br>
> > > browser it all looks like one app since everything comes<br>
> from different<br>
> > > paths in the same domain.<br>
> > ><br>
> > > I'll try to clarify the last part of my last mail: We are<br>
> currently<br>
> > > using<br>
> org.jboss.resteasy.skeleton.key.as7.OAuthAuthenticationServerValve<br>
> > > (skeleton-key-as7) in our REST-backend modules. If I'm not<br>
> mistaken,<br>
> > > some parts of the code base and concepts are the same as in<br>
> keycloak,<br>
> > > right?<br>
> > ><br>
> > > So far, in the AngularJS application we've been adding<br>
> bearer tokens to<br>
> > > the HTTP Authorization header. Since the backend uses<br>
> JAX-RS/ RestEasy,<br>
> > > the verification of the bearer tokens was done transparently by<br>
> > > OAuthAuthenticationServerValve and RESTEasy automatically<br>
> added the<br>
> > > roles etc. to the HttpServletRequest. Now in the REST<br>
> backend of the<br>
> > > admin app in keycloak you're doing the same thing<br>
> (validating the tokens<br>
> > > and extracting the roles) manually with the<br>
> AuthenticationManager<br>
> > > (authenticateSaasIdentityCookie(...)). So I was just<br>
> wondering whether<br>
> > > you are planning to make that process more transparent in<br>
> the future?<br>
> > ><br>
> ><br>
> > We're doing it manually because the original idea was that<br>
> the admin<br>
> > service could manage multiple organizations (a SaaS), so<br>
> you'd have to<br>
> > set up the cookie path's correctly.<br>
> ><br>
> > For your app, it sounds like @RolesAllowed will work. You<br>
> just have to<br>
> > set up the appropriate web.xml security constraints for your<br>
> REST urls<br>
> > in web.xml. Just set up the REST apis to require<br>
> authentication and let<br>
> > @RolesAllowed do the rest. The keycloak jboss/wildfly<br>
> adapter can<br>
> > handle BEARER token auth at the same time as regular browser<br>
> oauth. If<br>
> > the server is initiating the login, then you can just follow<br>
> the current<br>
> > keycloak examples. If not, then the Javascript lib Stian<br>
> wrote is an<br>
> > option (and something we'll have to document).<br>
><br>
> JS lib needs a bit of work as well, if it's something you want I<br>
> can make it a priority<br>
><br>
> ><br>
> ><br>
> ><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>
</div></div>> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div class="">> > <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
> ><br>
> _______________________________________________<br>
> keycloak-user mailing list<br>
</div>> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a> <mailto:<a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a>><br>
<div class="HOEnZb"><div class="h5">> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
><br>
><br>
><br>
><br>
><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>
><br>
<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>