[keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant

[Bill Burke]

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.

https://issues.jboss.org/browse/RESTEASY-1026

On 3/11/2014 8:59 AM, Nils Preusker wrote:
> 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 at gmail.com
> <mailto:n.preusker at 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 at redhat.com
>     <mailto:stian at redhat.com>> wrote:
>
>
>
>         ----- Original Message -----
>          > From: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>          > To: keycloak-user at lists.jboss.org
>         <mailto:keycloak-user at 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 at lists.jboss.org
>         <mailto:keycloak-user at lists.jboss.org>
>          > https://lists.jboss.org/mailman/listinfo/keycloak-user
>          >
>         _______________________________________________
>         keycloak-user mailing list
>         keycloak-user at lists.jboss.org <mailto:keycloak-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/keycloak-user
>
>
>
>
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com