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

Nils Preusker n.preusker at gmail.com
Tue Mar 11 08:59:07 EDT 2014


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>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>wrote:
>
>>
>>
>> ----- Original Message -----
>> > From: "Bill Burke" <bburke at redhat.com>
>> > To: 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
>> > 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140311/899e3633/attachment.html 


More information about the keycloak-user mailing list