|
Version 6.3 |
|
| ||||||||||||||||||||||
Helper SettingsTo specify the External Helper program path and other parameters, open the General page in the Settings realm of the WebAdmin Interface and click the Helpers link: The checkbox next to the Helper name tells the Server to start the specified program as a separate OS process.
Helper ProtocolWhen the Helper program is launched, the Server sends commands to the Helper process via the process standard input. The Server reads the program responses from the process standard output. Commands and responses are text lines, ending with the EOL symbol(s) used in the Server OS. Each command starts with a sequence number, and the response produced with the Helper program starts with the same number. This method allows the Helper program to process several requests simultaneously, and it can return responses in any order. The Helper program can send information responses at any time. An information response starts with the asterisk (*) symbol. The Server ignores information responses, but they can be seen in the Server Log. The response lines generated with a Helper program should not be larger than 4096 bytes. Note: communication between the Server and an Helper program takes place via OS pipes, and many programming libraries buffer output data sent to pipes. Check that your Helper program uses some form of the flush command after it sends a response to its standard output, otherwise the response will not reach the Server. Helper programs are started with the CommuniGate Pro base directory as their current directory. Helper programs should not write anything to their standard error streams, unless they want to report a reason for the failure before quitting. CommuniGate Pro reads the program standard error stream only after the program has terminated, and if the program writes into that stream while processing Server commands, the program will be suspended by the OS when the standard error pipe buffer is full. The Interface Version command is used to provide compatibility between different versions of Helper programs and different versions of the CommuniGate Pro Server. The Server sends this command specifying the protocol version it implements:nnnnnn INTF serverInterfaceVersion where:
The Helper program should return the INTF response and the supported protocol version.
When the Server shuts down or when it needs to stop the Helper program, it sends the QUIT command, and then closes the process standard input. The Helper program should send the OK response and it should quit within 5 seconds. Sample session (I: - server commands sent to the program standard input, O: - responses the program writes to its standard output, COMMAND - a Helper-specific command):
The sample above shows that the Server does not wait for a response before it sends the next command, and that it can accept responses for several pending commands in any order - as long as each command receives a response within the specified time limit. External AuthenticationExternal Authenticator programs can be used to provide authentication, provisioning, and routing services using external data sources. The External Authenticator Interface protocol is based on the generic Helper Protocol. This manual describes the External Authenticator Interface Version 11. When a user should be authenticated using the clear text method, the Server sends the following command:nnnnnn VRFY (mode) name@domain password [loginAddress] where:
nnnnnn SASL(method) (mode) name@domain password key [loginAddress] where:
If the password is accepted, the External Authenticator should return a positive response:
If the password was not accepted, a negative response should be returned:
If the password is accepted, and there is an authentication response to be returned to the
client, a positive response with a quoted string should be returned:
SASL password verification requires that the External Authenticator program correctly implements
all supported SASL methods and algorithms. Alternatively, the External Authenticator program can return
the user plain text password, making the Server verify the password and calculate necessary authentication responses.
The user plain text password should be returned as a quoted string:
The External Authentication program can be used to retrieve plain text passwords from external databases. To retrieve a password, the Server sends the following command:nnnnnn READPLAIN name@domain where:
The program should return the user plain text password as a quoted string:
The External Authentication program can be used to process unknown names, too. For example, the program can consult an external database, check if the user exists in that database, create an Account, Alias, Group, Mailing List, or Forwarder using the CommuniGate Pro CLI/API, and return a positive response to the Server. In this case, CommuniGate Pro will re-try to open a Domain object with the specified name. To check an unknown name, the Server sends the following command:nnnnnn NEW name@domain relayType where:
If the program sends the OK response, the Server tries to find the name object in the domain Domain again. If the program sends the ROUTED address response, the Server takes the supplied address response and restarts the Router procedure with this address. The routed address gets a "can Relay" attribute, unless it is specified with the [NORELAY] prefix. If the program sends the FAILURE response, the Server Router returns a "temporary internal error" code (this code causes the SMTP module to return a 4xx error code, not a permanent 5xx error code). If the program sends any other response, the Server Router returns the "unknown user account" error. Sample session:
The Consult External for Unknown Domain Setting tells the Server to use the External Authenticator program when an unknown name is addressed. The External Authentication program can be used to assist in address Routing. If an address is routed to the @external domain, the address "local part" is passed to the External Authentication program using the ROUTE command:nnnnnn ROUTE <address> relayType where:
If the program sends the ROUTED address response, the Server takes the supplied address response and restarts the Router procedure with this address. The routed address gets a "can Relay" attribute if the address is specified with the [RELAY] prefix. If the program sends the FAILURE response, the Server Router returns a "temporary internal error" code (this code causes the SMTP module to return a 4xx error code, not a permanent 5xx error code). If the program sends any other response, the Server Router returns the "cannot route the address" error. Sample session:
authAccount is the name of the Account performing the provisioning operation. If it is not known, this account name and the square brackets surrounding it are omitted. The program should either send an OK response, or a FAILURE "errorCode" response. External Message FiltersExternal Message Filter programs are used for content filtering (anti-virus and anti-spam filtering). The External Filter Interface protocol is based on the generic Helper Protocol.
If the external program crashes, CommuniGate Pro suspends the Enqueuer process until the external program is restarted. External RADIUS HelpersExternal RADIUS programs can be used to provide additional checks for authentication operations performed via the RADIUS module, as well as to add additional attributes into RADIUS responses. The External RADIUS Interface protocol is based on the generic Helper Protocol.
nnnnnn LOGIN name@domain attributes settings where:
nnnnnn ACCEPT attributes where:
If the password was not accepted, a negative response should be returned:
nnnnnn ACCNT command name@domain attributes where:
nnnnnn OK where:
The attributes in dictionaries should use the attribute type numeric values as keys (for example 27 for Session-Timeout). The following attributes are interpreted as 32-bit integer values and they are encoded
as numeric strings in dictionaries:
The following attributes are interpreted as 32-bit IP addresses and they are encoded
as aaa.bbb.ccc.ddd strings in dictionaries:
The following attributes are ignored in Helper responses:
All other attribute values are encoded either as a String or
as DataBlocks. The Server uses the DataBlocks format for those
attribute values that contain bytes outside the hexadecimal 0x20-0x7F range.
If an attribute has multiple values, the attribute value is encoded as an Array. The following attributes are added to the attribute dictionaries passed to the Helper:
The Vendor-specific attributes are presented using keys with negative numeric values. The key absolute value is the "VendorID" value. For each VendorID, the associated element is a dictionary. This dictionary keys are Vendor-specific "vendor types", with associated "specific attributes". The "specific attributes" values can be stored as String, DataBlocks, Number, or Arrays of Strings, DataBlocks, and/or Numbers. Sample session (I: - server commands sent to the program standard input, O: - responses the program writes to its standard output):
Note: the Server can send several concurrent requests for the same target Account. Note: the External RADIUS program is called when the target Account is open. In a Dynamic Cluster system this means that External RADIUS programs should run on backend servers, and that External RADIUS programs running on different backend servers will never get requests for the same Account at the same time. External CDR ProcessorExternal CDR Processor programs can be used to process CDRs (Call Detail Records) generated with the Signal component when a call is attempted, established, or tiered down. They can also process CDR records generated with CG/PL applications. The External CDR Processor Interface protocol is based on the generic Helper Protocol.
If the External CDR Processor program is enabled, the Signal module generated CDRs and sends them to the program. When a CDR is composed, the Server sends the following command:nnnnnn CDR cdr_data where:
when the record is processed, the program should return a positive response:
External Load BalancerExternal Load Balancer programs are used to control software load balancers for the Dynamic Cluster installations. These programs should be installed and enabled on all Cluster members that can act as load balancers. For each "balancing groups" the Cluster Controller selects one of the available load balancers and activates it, while other load balancers work in the "backup" mode. The External Load Balancer Interface protocol is based on the generic Helper Protocol.
nnnnnn MEMBERS (ip-address [,ip-address...] ) (ip-address [,ip-address...] ) where:
nnnnnn LOCAL ip-address where:
nnnnnn STARTBALANCER When the Cluster Controller needs to deactivate this load balancer, the program receives the following command: nnnnnn STOPBALANCER External Application HelpersExternal Application Helper programs can be used to provide CG/PL applications with arbitrary data.. The External Application Helper Interface protocol is based on the generic Helper Protocol.
nnnnnn USER user@domain REQ requestData where:
nnnnnn RESP responseData where:
If the External Application Helper program is not running, any request immediately produces an empty response. External Banner SystemExternal Banner System programs can be used to provide XIMSS and other clients with "banner" data (advertising information that a client presents to the user). The External Banner System Interface protocol is based on the generic Helper Protocol.
nnnnnn BANNER bannerType [ accountName@domainName ] [ INFO bannerSetting ] [ PREFS bannerPreference ] [ PARAM paramData ] where:
nnnnnn RESULT resultData where:
nnnnnn BLOCK The specified bannerType is added to the list of "blocked" types. If any client requests a banner of a "blocked" type, an empty response is returned immediately, without calling the External Banner System program. If the External Banner System program is not running, any banner request immediately produces an empty response. |