2.1 Authorization XML bridge

Connecting XML bridge to the target system is initiated by command bind (see chapter 6.2). If this is a connection via unprotected channel, connection is created and prepared for use in the moment a reply <bind Status="OK"/> was received. In case of connection via a protected channel authorization will be requested between the “bind request” and “bind reply”.

The application is informed about the authorization request by receiving element auth. This element has no attributes, but it contains sub-elements method. It is a list of supported types of authentication. If the bridge supports the SASL method then, under the corresponding element, we can also find a list of supported authentication mechanisms – elements of mechanism.

Before we begin with the description of the individual types (methods) of authentication, we must emphasize one thing. All that will seem in the following paragraphs to be useless complication is in fact done for the sake of basic security directive: “Sensitive information (credentials), such as passwords, must never be transferred from the source of authentication information (user) to the target (authentication authority) in an open form.” Credentials are transformed using mathematical algorithms, which have the property of being “one-way”. That means that their outcome (“hash” or “digest”) are functions of the “sensitive” data, but there is no method of reconstructing from the result (in reasonable time) the values, from which the result was calculated. After this modification it is possible to transfer the authenticated data via unsecured communication lines without risk. Possible capturing will not be of any use to the “villain”. Nevertheless authentication authority is able to determine from this information whether it was generated using knowledge of the access keys (passwords).

Let us assume that the communication library will be, with respect to the source of authentication information, always in one of the following positions:

1) The source of the authentication information (login and password) is the user and the communication library is used directly by the application used by the user. A typical example are all “fat-client” configuration tools;

2) Applications that connect to the branch office PBX via the communication library, have no user interface and the authentication data are stored in its configuration. Such applications usually carry out some kind of monitoring of the activities of the branch office PBX;

3) Communication library is used by the application server. Users connect to this server via a different application and this server mediates, in some form or another, functions of a PBX. A question arises here – how to secure the transfer of authentication information from its source (user application) into the communication library (application server). Communication library is a tool allowing carrying out this without “loosing the flower” and that even in case the client application is, for example, internet browser.

In the first two cases the communication library receives authentication information directly and the library itself will ensure safe authentication, but in the third case the library has only the role of a mediator. Transforming “sensitive” information into secure form in the way defined by the selected authentication mechanism must be carried out by the application, into which the user inputs the information. The library only sends these authentication data for evaluation to the authentication authority. It is worth mentioning that the branch office PBX NetStar is able to authorize an application on the basis of rights assigned to its host environment.