User Access Control

XX/1 provides user access level security through transaction filter. XX/1 ships a filter called XXSecurity that implements a file based (XML-format) user authentication and transaction auditing. The filter is enabled/disabled by adding or removing the XXSecurity library to the transaction filter list of the main configuration file xxscfg.xml.

...
<transactionfilter>
<filter name="Security" lib="xxsecurity" config="securitycfg.xml"/>
</transactionfilter>
...

The file securitycfg.xml contains the information on were the user and group profile files reside:

<security>
<!-- Folder with user and group profile files -->
<profiles>profiles</profiles>
</security>

 

 

Profile Files

Group and user profile files have the same format. At runtime, the group profile is merged into the user's profile. The files are in XML format MUST have exactly the same name as the userid (case-sensitive) with the.xml file-suffix, i.e. sampleuser.xml or samplegroup.xml. Modifications apply immediately - a server re-boot is not necessary.

<user name="sampleuser" password="password" group="samplegroup">
    <access>
        <interfaces native="yes" admin="no"/>
        <tc>
            <test select="provider[.='Amadeus'] and provider[@session='PT']" error="restricted provider"/>
        </tc>
        <req>
            <test select="" msg="" error=""/>
            <test select="" interface="native"/>
        </req>
    </access>
</user>
NodeDescription
user

Root node - create one XML document per user or group.

Attributes:
name = user id
password = password (optional)
group = name of group (optional, must match profile file name)

The user provides the identity information with each transaction along with the transaction control header.

accessUser's access rights
access/interface

User's access rights to server interfaces

Attributes:
native = access to native provider transactions (yes/no)
admin = access to remote administrator's interface

access/tcList of one or multiple transaction control header test conditions that can be applied to the request tc XML document
access/tc/test

Transaction control header test condition. If evaluates false, processing of the transaction is refused.

Attributes:

select = XPath select statement to be applied (context = root)
error = Error string to be returned if select statement fails

access/req/test

Request message content test condition. If evaluates false, processing of the transaction is refused.

Attributes:

msg = request message name where test to be applied
select = XPath select statement to be applied (context = doc-root)
error = Error string to be returned if select statement fails

 

 

Transaction Log

XX/1 provides transaction logging capabilities through transaction filter or through the Dynamic Trace Log Facility built into the XXE Engine. The XXSecurity filter discussed in the User Access Control section also implements transaction auditing, that can be used in combination with the acess security. The filter is enabled/disabled by adding or removing the XXSecurity library to the transaction filter list of the main configuration file xxscfg.xml. Auditing is enabled and disabled though the <audit> node in the user or group profile file. The output is a comma delimited text file (csv) with a customized layout. The name of the file will be generated from the user's name and the current time information. A new revolving file will be generated automatically depending on the specified interval. The file will contain the date, time-in, time-out and customized values as listed in the output/value nodes.

<audit>
    <output folder="log" msg="*" interface="" cachesize="8192" interval="daily" delim=";">
        <value select="provider" from="tc" test=""/>
        <value select="provider/@session" from="tc" test=""/>
        <value select="name()" from="req" test=""/>
        <value select="name()" from="rsp" test=""/>
        <value select="OriginDestination/Departure/CityCode" from="req" test=""/>
        <value select="count(OriginDestination/Flight)" from="rsp" test=""/>
    </output>
</audit>
NodeDescription
audit/output

Output format specifications

Attributes:

folder = directory where output files are created
cachesize = memory file write cache size in bytes - recommended size is 64000 for best performance
interval = file name revolving interval - can be hourly, daily, weekly or monthly
delim = output column separator
msg = name of request message for which this output matrix applies. Default is all messages.
interface = client interface for which output matrix applies. Default is "standard". Possible option is "native".

audit/output/value

Column with customized output value from transaction data

Attributes:

select = XPath select value for exctracting XML transaction data
from = context document where select statement is applied - can be tc, rsptc, req or rsp
test = optional XPath test condition that is applied to context document and that must evaluate true for select statement to be executed

 

 

Dynamic Trace Log

The Dynamic Trace Log feature is built into the core XXE Engine and allows you to log XX/1 session traffic into log files on the server, which can be either plain text files or compressed XTR files for the XXTraceConsole utility.

To enable the Dynamic Log a log file path has to be specified as system property in the main configuration file xxscfg.xml.

<xxscfg>
  <sysprops>
      <prop name="dynamiclog" value="log"/>
      <prop name="dynamiclogfiletype" value="xtr"/>
   </sysprops>
PropertyValueDescription
dynamiclog

Specifies name of file folder (relative to current directory)

Location where dynamic log files are stored.

The actual file name is determined by the <log> element text value supplied by the client in the <tc>.

If this property is not defined then logging is disabled.

dynamiclogfiletype

Specify file type (suffix) of log files.

xtr: XXTraceConsole
txt: Plain Text File
dlog: Plain Text File

Default value is dlog.

Dynamic Logging affects scalability as they are thread and inter-process safe.

These log files are never reset automatically and must be deleted manually when needed.

 

Encryption

XX/1 supports two different types of encryption:

  • A free PGP-style proprietary 128-bit encryption for high performance and scalability and
  • an TLS1.2 (SSL) 256-bit industry standard encryption for maximum security (requires purchase of certificate).

The PGP encryption is built into the SOAP interface library and activated on demand by the client application.

The SSL layer is provided through a separate SOAPSSL interface library that is listening on a different port (default 443).

<if name="SOAPSSL" lib="soapsslif">
    <port>443</port>
    <bind></bind>
    <traceid>SOAP</traceid>
    <threadpool>0</threadpool>
    <certificate>PASS Consulting Corp</certificate> 
    <certdbdir></certdbdir>
</if>

The recommended method is PGP since XX/1 already provides access security on a higher level.

Upgrades and Configuration Updates

All XX/1 product upgrades and configuration updates require a server re-start, as all parameters, tables, scripts and session pools are pre-loaded or compiled at startup for maximum performance (user profiles are the only exception). Seamless updates and upgrades can be managed smoothly through load balanced environments. When stopping the XX/1 server, all external interfaces are shut down and pending transactions will be completed.