Re: [keycloak-user] WebSockets

On 8/5/2015 7:52 AM, Marek Posolda wrote: > 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. > Looks like something we need to support. Is it something we would only support with Servlet 3.1 (which has http upgrade support)? The way we could implement is that we only support query-param tokens when an HTTP Upgrade request is invoked.