[Hawkular-dev] hawkular-accounts integration with websocket stuff in kettle

[Juraci Paixão Kröhling]

As an status, since it's been a couple of days already:

TL;DR:

- I have a branch in Accounts with a PoC for WebSockets. It's nowhere 
near, but it's "started" at least: http://git.io/vOSBT

- There's a discussion on Keycloak about this, but I don't think we 
should expect much from it. Mostly because it's understood that this is 
an application's concern (from the WebSocket's point of view). So, we 
are likely going to follow the route of implementing a "check" on each 
onMessage. Not clean, certainly invasive, but works. I'll try to 
alleviate the pain as much as I can by providing simple APIs.

Long version:

It seems that my knowledge of WebSockets isn't that outdated, as not 
much has happened lately. The thing is, WebSockets doesn't define any 
standard for authentication and/or authorization. On the spec, it says 
that it should rely on HTTP authentication, done on the upgrade request. 
That provides only a small part of the whole authentication scheme, 
though: given that a WebSocket can potentially live for a very long time 
(hours, or even days), it's likely that a session might expire during 
the lifetime of the socket connection. So, this connection has to be 
"somehow" refreshed or killed.

Keycloak won't be able to help that much once a connection is 
established, though: the only way of checking if a connection is still 
valid is by asking the client to send their latest token, and checking 
this token against KC server. And this would have to be part of the 
message's payload, which is very invasive from the PoV of the 
application. So, I don't expect any "transparent" support for 
WebSockets, the same way we have for regular HTTP requests.

The current ideas are:

- Check what's undertow's support for WebSockets. If it provides 
something like a "filter" for messages, Accounts could intercept the 
messages and do the checks it needs, removing the auth part from the 
message (so that the server endpoint wouldn't have to worry about it at 
all). The client, however, would still need to know how to "talk auth", 
as the server might ask it for renewed tokens.

- If undertow has no support for filters or similar, then the actual 
server endpoints would have to call Accounts with the payload (and the 
session). Accounts would then either let the processing continue, ask 
the client for a renewed token (to be sent on subsequent payloads), or 
kill the connection (if no new token was received to replace the token 
that just expired).

- In any case, Accounts would provide a Persona object. On the first 
case, it could be via CDI (hopefully), on the second case it would be 
via an API where Accounts receives the token and returns a Persona.

Is there something you'd require that I might be missing?

- Juca.


On 08/03/2015 04:34 PM, Juraci Paixão Kröhling wrote:
> Mazz,
>
> On 08/03/2015 03:01 AM, John Mazzitelli wrote:
>> I think the time is coming close when I need to wrap authentication
>> around the websockets stuff we have in the server. Right now, any
>> client can connect to our websocket server running in kettle. I know
>> you mentioned that KeyCloak doesn't have an official integration with
>> websockets today, but can we make calls to your accounts API directly
>> to do things like logging in?
>
> I'm afraid my knowledge of WebSockets might be outdated with regards to
> authentication. I'm quite sure there's no specific WebSocket support on
> Keycloak, but we might be able to leverage JAAS integration on that.
>
> In any case, I'll run some tests and come up with some options, so that
> we can start a discussion.
>
> - Juca.