The adapters do not set any cookies except the temporary OAUTH *state*
cookie. The demo examples remember authenticated sessions by storing
the token in the HttpSession.
The admin console is really just a bunch of stateless REST services
which is why it sets the Identity cookie. What you're seeing is a bug
in Resteasy as the cookie is created with HttpOnly set to true.
digging a bit deeper... I looked for usages of HttpFacade.setCookie
and
noticed that HttpOnly always seems to be set to false... If I understood
the log-in mechanism for pure client side JavaScript applications
correctly, it was supposed to be based on a HttpOnly cookie, which makes
it impossible for scripts (so the JavaScript application) to access the
cookie.
Am I missing something?
Cheers,
Nils
On Tue, Mar 11, 2014 at 12:08 PM, Nils Preusker <n.preusker(a)gmail.com
<mailto:n.preusker@gmail.com>> wrote:
Hey guys,
I just looked at the login mechanism and the communication between
the admin console and the backend in the alpha 2 release again. If
I'm not mistaken, you used to use HTTP-only for the
KEYCLOAK_SAAS_IDENTITY cookie. Did something change about that in
alpha 2? When I look at the HTTP requests in the chrome developer
console, I don't see the HttpOnly flag anywhere.
Cheers,
Nils
On Thu, Jan 30, 2014 at 5:23 PM, Stian Thorgersen <stian(a)redhat.com
<mailto:stian@redhat.com>> wrote:
----- Original Message -----
> From: "Bill Burke" <bburke(a)redhat.com
<mailto:bburke@redhat.com>>
> To: keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
> Sent: Thursday, 30 January, 2014 3:46:52 PM
> Subject: Re: [keycloak-user] Keycloak and OAuth 2.0 Resource
Owner Password Credentials Grant
>
>
>
> On 1/30/2014 9:29 AM, Nils Preusker wrote:
> > Hey Bill, thanks for the clarification, I didn't realize
that the cookie
> > was Http-only, neat!
> >
> > 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.
> >
> > I'll try to clarify the last part of my last mail: We are
currently
> > using
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?
> >
> > 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
> > 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
> > (authenticateSaasIdentityCookie(...)). So I was just
wondering whether
> > you are planning to make that process more transparent in
the future?
> >
>
> We're doing it manually because the original idea was that
the admin
> service could manage multiple organizations (a SaaS), so
you'd have to
> set up the cookie path's correctly.
>
> For your app, it sounds like @RolesAllowed will work. You
just have to
> set up the appropriate web.xml security constraints for your
REST urls
> in web.xml. Just set up the REST apis to require
authentication and let
> @RolesAllowed do the rest. The keycloak jboss/wildfly
adapter can
> handle BEARER token auth at the same time as regular browser
oauth. If
> the server is initiating the login, then you can just follow
the current
> keycloak examples. If not, then the Javascript lib Stian
wrote is an
> option (and something we'll have to document).
JS lib needs a bit of work as well, if it's something you want I
can make it a priority
>
>
>
> --
> Bill Burke
> JBoss, a division of Red Hat
>
http://bill.burkecentral.com
> _______________________________________________
> keycloak-user mailing list
> keycloak-user(a)lists.jboss.org
<mailto:keycloak-user@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/keycloak-user
>
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org <mailto:keycloak-user@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-user
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user