I'm currently looking into the best way to perform authentication for WebSockets, and it seems that the best (only?) option so far is to handle this on the socket's endpoint itself. But before I start with some library for the other Hawkular components to consume, I'd like to ask if there's a best practices/recommendations for doing WebSocket authentication with Keycloak. My plan right now is to require the endpoints to inject a service that would accept a message and session, closing the session on this service if the login data is not provided (login data == token, send on the first message, at least at first). Ideas/thoughts? - Juca. _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

There is also another example https://github.com/secondsun/wildfly-secured-websocket , where client is javascript application . It's based on web.xml security and the client and server are both in same web application. Unfortunately I don't know if it can work if client and server are in different applications, as it seems that there is no way for add additional HTTP headers on client in javascript websockets API (at least according to http://stackoverflow.com/questions/4361173/http-headers-in-websockets-cli... ). So adding "Authorization: Bearer" looks like a challenge here.

Marek On 5.8.2015 09:54, pslegr wrote: > Hello Juraci, > > maybe other Keycloak core devs might have having other recommendations, > never-less I've put up an example for our project > https://github.com/pslegr/pnc/commit/873e875d657215890b9b9aafe93b2138ae94... > which uses Keycloak to secure the WS endpoint. > The point is to intercept the initial HttpRequest and add an > AuthorizationHeader > into this one. > > ... > List<String> authHeader = new ArrayList<String>(); > authHeader.add("Bearer " + authenticate()); > headers.put("Authorization", authHeader); > > ... > > This is done before protocol upgrade into WS/WSS. > > I don't see any other way doing this so far.... > > regards > Pavel > > On 4.8.2015 16:44, Juraci Paixão Kröhling wrote: >> I'm currently looking into the best way to perform authentication for >> WebSockets, and it seems that the best (only?) option so far is to >> handle this on the socket's endpoint itself. >> >> But before I start with some library for the other Hawkular components >> to consume, I'd like to ask if there's a best practices/recommendations >> for doing WebSocket authentication with Keycloak. >> >> My plan right now is to require the endpoints to inject a service that >> would accept a message and session, closing the session on this service >> if the login data is not provided (login data == token, send on the >> first message, at least at first). >> >> Ideas/thoughts? >> >> - Juca. >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)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

It looks it's possible to add query parameters in Javscript Websocket client. But ATM our adapter supports authenticating requests where the token is sent only in "Authorization: Bearer" header. Maybe adding support for authentication tokens from query parameter is something we can support for adapters though (if someone has valid usecase for it) Marek On 5.8.2015 10:47, Marek Posolda wrote: > There is also another example > https://github.com/secondsun/wildfly-secured-websocket , where client > is javascript application . It's based on web.xml security and the > client and server are both in same web application. Unfortunately I > don't know if it can work if client and server are in different > applications, as it seems that there is no way for add additional HTTP > headers on client in javascript websockets API (at least according to > http://stackoverflow.com/questions/4361173/http-headers-in-websockets-cli... > ). So adding "Authorization: Bearer" looks like a challenge here. > > Marek > > On 5.8.2015 09:54, pslegr wrote: >> Hello Juraci, >> >> maybe other Keycloak core devs might have having other recommendations, >> never-less I've put up an example for our project >> https://github.com/pslegr/pnc/commit/873e875d657215890b9b9aafe93b2138ae94... >> which uses Keycloak to secure the WS endpoint. >> The point is to intercept the initial HttpRequest and add an >> AuthorizationHeader >> into this one. >> >> ... >> List<String> authHeader = new ArrayList<String>(); >> authHeader.add("Bearer " + authenticate()); >> headers.put("Authorization", authHeader); >> >> ... >> >> This is done before protocol upgrade into WS/WSS. >> >> I don't see any other way doing this so far.... >> >> regards >> Pavel >> >> On 4.8.2015 16:44, Juraci Paixão Kröhling wrote: >>> I'm currently looking into the best way to perform authentication for >>> WebSockets, and it seems that the best (only?) option so far is to >>> handle this on the socket's endpoint itself. >>> >>> But before I start with some library for the other Hawkular components >>> to consume, I'd like to ask if there's a best practices/recommendations >>> for doing WebSocket authentication with Keycloak. >>> >>> My plan right now is to require the endpoints to inject a service that >>> would accept a message and session, closing the session on this service >>> if the login data is not provided (login data == token, send on the >>> first message, at least at first). >>> >>> Ideas/thoughts? >>> >>> - Juca. >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)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 > > > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user

On 5.8.2015 11:49, Juraci Paixão Kröhling wrote: > Thanks for the comments! In our case, we'd need a > "standards-compliant" WebSockets authentication, in the sense that we > cannot depend on clients adding HTTP Headers (for instance). At first, > I think our main client will be a Java agent, so, we _could_ add extra > HTTP Headers, but our main API would be available for other developers > to make their own agents. > > From what I've read, even messing with the protocol part of the > connection could be seen as a violation of the spec, but it's a grey > area (people *are* actually doing it). > > The remaining "generic" option seems to indeed be adding the > token/user+pass details to the URL. > > After that, the only solution is to do it as part of the application > protocol itself: either each message comes with a token that is > validated as the first step in processing the message (a-la > request-based authentication), or from time to time, or even just at > the beginning of the connection (which is problematic, as the user > might logout and the socket would not "notice" it). Doing at the beginning of the connection might be easy. We may just need to add support to adapters for authentication via bearer token sent in URL query parameter or in the POST body. There is also specs for it http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param . Not sure if adapters should support it by default or just on demand as there are some security implications when access token is sent in URI as mentioned in the specs. Not sure about request-based authentication, I don't know much about websockets TBH so not sure what would be required to support this.

Doing at the beginning of the connection might be easy. We may just need to add support to adapters for authentication via bearer token sent in URL query parameter or in the POST body. There is also specs for it http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html#query-param

Maybe it's possible the server will poll the client socket and ask for updated token from the client periodically. I am not sure about the possible and best option TBH (not have deep websocket knowledge)

----- Original Message ----- > From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; > To: "Marek Posolda" <mposolda(a)redhat.com&gt;, "pslegr" <pslegr(a)redhat.com&gt;, keycloak-user(a)lists.jboss.org > Sent: Wednesday, 5 August, 2015 4:20:32 PM > Subject: Re: [keycloak-user] WebSockets > > On 08/05/2015 03:39 PM, Marek Posolda wrote: >> Maybe it's >> possible the server will poll the client socket and ask for updated >> token from the client periodically. I am not sure about the possible and >> best option TBH (not have deep websocket knowledge) > > It is possible, but that goes into the "invasive" approach, as it can be > done only with a message going from the server to the client. Doing this > at the Keycloak level means that the application has to know how to > handle (or discard) Keycloak-specific messages. > > Honestly, the more I think about it, the more I realize that the best > solution would be to get an API from Keycloak that would allow me to > validate tokens and extract a principal from it, like what the Request > Authenticators do. Even better if this API could call me back from time > to time, so that my server part could ask the client part for a renewed > token. My client could then send this token in the next payload (not > necessarily a payload *only* with the token). +1 I'm less convinced about including token in URI due to security issues + access tokens are short lived. The better option is to send the access token as a message after the socket is open. If the token is expired the server should return with an appropriate error message so the client knows it needs to refresh the access token and resend to the server. We'd need to support this for multiple languages though :/

On 08/10/2015 03:26 PM, Bill Burke wrote: > Once the WeBSocket is established there is > actually no reason to resend the token as the connection/socket remains > open. HTTP requests are different. They need to retransmit the token > because HTTP is connectionless and assumes every request is a different > connection. For browser apps, logout can be handled in the regular way > with keycloak.js. Non-browser apps can just rely on non-browser means. > > All the server needs is a way to validate and unpack the token. Refresh > should be handled at the client side through keycloak.js or some other > oauth library. For bearer token auth, it is not the responsibility of > the server to manage the token. Not sure I get it. Are you saying that my server endpoint should trust that the client will close the connection once the token expires/is invalidated?

I know there's no standard protocol, but I still think the token should be sent through the socket itself not as part of the url. I don't like sending it as the url for one, secondly having to drop and re-create the socket every time the token expires negates the purpose of web sockets somewhat.

On Aug 11, 2015, at 1:23 AM, Stian Thorgersen <stian(a)redhat.com&gt; wrote: ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-user(a)lists.jboss.org > Sent: Monday, 10 August, 2015 4:10:36 PM > Subject: Re: [keycloak-user] WebSockets > > > > On 8/10/2015 9:48 AM, Juraci Paixão Kröhling wrote: >> On 08/10/2015 03:26 PM, Bill Burke wrote: >>> Once the WeBSocket is established there is >>> actually no reason to resend the token as the connection/socket remains >>> open. HTTP requests are different. They need to retransmit the token >>> because HTTP is connectionless and assumes every request is a different >>> connection. For browser apps, logout can be handled in the regular way >>> with keycloak.js. Non-browser apps can just rely on non-browser means. >>> >>> All the server needs is a way to validate and unpack the token. Refresh >>> should be handled at the client side through keycloak.js or some other >>> oauth library. For bearer token auth, it is not the responsibility of >>> the server to manage the token. >> >> Not sure I get it. Are you saying that my server endpoint should trust >> that the client will close the connection once the token expires/is >> invalidated? >> > > I didn't say that. You just don't have to retransmit the token every > request because in WebSockets the connection is already established. > > You are going to have to rely on the client to get a new token and > reconnect. Keycloak can't support every single pet protocol implemented > on top of WebSockets. We can only offer token validation on HTTP > Upgrade out-of-the-box plus an API to unpack and validate a token. > Anything more and you'll have to implement it yourself. > > IMO, abort with an error code, the client destroys the WebSocket, > refreshes the token via OAuth, and reestablishes the WebSocket. Its > the simplest way and we can provide support for it OOTB with Keycloak's > adapter lib. Otherwise you'll have to implement anything more complex > yourself. I know there's no standard protocol, but I still think the token should be sent through the socket itself not as part of the url. I don't like sending it as the url for one, secondly having to drop and re-create the socket every time the token expires negates the purpose of web sockets somewhat. > > > -- > Bill Burke > JBoss, a division of Red Hat > http://bill.burkecentral.com <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 <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 <https://lists.jboss.org/mailman/listinfo/keycloak-user>

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-user(a)lists.jboss.org Sent: Tuesday, 11 August, 2015 4:22:18 PM Subject: Re: [keycloak-user] WebSockets On 8/11/2015 1:23 AM, Stian Thorgersen wrote: > > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: keycloak-user(a)lists.jboss.org >> Sent: Monday, 10 August, 2015 4:10:36 PM >> Subject: Re: [keycloak-user] WebSockets >> >> >> >> On 8/10/2015 9:48 AM, Juraci Paixão Kröhling wrote: >>> On 08/10/2015 03:26 PM, Bill Burke wrote: >>>> Once the WeBSocket is established there is >>>> actually no reason to resend the token as the connection/socket remains >>>> open. HTTP requests are different. They need to retransmit the token >>>> because HTTP is connectionless and assumes every request is a different >>>> connection. For browser apps, logout can be handled in the regular way >>>> with keycloak.js. Non-browser apps can just rely on non-browser means. >>>> >>>> All the server needs is a way to validate and unpack the token. Refresh >>>> should be handled at the client side through keycloak.js or some other >>>> oauth library. For bearer token auth, it is not the responsibility of >>>> the server to manage the token. >>> >>> Not sure I get it. Are you saying that my server endpoint should trust >>> that the client will close the connection once the token expires/is >>> invalidated? >>> >> >> I didn't say that. You just don't have to retransmit the token every >> request because in WebSockets the connection is already established. >> >> You are going to have to rely on the client to get a new token and >> reconnect. Keycloak can't support every single pet protocol implemented >> on top of WebSockets. We can only offer token validation on HTTP >> Upgrade out-of-the-box plus an API to unpack and validate a token. >> Anything more and you'll have to implement it yourself. >> >> IMO, abort with an error code, the client destroys the WebSocket, >> refreshes the token via OAuth, and reestablishes the WebSocket. Its >> the simplest way and we can provide support for it OOTB with Keycloak's >> adapter lib. Otherwise you'll have to implement anything more complex >> yourself. > > I know there's no standard protocol, but I still think the token should be > sent through the socket itself not as part of the url. I don't like > sending it as the url for one, secondly having to drop and re-create the > socket every time the token expires negates the purpose of web sockets > somewhat. > I just don't see how this is feasible beyond providing a simple servlet-aware helper class on the server side that would be used only on connection setup. But you still have the problem of when the access token expires. That would have to be handled by the application because the protocol would be app specific.

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