[keycloak-user] Keycloak and OAuth 2.0 Resource Owner Password Credentials Grant
n.preusker at gmail.com
Tue Mar 11 07:08:30 EDT 2014
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
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
> > > 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
> > > (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
> > > 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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the keycloak-user