[keycloak-user] Undertow Bearer Token in Cookie

Jérôme Blanchard jayblanc at gmail.com
Tue Dec 23 04:03:11 EST 2014


Hi, by mentionning the servlet adapter, you mean the WAR configured using
web.xml (server side) ? or the client servlet adapter ?

In our configuration we have a REST API prtoected using the WAR wildfly
adapter (ensuring EJB auth propagation) and a JS client.

I tried using the configuration of cookie token store (

"token-store": "cookie"

) in the wildfly adapter (server side) but no cookie is set in my HTML5/JS
client and it seem no cookie is catched by the wildfly adapter...
Did I missed something ?

Best regards, Jérôme.

Le Mon Dec 22 2014 at 16:24:58, Bill Burke <bburke at redhat.com> a écrit :

Servlet adapter already does this.
>
> * 1.0.x Keycloak attaches the token to the Http Session.
> * 1.1 Beta+ Keycloak adapter has an option to store the token in a
> cookie instead of the HttpSession.
>
> On 12/18/2014 12:07 PM, Jérôme Blanchard wrote:
> > Hi all,
> >
> > Is it possible to configure the servlet adapter to check presence of a
> > bearer token in a cookie instead of in a header ?
> > This question is about the download file usecase. If the bearer token
> > will be placed in a cookie by the javascript client at the same time
> > settnig the header, his will ensure that this cookie will be sent by the
> > navigator in the case of a download file or a <img> tag that would
> > happen outside of a XHR.
> >
> > Thanks, Best Regards, Jérôme.
> >
> > Le Wed Dec 17 2014 at 18:12:35, Jérôme Blanchard <jayblanc at gmail.com
> > <mailto:jayblanc at gmail.com>> a écrit :
> >
> >     Hi Stian,
> >
> >     Thanks for your precisions, we have choose to implement the solution
> >     of a time based password.
> >     Using a ServletFilter and the Servlet 3.0 HttpRequest.login()
> >     feature we're able to intercept token from query parameter and
> >     propagate it to the JAAS stack. A dedicated LoginModule validate
> >     this token to enforce principal in the EJB SecurityContext and,
> >     according to this, our custom authorisation system is used ASIS
> >     without the need to create a hook in the download operation.
> >     This solution give the advantage to not interfer with the classic
> >     OAuth authentication in case of using a XHR Header nor a RESTClient
> >     that programmatically include the bearer token in the request header.
> >
> >     Thanks a lot for your support, Best Regards, Jérôme.
> >
> >
> >
> >     Le Wed Dec 17 2014 at 09:05:22, Stian Thorgersen <stian at redhat.com
> >     <mailto:stian at redhat.com>> a écrit :
> >
> >
> >
> >         ----- Original Message -----
> >          > From: "Jérôme Blanchard" <jayblanc at gmail.com
> >         <mailto:jayblanc at gmail.com>>
> >          > To: "Stian Thorgersen" <stian at redhat.com
> >         <mailto:stian at redhat.com>>
> >          > Cc: keycloak-user at lists.jboss.org
> >         <mailto:keycloak-user at lists.jboss.org>
> >          > Sent: Tuesday, 16 December, 2014 5:51:37 PM
> >          > Subject: Re: [keycloak-user] HTML5/JS and download URL.
> >          >
> >          > Hi,
> >          >
> >          > Thank you for your answer. Sorry for my lake of knowledge in
> >         OAuth but
> >          > speaking about generating a temporary token to include in the
> >         link, what
> >          > kind of token do you mean and what is the best way to do that
> >         with Keycloak.
> >
> >         We don't have any support for this at the moment so you would
> >         have to make it yourself. With regards to token all I mean is a
> >         something temporary that allows the server to verify the user
> >         has permissions to download the file.
> >
> >         For example the token could be the base64 encoded signature
> >         (hmac, rsa or whatever you'd like) of userid,
> >         timestamp/expiration and file-url. That way the server can
> >         simply verify the signature on the server-side when the user is
> >         trying to download the file and check that it matches.
> >
> >          >
> >          > Best regards, Jérôme.
> >          >
> >          > 2014-12-15 16:49 GMT+01:00 Stian Thorgersen <stian at redhat.com
> >         <mailto:stian at redhat.com>>:
> >          > >
> >          > >
> >          > >
> >          > > ----- Original Message -----
> >          > > > From: "Jérôme Blanchard" <jayblanc at gmail.com
> >         <mailto:jayblanc at gmail.com>>
> >          > > > To: keycloak-user at lists.jboss.org
> >         <mailto:keycloak-user at lists.jboss.org>
> >          > > > Sent: Monday, 15 December, 2014 3:13:06 PM
> >          > > > Subject: [keycloak-user] HTML5/JS and download URL.
> >          > > >
> >          > > > Hi all,
> >          > > > We have a use case where an HTML5/Angular application is
> >         calling a REST
> >          > > > interface using keycloak for authentication SSO.
> >         Everything works fine
> >          > > until
> >          > > > we need to download files or preview images (using <img>
> >         tag). In both
> >          > > case,
> >          > > > this is the browser which perform the request on the REST
> >         url and,
> >          > > because
> >          > > > of a specific XHR authentication putting the bearer token
> >         in the
> >          > > headers, a
> >          > > > 'classic' browser request for downloading a file result
> in an
> >          > > > UNauthenticated request because of unexisting bearer
> token.
> >          > > >
> >          > > > We're minding if there is a best practice to handle this
> >         case. We plan to
> >          > > > include a dedicated token as a download request parameter
> >         and to check
> >          > > this
> >          > > > particular query paramter programmatically in the
> >         /download JAX-RS
> >          > > > operation. What kind of token should have to put in the
> >         query and is
> >          > > there
> >          > > > an already existing mechanism to catch such token in
> >         jax-rs server-side
> >          > > > operations nor programmatically ?
> >          > >
> >          > > We actually had the same issue in our admin console as we
> >         provide a
> >          > > download option for the application config. AFAIK there's
> >         two solutions:
> >          > >
> >          > > * Generate a temporary token - basically what you're
> >         suggesting. There's
> >          > > two ways you can do this, always generate one and add it to
> >         the link,
> >          > > second is to use a redirect that only generates the token
> >         on demand
> >          > > * Use XHR to get the file, which allows setting the
> >         Authorization header,
> >          > > then use JavaScript to download
> >          > >
> >          > > There's currently no direct support for this in Keycloak,
> >         but it would be
> >          > > interesting to add.
> >          > >
> >          > > >
> >          > > > Thanks a lot for your support and so good work, Best
> >         Regards, Jérôme.
> >          > > >
> >          > > > ___________________________________________________
> >          > > > keycloak-user mailing list
> >          > > > keycloak-user at lists.jboss.org
> >         <mailto:keycloak-user at lists.jboss.org>
> >          > > >
> >         https://lists.jboss.org/__mailma__n/listinfo/keycloak-user
> >         <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
> _______________________________________________
> 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/20141223/892c59a3/attachment-0001.html 


More information about the keycloak-user mailing list