8:01 p.m.
Juca,
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?
In our websockets code, I believe we can get access to the headers that were passed in by
the UI client when connecting to websockets
(javax.websocket.Session.getRequestParameterMap() is what I assume we can use). So a UI or
feed could pass in username/password (just like a normal HTTP client would to connect to
our metrics or inventory REST API). We would just need to manually take those
username/password credentials and ask accounts to verify the credentials and perhaps give
us back a UserPrincipal or whatever it is you can give us.
We will eventually need to use this user principal or whatever to logically link that UI
client (and the requests it makes to the server) to the responses of those requests (so
those responses can be sent back to the proper client)
Ideas?
--John Mazz
9:34 a.m.
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.
5:12 a.m.
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.
5:38 a.m.
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.
What do you mean by session expiring (which session)?
If the WS-client goes away, the server will see an event for it.
What may possibly more a cause for concern is that a Hawkular user may
have a WS-connection open and the user is removed from the user
database. In this case we may want to invalidate all tokens/grants and
also forcefully disconnect the WS.
5:40 a.m.
On 08/06/2015 12:38 PM, Heiko W.Rupp wrote:
> 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.
What do you mean by session expiring (which session)?
The HTTP session. For instance, if the user has performed a "single sign
out". Then, the user should be logged out of all applications.
What may possibly more a cause for concern is that a Hawkular user
may
have a WS-connection open and the user is removed from the user
database. In this case we may want to invalidate all tokens/grants and
also forcefully disconnect the WS.
That's a good variant for the above scenario.
- Juca.
8:05 a.m.
Is there something you'd require that I might be missing?
If we have something like this:
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.
then that would be very helpful and possibly most of what we need (I say "most"
because this wouldn't cover the use-case Heiko just mentioned - what if a user has
been removed from the system - we would need to know that and forcibly disconnect the
WebSocket connection - but that's an edge case. For now, just care about the general
use-case of a user making a connection - how do we authenticate that user?)
8:21 a.m.
On 08/06/2015 03:05 PM, John Mazzitelli wrote:
> Is there something you'd require that I might be missing?
If we have something like this:
> 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.
then that would be very helpful and possibly most of what we need (I say "most"
because this wouldn't cover the use-case Heiko just mentioned - what if a user has
been removed from the system - we would need to know that and forcibly disconnect the
WebSocket connection - but that's an edge case. For now, just care about the general
use-case of a user making a connection - how do we authenticate that user?)
I'd say that it even fulfills this case, as the check would be done on
Accounts, having access to the session. Accounts would then close the
session if needed.
- Juca.
11:34 a.m.
Mazz,
I just finished a draft that is close to become the final code for this.
It has no documentation apart from a sample application that I'm using
to test it.
I'd appreciate if you could give some feedback and check whether it
provides what's needed for your component.
I'll be working on writing some documentation tomorrow, but feel free to
ping me on IRC should you have any questions.
The working branch is here:
https://github.com/jpkrohling/hawkular-accounts/tree/HAWKULAR-505-WebSock...
Basically, the approach is:
- Websocket client sends JSON messages to server, with an
"authentication" node on the message (at least on the first message)
- Server uses CDI to inject the Accounts WebSocket API's
- Server calls "authenticate()" method, passing the message and the Session
- Authenticate will automatically close the Session if the auth data is
missing, invalid or expired
What could be implemented, in case you need:
- support for binary messages (you'd have to tell the API what's the
token, though)
- support for username/password instead of token
- Juca.
On 08/06/2015 03:21 PM, Juraci Paixão Kröhling wrote:
On 08/06/2015 03:05 PM, John Mazzitelli wrote:
>> Is there something you'd require that I might be missing?
>
> If we have something like this:
>
>> 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.
>
> then that would be very helpful and possibly most of what we need (I
> say "most" because this wouldn't cover the use-case Heiko just
> mentioned - what if a user has been removed from the system - we would
> need to know that and forcibly disconnect the WebSocket connection -
> but that's an edge case. For now, just care about the general use-case
> of a user making a connection - how do we authenticate that user?)
I'd say that it even fulfills this case, as the check would be done on
Accounts, having access to the session. Accounts would then close the
session if needed.
- Juca.
2:32 p.m.
Juca,
I think I have the hawkular websocket code ready to start calling the accounts API.
Looking at:
https://github.com/jpkrohling/hawkular-accounts/blob/HAWKULAR-505-WebSock...
I would need "authenticateWithUsernamePassword" to be implemented (right now it
is private and throws UnsupportedOperationException) as well as
"authenticateWithToken" be exposed (right now this is private). I don't care
about the return values - so if you want to provide versions of these methods that return
void rather than return your cached session, that's fine. I am assuming if
authentication fails, a WebsocketAuthenticationException will be thrown; if authentication
succeeds, the methods just return normally.
I plan on being able to pass you an optional "persona" (I saw in your PoC that
your methods accepts a persona in addition to credentials or tokens). If that is not your
plan in the future, let me know and I will remove the code I have for passing around
persona.
I think I have the server-side stuff coded up (with a couple of TODOs where calls to your
new authenticate methods will go) in a branch in hawkular-bus. Here's a place where I
will be calling the accounts API, as an example:
https://github.com/hawkular/hawkular-bus/blob/mazz/hawkular-581-websocket...
--John Mazz
----- Original Message -----
Mazz,
I just finished a draft that is close to become the final code for this.
It has no documentation apart from a sample application that I'm using
to test it.
I'd appreciate if you could give some feedback and check whether it
provides what's needed for your component.
I'll be working on writing some documentation tomorrow, but feel free to
ping me on IRC should you have any questions.
The working branch is here:
https://github.com/jpkrohling/hawkular-accounts/tree/HAWKULAR-505-WebSock...
Basically, the approach is:
- Websocket client sends JSON messages to server, with an
"authentication" node on the message (at least on the first message)
- Server uses CDI to inject the Accounts WebSocket API's
- Server calls "authenticate()" method, passing the message and the Session
- Authenticate will automatically close the Session if the auth data is
missing, invalid or expired
What could be implemented, in case you need:
- support for binary messages (you'd have to tell the API what's the
token, though)
- support for username/password instead of token
- Juca.
On 08/06/2015 03:21 PM, Juraci Paixão Kröhling wrote:
> On 08/06/2015 03:05 PM, John Mazzitelli wrote:
>>> Is there something you'd require that I might be missing?
>>
>> If we have something like this:
>>
>>> 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.
>>
>> then that would be very helpful and possibly most of what we need (I
>> say "most" because this wouldn't cover the use-case Heiko just
>> mentioned - what if a user has been removed from the system - we would
>> need to know that and forcibly disconnect the WebSocket connection -
>> but that's an edge case. For now, just care about the general use-case
>> of a user making a connection - how do we authenticate that user?)
>
> I'd say that it even fulfills this case, as the check would be done on
> Accounts, having access to the session. Accounts would then close the
> session if needed.
>
> - Juca.
3408
days inactive
3433
days old
8 comments
3 participants
participants (3)
-
Heiko W.Rupp -
John Mazzitelli -
Juraci Paixão Kröhling