This translation is older than the original page and might be outdated.


The Security Broker involves the implementation of a secure and reliable communications channel between terminals with XOne applications and the central server, providing a secure gateway of isolated resources. In this way, all the transmissions made under the communications protocol used by XOne have increased their security, providing protection against attacks via the web to the central services.
The use of this BROKER is combined with the following modules:


MODULES
Replica Server, both for data and for files.
Updates System, XOneLive Plus, to install and update apps and databases.
Integration with online connectivity utilities: JSON, XML, XMLRPC, SOAP, WSDL, SOA.
Compatible with the use of PUSH system.


Its use, combined with the security elements of the client, provides a security plus to XOne architecture, avoiding the exhibition of any component of the system facing the outside. This system avoids identity theft and denial of service attacks. To do so, different headers are sent for each communication, where a unique message identification frame is configured.


Once an application is set with the Broker, it is achieved that each and every one of the communications between the mobile devices and the central server are through WebSocket or Rest. The use of one or another way, that we will describe further, is made through the configuration of the devices modules.
That communications only are enabled under the SSL protocol, what allows the the encryption of the transmitted data.


The communications used in this environment, even having that intermediate Broker, are quite agile.
And they improve the performance of the proxys system developed previously by XOne. These improvements become obsolete the XOne Proxy.
This Broker system allows the nesting of as many levels as they deem necessary. Nevertheless, the use of some of them impacts on the system speed.




The Security Broker implementation provides different protections, depending on the module which the information exchange is being made with:


Replica Server


Double encryption of the communications, through those of the XOne protocol and later thanks to the use of SSL certificate.
The mobile device has no the real path of where the Replica Server is installed in. This is like this because of the following configuration:
- The device has a Mapping Identifier.
- The real path of the replica server, only is available in the Broker.
- El Identificador de Mapeo debe estar incluido en el sistema Broker, enrutando las comunicaciones al sistema correspondiente.
- Un único Broker permite emplear infinitos entornos XOne, si se considera necesario, o bien establecer un Broker por cada entorno, aunque no sería necesario.


Updates System XOneLive Plus


Encryption of communications via SSL.
The data infrastructure and the files of the central server become independents.
Independence of the updates system regarding the communication server and data manager. The infrastructure of folders necessary for its operation is also independent.



Integration with Online Connectivity utilities



Double encryption of the communications, through those of the XOne protocol and later thanks to the use of SSL certificate.
Security by session maintenance. It is necessary a session token that the server sends when it is authenticated and the Framework of the devices maintain them for the different communications between them.



Compatible with the use of PUSH System


It is possible to establish Push functionalities by using the security broker.




At the time to start up the Broker, we can opt by two options : WebSocket or Rest.

Following, we are going to describe the factors to keep in mind for its implementation:

It is necessary the incorporation of a new machine, that will be the one which host this new service. This machine must have Windows Server 2012 operative system or superior. An unique Security Broker may provide support to several environments. Also, it would be possible to establish a broker by each environment, according the client requirements.
If we choose to install the service with WebSocket configuration, in comparison with Rest:
- we will have a better performance.
- increase in speed in communications than the environment set with Rest.
- reduction of the overhead of this system.
- reduction of data consumption in the mobile devices.





A possible design of the architecture to implemement it would be the following one:


The features of this architecture are:

It is not necessary to have a VPN in the mobile devices to data cards level.
All the connections between the mobile device and the Central Platform are made by a single port.
The mobile devices are connected to a communications server, which the Security Broker will be implanted in. This server is independent of the Data Server and from the XOne Server (usual elements of the XOne architecture), and will be in charge to channel the traffic between the outside and the different services.
The system will be able to be set with as many Broker as required between the communications server and the XOne server.
The XOneLive communications in this architecture, also will be made with the protocol improved, for what is necessary to implant the module of XOneLive Plus.
To the communications system can be added the use of X509 certificate, such as we explain further on.





The necessary requirements for the Security Broker implementation are the following ones:

Windows Server 2012 64 Bits
Microsoft .NET Framework 3.5 with its Service Pack
Microsoft .NET Framework 4.0 with its Service Pack
Microsoft .NET Framework 4.5 with its Service Pack
Internet Information Server 7.0 or superior
Protocol WebSocket installed on IIS
The hardware requirements are the recommended ones by the operative system.





The data replica is one of the most attractive functionalities of the XOne Technology, since it allows that the mobile apps work independently of the existance of communication links among the terminals and the centers of data (servers).

It is important to bear in mind that one of the main needs of a mobility system is communication with the central,since the data entered in the terminals have to be incorporated into the management systems. In the same way, terminals must receive data from the exchange, so that mobile operators stay updated.


A common example is the seller who has to send their orders to the administration and receive the rates and customers with which to operate, without this data transmission, mobility applications would make little sense in business systems.
It is in this place where the replica takes its place, since it allows this communication to be carried out in an asynchronous, safe and unattended manner. When there are communications, the replica transmits and receives data. When there is not, the replica looks for ways to connect to communicate with the central. Meanwhile, applications can continue to work with local copies of the data, so users can continue working, even if there is no data link.

To intercommunicate the different devices that are being used in a project, Android, iPhone, PC, Windows Mobile , … a tool is needed to maintain the referential integrity of all the data transparently. The XOne data replication system allows this process to be performed without the relationships between records in each copy of the database losing coherence. From the point of view of the XOne data replication, what is handled are copies of data representing “equivalent” subsets of the central database (which contains all the data).
This equivalence implies that the data have to “mean” the same thing for the users, they are seeing the copy they are looking at, although internally the data is not represented in exactly the same way, due to differences in database systems employees, as well as the fact that copies of the devices do not have to contain all the data that exists in the exchange.

The XOne data replica is a client / server system . The central database is managed by one or several applications that make up the replica server. A replica client runs on each terminal connected to the system. For each of the Platforms, a specific client has been developed, which adequately exploits the possibilities of the execution environment. Through a proprietary protocol, over TCP / IP, for the exchange of commands and information, all encrypted at several levels, the systems are able to synchronize their databases. In this way, the clients send to the server the information generated by their users, receiving, in turn, data according to the criteria specified for each one of the replication clients. In addition, the entire database of operations sent and received by each client is stored in the central database.

The administration of the replica can be done in a centralized manner by managing configuration tables that allow each of the clients to be manipulated, decide which data is sent to each one, block access, control the number of operations per lot, etc. The replica tables of the server also allow monitoring the status of each client's connections, so that an administrator can know at all times which clients are behind, since when they do not connect, if there are errors in their terminal or in the data you have sent, etc.

The data replication system also allows connecting other copies of the central database without selectivity. These total copies also work with replica clients and can be used to link headquarters of the same company, to maintain local data servers that do not load the central database or to maintain a separate copy of the database on a geographically remote machine of the central server as backup or backup. This whole system works automatically, so you can keep copies of the data virtually in real time.

To distribute the data transmission geographically, the replica server can be distributed in several star-shaped nodes. In this way the devices of a zone can be connected to a machine that in turn centralizes the upload of this information to the central using a more powerful link and takes away work from the central server, since the selectivity of the clients of each region is would run on your particular server and not the central one. This mechanism also allows that when the links in the central node fail, the regions can continue to send their data against their own headquarters. This type of topology is called multimaster replica.



The replica server is responsible for preparing the data so that customers can receive them. It is also responsible for accepting the sending of customer data to place it in the central databases.


It consists of one or several services that perform the following tasks:

Accepting clients requirements. Client requests are commands for sending and receiving data, configuration and administration, etc. The commands are received via TCP-IP .
Managing the clients selectivity. The selectivity tables contain the rules that operations must comply with to go to each client of each database
Processing the data that the clients send for insert them into the databases.


It is important to keep in mind that the replica server can serve several databases at once, one for each application that the company has. In this way, different applications can be mobilized within the same company using the same replica server. Each database has its own set of clients and works independently of the others. In case a scalable solution is needed, the system administrator can choose to separate the databases on different replication servers with very few modifications to the configuration of the servers.


For each of these activities, different software modules (services) can be configured, which considerably improves the response of the server to a greater load. Simple configurations employ a single service to perform all tasks. When the load of the server increases, the components can be separated so that they distribute the load.

Interconnection of different database systems, installed on a server or replica client, depending on the device to be used


For any application, it is possible to have multiple database systems coexisting in the same development. Even if the central system has a database engine, such as Oracle, replica clients are not required to use this same database engine to work.


This heterogeneous system allows servers to install powerful databases capable of managing a large amount of information while mobile devices benefit from small database engines that consume little memory and processor.

In those cases in which the client has CPDs or databases already installed and working, you can benefit from these infrastructures to place the replica repositories there without having to duplicate any logistics or administrative structure, which makes the solution very attractive in terms of operating costs and administration.
In this way, it is possible to propose a development that presents an architecture similar to the following:


Selectivity


When designing the criteria of use of a mobile application, it is normal that each terminal does not have the complete information of the system to be able to perform the tasks for which it has been developed. In this way, it is possible that all needs are linked to criteria that depend on the user associated with the terminal or the region in which it operates.

In order to satisfy this need, a system based on SQL conditions is used to limit the information that has to be sent to each of the devices. These conditions make up what is called “selectivity”, and are established for each of the entities that are used, which may have been modeled in one or several tables in the central database. It is necessary to emphasize that the conditions are specific for each of the replication clients, although they generally have a similar structure for all the clients, changing only the values ​​of those variables that decide the destination of the operations.

However, it is not mandatory that this be the case, since different customers may have different conditions, as a result of the type of terminal they use and the limitations that each of them may have; see for example the comparison between a Blackberry terminal and a PC. Even for similar terminals, it is possible that the user profiles are different, and therefore the requirements within the application; for example, the needs of a self-sales user have nothing to do with those of a commercial director who controls that sales.


Currently there are two different models for selectivity processing:


EXTERNAL SELECTIVITYThe server component performs the massive processing of the information by blocks of parameterizable size. It requires a greater use of replication server resources than the internal system, but it is easier to implement, since it does not require any kind of work on the database server.
INTERNAL SELECTIVITYThis model, very similar to the previous one, makes use of the potential of the database manager, integrating in it all the selectivity calculation processes, instead of leaving these tasks to an external application. This achieves a more optimal performance since it is the database engine itself that performs the tasks.



Integrity Maintenance


To achieve a more efficient operation of the applications, XOne in its designs uses relationships between tables by means of autonomic IDs. Once the data to be sent to the replication clients is limited as a result of the selectivity, the relationships between said tables do not have to maintain those same ID values. To solve this problem, XOne has a system that allows generating a unique registration identifier within the entire system.
This identifier will allow, through the use of a relationship resolution mechanism, to establish the correct links in all the terminals, thus maintaining the integrity of the data.

The processing of these links is done automatically and completely transparent, so when developing the application is not necessary to take it into account. This allows you to benefit from the efficiency of the auto-numeric links without worrying about coherence problems between different databases.

Security in the transmissions


In order for the replication client to initiate a communication session with the server, XOne has its own binary protocol. All the exchange of commands and client-server data is done by default using a symmetric encryption that depends on the system in which the server is executed. The keys to perform these operations are exchanged between the client and the server at the time of the session and are generated randomly for each new session.
The cryptography algorithms used are the same in all systems, but in general the way in which the keys are derived, the amount of bits used to carry out the cryptographic functions, etc. is usually varied.
This is why the client the first thing he has to do when he starts a replication session is to identify the server. There is a command for this, which tells the client what type of server is serving him. When this is determined, the client can first know if it has an adequate key generation mechanism for that server, and subsequently generates an adequate session key. With this key, the login is started, during which the client's random key is exchanged with the server's key.

From this moment, all the commands will be sent encrypted with this pair of keys. For the exchange of the symmetric keys you can use a pair of RSA keys, or an X509 certificate depending on the server license acquired by the user. The cryptography algorithm and the key length will also depend on the operating system and the license acquired.

When a client needs a cryptographic algorithm that is not available on the server, the replica can not log on. For environments that require a higher level of security, the client and the server can be configured to regenerate the session keys (rekeying) periodically and force a new key exchange, in order to make the cryptographic analysis difficult. of the data flow.

When a client owns several cryptographic systems at his disposal he will seek to use the most secure of those he shares with the server, so the most restrictive system possible will always be used, given any combination of client and server. Through this mechanism of exchange of cryptographic “capacity” a mechanism is established that allows to evolve without having to stop the whole system to update it, which minimizes administrative costs.
As the replication server can be placed behind an HTTP proxy, in addition to the cryptography of the XOne system, an HTTPS channel can be used to send the data, so that these would travel through an SSL channel in addition to being encrypted using the own cryptography.

In addition to this mechanism, the client can choose to allow access to his server only through a VPN or IPSec network, so in addition to the two previous methods, the information would travel in an encrypted form through the virtual network, with the that there would be three concurrent levels of encryption in customer information, of which at least two are entirely in the hands of the system administrator, which makes it highly reliable for those applications where a high level of security is required. \ Blackberry clients also have a security level of their own in their private network, whether or not they have a BES infrastructure.


Clusterization


Projects that have a very large number of replication terminals or that process a very large amount of data can benefit from the possibility of splitting the work between separate components. In case that even then the tasks are too many for a single server machine, these components can be separated into different machines, so that each of them performs a different task.

You can even have several machines sharing the same activity (i.e. Attending client requests) so that when the load increases the response to the replica clients does not suffer degradation due to excess load on the server.


Load Balance


If you can have several servers to host an application, you can choose to use this module to control the workload of each of them. Thus, the general scheme would be similar to the one in the following image.


Replica Servers in cloud environments


The solutions in the form of cloud allow to have environments of high reliability, scalability and redundancy at very convenient prices. XOne has components that can be executed in these environments taking advantage of their connectivity to avoid the end customer hardware and software maintenance costs associated with the server machines.

They also allow a customer to benefit from the additional security environment offered by the cloud. Replication clients do not need to know that they are connecting to a server in the cloud, so the system can be developed in a local testing and development environment and subsequently published in the cloud or hired from a provider without having to change anything.

Documental Replica


Transfer of files and images. This mechanism allows certain fields in the database to be used as references to files that will be transmitted between the client and the server. Optionally these files are also sent to the replica clients, depending on the design that is generated for the application.
The different frameworks can use these files to show them to the client or for other tasks related to the operation of the applications. To do this, special types of fields have been created that are displayed differently from conventional data records.
You can also use these files in scripts.

The transmission of files gives priority to the integrity of information on the speed of transfer, bearing in mind that in many cases the transmission can be affected by the line, the lack of coverage or even the interruption of the service for a considerable time. Therefore the sending of data is prioritized and the sending of files is subordinated to the availability of bandwidth and processor in the device.

The dimensions of the blocks are calculated taking into account the availability of communications, so that the number of retransmissions is minimal and that in case of falling transmission is not lost time and data rate used so far starting the shipment again . It is important to remember that most data plans have a ceiling on the volume of information to be transmitted, so that the smaller the amount of information retransmitted as a result of falls or link failures, the more efficient the plans of information will be exploited. end user data.

Due to the fact that the same data replication channel is used for sending file blocks, this is done using the same security protocols, so that sensitive information can be transmitted as documents attached to the application (ie photocopies of documents of identity, health cards, etc.).

Conflicts Resolution


Data conflicts occur when two or more different terminals try to access the same record in different copies of the same database. This type of problem can occur in any replication system that mixes data (publish / subscribe systems do not have this kind of difficulty, but would not be appropriate for many mobility applications), but in the case of asynchronous systems such as the one that employs XOne, is much more critical, because conflicts can not be solved in real time or through a system of distributed transactions.

The XOne data replica uses a system of priorities and time control to resolve conflicts. It is important to bear in mind that when the operations that are problematic do not affect the same fields of the same registry, the system does not consider them conflicts, so that not only greater efficiency is achieved, but also avoiding losing modifications due to conflicts.

This is helped by the way in which the XOne machinery generates data updates, incrementally replicating only those changes in those fields where they have occurred and not by sending complete records. In the long run, the only way to avoid conflicts affecting the system and delaying replication processes is to design the applications correctly.
This type of knowledge is offered in the training courses offered by XOne as part of the training of the personnel in charge of designing mobility applications.

Operations Log (log)


You can establish different trace levels of the processes generated by the replication server, from basic levels, which record only the errors, to the most detailed to carry out load studies, efficiency optimizations, etc.

The records of operations can be written in the location that the user or administrator decides and they are partitioned so that they can be manageable if needed for some analysis. The logs are daily and are separated by database, so for each application you can have a different log level, avoiding affecting the performance of databases that are in production by others that are in development or in tests.



The Platform has its own protocol for sending and receiving information between mobile devices and the server side.

Its main features are:

FEATURES
UNATTENDED COMMUNICATION The user of the mobile application will not have to force the synchronization mechanisms at any time. This process can become totally transparent to the user, so that he is not even aware of it. This does not prevent access to the replication service controls to check their status, force communications or modify their behavior. These management activities are subject to permissions defined by system administrators.
SECURITY IN THE COMMUNICATIONS Although the system can work locally, regardless of whether there is connectivity, once it is available, the sending and receiving of information is managed. The synchronization processes are protected against possible connection losses, so that the integrity of the information can be guaranteed. In addition, in the case that the connection is interrupted, when starting it again the transfer will continue from the point where transmission confirmation was obtained from the server. Therefore, even if there are connection losses, the synchronization mechanisms allow not restarting the entire process, guaranteeing security and efficiency in the exchange of information. Both the client and the server are prepared so that these possible cuts of communication do not affect the integrity of the data (lost records, duplicates, etc.). The system prioritizes the integrity of the information before the speed of sending, with which any optimization speed is done in a way that subordinates the security of never losing a data.
VARIABLE BLOCK SIZES Depending on the application design, type of terminal or even the communication channel used for the replication process, it is possible to modify the block sizes that are exchanged between the client and the server. In addition, it is possible to set different values ​​for the data sending and receiving cycles. This factor must be taken into account when working in heterogeneous environments, since it is possible to optimize the times used to synchronize client and server. This aspect does not penalize users who have better connectivity, adjusting the process with a smaller block size, to favor terminals that have a lower speed modem or a worse data coverage area, since they are reduced the sizes only for those terminals. Thus, for example, the sizes defined for a replication client that connects through a local network or ADSL can be significantly greater than those of a terminal that, even if it has 3G connectivity, is in an area where the type of coverage does not allow it move from a GPRS connection. In the Platforms that allow it, the replica clients can choose to change the size of the block dynamically based on the response of the data channel. This allows to send a greater quantity of information when the channel is more idle or has better coverage and to reduce the size of the packages when there is little coverage or the network fails more, so that although the replica works more slowly, when it is necessary to retransmit, the amount of data committed is less.
MAXIMUM USE OF THE TERMINAL When replication clients are written for each mobility environment, the lowest level native code that each environment allows is used. This allows the process to be as efficient as possible and have the least possible amount of device abstraction. Each environment, including each version of the same environment, has clients that are exactly matched to their characteristics, so that both the network and processing characteristics for the replication work are maximized.
SMART SWITCHING OF NETWORKS It is possible to configure the switching between different networks depending on the needs of the application. Thus, for example, for a logistics application, in which a start of workday is generated, triggering the request of certain data to the main server, such as its work route, it is possible to force the replication client to connect through WIFI, modifying later this behavior to use 3G connection while the rest of the distribution process is carried out.