[Libwebsockets] Libwebsocket with Keycloak Integration
andy at warmcat.com
Wed Apr 10 10:17:10 CEST 2019
On 10/04/2019 15:04, Marcel Isenbügel wrote:
> Hey everyone,
> I’m interested to implement an authentication system to Websockets.
> So they are two different ways.
> 1.After upgrading to ws conncetion start an authorisation
> 2.On the HTTP Request test the authorization
Lws natively supports Basic Auth using the http mount stuff... URLs that
match the mount (so /secret/anything/etc if the mount was at /secret)
cause the browser to prompt the user for credentials that must exist in
a text file outside the served part of the filesystem. It's "Basic" as
the name says, but combined with TLS, it's better than nothing.
The Basic Auth support also covers ws upgrades on master, you need to
add a pvo to the related vhost attached to the protocol name and with
name "basic-auth" and value "path" where "path" is the path to the
credentials file on the server.
for how to add pvos.
> So I want to implement the second way. A Bearer Token will be send in
> the http request. Is there a easy way to catch that token and check it
> against a keycloak server.
> I think I have to extract the http header when
> LWS_CALLBACK_HTTP is called ?
> The Token is in the header => Authorization: Bearer <token>
> How can I get this token ?
You should be able to get the headers for a non-upgrade HTTP request at
LWS_CALLBACK_HTTP, but it might be worth trying
/**< This gives the user code a chance to forbid an http access.
* `in` points to a `struct lws_process_html_args`, which
* describes the URL, and a bit mask describing the type of
* authentication required. If the callback returns nonzero,
* the transaction ends with HTTP_STATUS_UNAUTHORIZED. */
in this case. You would check the Authorization: header the usual way
using token index WSI_TOKEN_HTTP_AUTHORIZATION with the api
> On Success upgrade to ws
> On Error decline connection
> Is this a right and good way to implement this ? If someone has an
> example it would be nice to see how it can works.
I'm not really clear what Keycloak is... if it's a network service
itself, you will have to create an onward client connection and await
the results before proceeding. Lws only has the idea that you can
immediately tell at the callbacks if it should proceed or not, as is the
case with Basic Auth it either gave you valid credentials in the request
header already, or it didn't... it doesn't have a way atm to defer
judgement until later. For ws upgrade, if you need an onward client
connection, atm you'd need to take the approach to accept the connection
but in the protocol don't do anything until the validity of the
credential is known from the external service, or it times out waiting.
It probably needs a little more something in lws to support this
deferred credential validity testing cleanly.
> Best regards
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets