Jabber (XMPP) Client

Introduction

Some versions of Access Manager have a remote alert feature whereby all audit trail events received from controllers can be forwarded to a remote application, via LAN/WAN/Internet using Jabber. For simple remote monitoring the remote application could be a simple "chat" client. For more sophisticated monitoring the remote Jabber client could be embedded in an application.

The primary benefits of using Jabber are that it eliminates the need for fixed IP addresses, and routers do not need to be set up with port redirection, demilitarised zones, or open ports. This simplifies setup and eliminates the need to expose LANs to potentially hostile traffic from the internet.

Setting up Accounts

Before a link can be initiated, first a Jabber account must be created for both Access Manager and the remote client. Jabber accounts are held with Jabber servers and operate in a similar way to email accounts. The Jabber equivalent of an email address is a Jabber ID, and they are identical in form (ie user@server.net). Just like email accounts, two Jabber accounts do not need to be on the same server in order to communicate. Like email servers Jabber servers can be public (see http://xmpp.org/services/ for a list of public servers), private, or restricted to operating within a LAN. The advantage of using public servers is that everything works immediately (it takes literally a few seconds to set up an account on a public server). The disadvantage is that you are forced to rely on the integrity of a third party for your security. The advantage of having a private server, especially on a LAN, is that you have complete control. The disadvantage is that it's up to you to make the system operative and secure. In practice, setting up a Jabber server for use on a LAN is quite simple (for a full range of Jabber servers please see http://xmpp.org/software/servers.shtml). It is strongly recommended that you select a server that accepts TLS (Transport Layer Security) connections.

Setting up an Account for Access Manager

To create an account using Access Manager, first display the Jabber client. Then select from the  New... Ú from the drop-list in the Account box. You will then be asked for an account ID. This can be <anything>@<any existing server>, such as mysite@jabber.org. If the account name (in the example mysite) is not already taken, your account will be set up and the drop-list will change to  Online Ú.

Checking the Security of an Access Manager Account

The Server Certificate box displays the server certificate details. It is the your responsibility to check it matches the server with which you have signed up. If there is no certificate, the link is not secure (encrypted), which means in most circumstances that it should not be used.

Setting up Links

Once both accounts are created, either account holder should send a request to the other to be placed on the contacts list of the other. Most Jabber clients (including Access Manager) operate on a mutual basis, so that upon receiving and accepting the request they make a request back to the originator. Once this has been done, Access Manager and the remote client may communicate as and when required.

Setting up a Link using Access Manager

To set up a link using Access Manager, first display the Jabber client. Ordinarily the drop-list to the right of the contacts list is set to  Deny Authorisation Requests Ú to secure the client against being added to anyone's roster. When setting up a link you should set this to  Confirm Authorisation Requests Ú or  Accept Authorisation Requests Ú at each end of the link. Either end can then press the     Add...     button to add the other end's Jabber ID to the contacts list. This will send an authorisation request to the other client. When the remote end accepts the authorisation request, it will automatically send back a second authorisation request, and once accepted each will be in the other's contacts list. Once all required links are set up, the drop-list can then be set back to  Deny Authorisation Requests Ú on each client. Selecting a contact at either end of a link and pressing the     Delete     button will effectively delete the link.

Operation of a Communications Session

Jabber operates on the basis of sessions, each of which has a unique ID so that responses are routed back to the client that requested a response. To initiate a communications session with a remote Access Manager system, all you have to do is use any Jabber client to send the following message to that system:

    login <username> <password>

where <username> and <password> are the details of an Access Manager user who has been granted administrative or monitoring rights.

Although the password is in plain text, the remote client can use TLS to encrypt it (along with the entire session), so it will not appear as plain text in the network traffic. The Access Manager client will always use TLS if the Jabber server accepts a TLS connection.

Once Access Manager has authenticated the user it will begin sending back log records every time it updates its log table. It will do this until connection is broken for any reason (such as the remote client logging out). The records are in the following format:

    <type>\t<logID>\t<timestamp>\t<date>\t<time>\t<description>\t<controller>\t<door>\t<reader>

where \t means tab.

The type field is a single character that identifies the type of record. It may be conveniently used either to filter unwanted messages, or to raise an alarm when certain types of event (such as an attempt to gain unauthorised access) happen. Note that additional event types may be added at a later date, and that they could be any of the characters represented by a single byte.

The logID field is a 32 bit number (represented as a hexadecimal string) that effectively uniquely identifies the log record in the Access Manager database (the number is incremented with each new record). Note that access requests (record type 'T') and their acceptance or denial (record types 'U', 'A', 'B', and 'P') are stored in the same record by Access Manager, and will therefore have the same logID. Thus the logID field could be used to collate the two if desired. However, the access denial or rejection messages repeat the information provided by the access request message.

The timestamp field is a 32 bit number (represented as a hexadecimal string), and represents the time and date in GMT as the number of seconds passed since 1st January 1970. Note that on a multi-controller network the messages may not appear in time order, as the controllers cannot all report activity simultaneously.

The date and time fields are strings formatted according to the time and date format set in the Windows Control Panel on the PC on which Access Manager is running. They will therefore represent local time.

The remaining fields are descriptive strings for the record. These are based on the Display Names entered into Access Manager.

Three examples of sequences of messages generated as a result of various actions follow. This example network has two controllers (Office and Plant Room), two doors (Front Door and Plant Room Door), and three readers (Lobby, Plant Room [In]), and Plant Room [Out]).

Note the last log message “Input 8 active”. Inputs are programmable, but the defaults are:

Using a Conventional Remote Chat Client

A wide range of conventional Jabber chat clients are available. Here we see the Pandion Jabber client being used for simple monitoring by a human operator. Near the top of the window the operator typed in login admin. Below that you can see Access Manager reporting activity.

Note that if, unlike Pandion, the client does not support Jabber extension JEP-0022, each message will appear three times with a long delay between each. This is because the client is not acknowledging the messages sent by Access Manager.

Using an Embedded Remote Chat Client

Jabber IDs differ from email addresses in that you can append a piece of text called a resource. The session ID for a particular communications session is created with the aid of the resource part of the Jabber ID. For example, if the remote client logged on to Jabber server foo.bar as remoteclient@foo.bar, it would make its from field in the Jabber XML remoteclient@foo.bar/<resource>. A GUID formatted as a string is commonly used as a resource to ensure global uniqueness, eg:

    remoteclient@foo.bar/91c92690066f2aae53c8c8123a9c6f63

Various libraries are available to assist in the implementation of Jabber clients. When selecting a library you should review its feature set. It is recommended that in addition to basic functionality the chosen library should use TLS (Transport Layer Security) encryption, and provide an interface to a JEP-0022 subsystem

Message Acknowledgement

This is handled through Jabber extension JEP-0022, so no data need be passed in the body section of the XML. Instead the information is passed in another part of the XML in the form of five message events, three of which are not currently used by Access Manager. These indicate activity at the far end of the link. If using a Jabber code library (recommended), for your own convenience you should make sure it has a JEP-0022 interface.

Access Manager will request with each message it sends which acknowledgements it requires. The remote client should provide the required acknowledgements otherwise Access Manager will send each message three times. Also the remote client should request that it requires acknowledgements if it wants to ensure acknowledgements are sent to it. This behaviour is part of JEP-0022.

The notifications, are as follows:

*TLS encryption means that if the transmission arrived at all it will have arrived intact.