Dynamic Authenticators

All authentication methods can be configured statically, i.e. the credentials are contained in the the Crossbar.io configuration.

Alternatively it is possible to give the URI for an authentication component which is called on each authentication attempt.

For example, for Ticket authentication, an example configuration for a dynamic authenticator is

"auth": {
   "ticket": {
      "type": "dynamic",
      "authenticator": "com.example.authenticate"
   }
}

A dynamic authenticator receives the full set of details about a connecting client, not just the minimum information required for a particular authentication method.

As an example, for a ticket authentication, the dynamic authorizer receives

{
    "session": 508715025212448,
    "ticket": "123sekret",
    "transport": {
       "cbtid": null,
       "protocol": "wamp.2.msgpack.batched",
       "http_headers_received": {
          "upgrade": "WebSocket",
          "sec-websocket-version": "13",
          "sec-websocket-protocol": "wamp.2.msgpack.batched,wamp.2.msgpack,wamp.2.json.batched,wamp.2.json",
          "host": "localhost:8080",
          "sec-websocket-key": "xWszwpILt1/lMXVdGmIkfw==",
          "user-agent": "AutobahnPython/0.11.0",
          "connection": "Upgrade",
          "pragma": "no-cache",
          "cache-control": "no-cache"
       },
       "peer": "tcp4:127.0.0.1:17185",
       "http_headers_sent": {},
       "type": "websocket",
       "client_cert": null
    }
 }

Running authenticators in configurable realms

By default, dynamic authenticators must run in the same realm as the session that is connecting.

In some situations, this can be a pain, and it is possible to invoke dynamic authenticators on a different realm than the session connecting by configuring an explicit realm:

"auth": {
   "ticket": {
      "type": "dynamic",
      "authenticator": "com.example.authenticate",
      "authenticator-realm": "realm-auth"
   }
}

With the above, the authenticator (which needs to be connected to realm-auth) is invoked irrespective of the realm that a client using ticket authentication connects to.

Data the authenticator can set

In many methods, the authenticator need only return the authrole which it determines.

It can, however, also always return an authid and a realm. In cases where these are provided by the client, this allows overwriting the clients’ requests for these.

Custom Data

An authenticator can return custom data, which is passed on to authenticated clients in the WELCOME message as part of the details.

As an example, in a dynamic authenticator component written in Python for a ticket authentication, this could return the following result:

res = {
   u'realm': principal[u'realm'],
   u'role': principal[u'role'],
   u'extra': {
      u'my-custom-welcome-data': [1, 2, 3]
   }
}
return res

where the extra dictionary can contain any data the implementer wants.

Example

We provide a full working example for the above. (This uses ticket authentication, but the principles apply to other authentication types.)