It’s possible to enable shared sessions whereby users already
logged in to your website will also automatically be logged in on the XMPP server,
Once a user is logged in, the session will be kept alive across page loads.
There are a few ways to let your users be automatically authenticated to an
XMPP server once they’ve logged in to your site.
Option 1). Server-side authentication via BOSH prebinding
To prebind refers to a technique whereby your web application sets up an
authenticated BOSH session with the XMPP server or a standalone BOSH
connection manager.
Once authenticated, it receives RID and SID tokens which need to be passed
on to Converse. Converse will then attach to that same session using
those tokens.
It’s called “prebind” because you bind to the BOSH session beforehand, and then
later in the page you just attach to that session again.
The RID and SID tokens can be passed in manually when calling
converse.initialize, but a more convenient way is to pass Converse a prebind_url
which it will call when it needs the tokens. This way it will be able to
automatically reconnect whenever the connection drops, by simply calling that
URL again to fetch new tokens.
Prebinding reduces network traffic and also speeds up the startup time for
Converse. Additionally, because prebind works with tokens, it’s not necessary
for the XMPP client to know or store users’ passwords.
One potential drawback of using prebind is that in order to establish the
authenticated BOSH session server-side, you’ll need to access and pass on the XMPP
credentials server-side, which, unless you’re using tokens, means that you’ll
need to store XMPP passwords in cleartext.
This is however not the case if you for example use LDAP or Active Directory as
your authentication backend, since you could then configure your XMPP server to
use that as well.
To prebind you will require a BOSH-enabled XMPP server for Converse to connect to
(see the bosh_service_url under Configuration settings)
as well as a BOSH client in your web application (written for example in
Python, Ruby or PHP) that will set up an authenticated BOSH session, which
Converse can then attach to.
Note
A BOSH server acts as a bridge between HTTP, the protocol of the web, and
XMPP, the instant messaging protocol.
Converse can only communicate via HTTP (or websocket, in which case BOSH can’t be used).
It cannot open TCP sockets to communicate to an XMPP server directly.
So the BOSH server acts as a middle man, translating our HTTP requests into XMPP stanzas and vice versa.
Jack Moffitt has a great blogpost
about this and even provides an
example Django application
to demonstrate it.
When you authenticate to the XMPP server on your backend application (for
example via a BOSH client in Django), you’ll receive two tokens, RID (request ID) and SID (session ID).
The Session ID (SID) is a unique identifier for the current session. This
number stays constant for the entire session.
The Request ID (RID) is a unique identifier for the current request (i.e.
page load). Each page load is a new request which requires a new unique RID.
The best way to achieve this is to simply increment the RID with each page
load.
You’ll need to configure Converse with the prebind prebind_url settings.
Please read the documentation on those settings for a fuller picture of what
needs to be done.
Example code for server-side prebinding
Option 2). Delegated authentication, also called external authentication
Delegated authentication refers to the usecase where the XMPP server delegates
authentication to some other service.
This could be to LDAP or Active Directory (as shown in the diagram at the top
of the page), or it could be to an OAuth provider, a SQL server to a specific
website.
The Prosody webserver has various user-contributed modules which delegate
authentication to external services. They are listed in the Prosody community modules
page. Other XMPP servers have similar plugin modules.
If your web-application has access to the same credentials, it can send those
credentials to Converse so that user’s are automatically logged in when the
page loads.
This is can be done by setting auto_login to true and configuring the
the credentials_url setting.
Option 3). Temporary authentication tokens
The first option has the drawback that your web-application needs to know the
XMPP credentials of your users and that they need to be stored in the clear.
The second option has that same drawback and it also needs to pass those
credentials to Converse.
To avoid these drawbacks, you can instead let your backend web application
generate temporary authentication tokens which are then sent to the XMPP server
which in turn delegates authentication to an external authentication provider
(generally the same web-app that generated the tokens).
This can be combined with prebind or with the credentials_url setting.
