Patent Description:
Such a system is computer network that generally comprises one or more application servers hosting a plurality of applications, so called CRS applications. For instance, these applications are used to provide online services for a variety of tasks, such as booking plane tickets or hotel rooms, searching for travel offers and corresponding fares.

The CRS applications can be accessed from anywhere around the world, at any time and by any device (e.g. desktop, laptop, mobile phone, tablet). As a result, there is a need to provide a secured access to these CRS applications and thereby ensure the security of the data that are distributed through the CRS applications.

Upon receipt of a request emitted by a user to access an application, the application server hosting the application may grant access to the application. In order to protect access and prevent misuse of the CRS, security components are provided within the CRS. For instance, a login security server (LSS) may be provided to grant or deny access for a user requesting access to an application, based on data contained in a central generic access control (GAC) file and in the user access request.

More specifically, each application within the CRS requiring an access control is provided with an identification component. Even though all these identification components are ultimately connected to a centralized LSS, each application has to implement its own identification component connected to the LSS.

As a consequence, the user of each application is confronted with a different user interface for identification. Furthermore, the connection between the identification component and the LSS is not always guaranteed due to incompatibilities resulting from the differences in structure of the authentication message, or differences in versions between the identification components, etc..

Furthermore, once the user is identified, he/she should be able (or not) to access services by the applications executed on the distributed application servers in the open back-end (OBE) of the CRS computer network. The access or denial of access to the service is based on the respective user access rights which are stored in the GAC.

The GAC is a module that hosts a centralized database or file that contains the account information of all registered users including their respective access rights for each application hosted by the distributed servers. The GAC database may comprise several nodes to ensure stability in case one of the nodes fails another node may be solicited to process the user request.

The GAC module may be implemented in SQLite. The GAC file or database is stored within a cache memory on every OBE and wherein the OBE has to duplicate at fixed intervals the file from a central storage within the LSS.

Due to the ever-increasing amount of users of the CRS services, the size of the GAC SQLite file increases rapidly. For instance, the GAC file can triple within three years. The size of a GAC is now typically of the order to <NUM> GB (Giga Bytes). As a result, due to the vast amount of different CRS applications contained in the CRS architecture, it has become increasingly difficult to retrieve, duplicate and store each GAC file.

In existing CRS architectures, the GAC module distributes frequently user data to all applications across a large number of distributed servers (typically <NUM> to <NUM>) to apply user account changes in particular with regard to their access rights. With a typical CRS architecture comprising up to <NUM> servers, about <NUM> GB of data need to be distributed across the network every hour.

<CIT> presents multi-user web service sign-in client side components. The currently authenticated user account of a first application of a client is transferred to another application of a client. Furthermore, a common credential store is used to share data for a plurality of user accounts associated with a client between a plurality of applications of the client, and for the applications to output multi-user interfaces having portions corresponding to the plurality of accounts.

<CIT> describes a method and an apparatus for generating user group identifiers using a permissions matrix. The permissions matrix includes an entry that is associated with a row and a column of the permissions matrix. The row of the permissions matrix is indexed with a first role and the column of the permissions matrix is indexed with a second role. A data structure implementing such a method can include, for example, a user group identifier matrix. Alternatively, a method is disclosed in which the expiration of a user group identifier is detected. In such a case, the user group identifier is updated by accessing a user group identifier matrix.

<NPL> - a growing trend of organizations migrating to RBAC because of the economic benefits that RBAC provides, and the ease of administration. In order to deploy an RBAC system, one requires to first identify a complete set of roles. This process, known as role engineering, has been identified as one of the costliest tasks in migrating to RBAC. Several approaches have been proposed that mostly use data mining techniques to discover roles. However, most of them do not consider the existing roles and try to define everything from scratch, which is not acceptable for organizations that already have an RBAC system in place. Takabi et al. formally defines the problem of mining role hierarchy with minimal perturbation and present StateMiner, a heuristic solution to find an RBAC state as similar as possible to both the existing state and the optimal state. Takabi et al. presents experiments to demonstrate the effectiveness of our approach.

Therefore, there is a strong need to reduce this amount of information in order to reduce the network overall traffic and optimize usage of network resources such as bandwidth, processing usage and energy. This need has become all the more important that the number of applications and users keeps on increasing worldwide at a rapid pace.

The current security framework implemented within existing CRS computer networks configured for identifying the users of online services and to allow or deny access to these services suffers from the above drawbacks and deficiencies. The present invention has been devised to address one or more of the foregoing concerns.

According to a first aspect there is provided a computer network adapted to provide secured access to applications for a user, said computer network comprising :.

The central login panel is a single authentication interface that can be advantageously shared amongst all applications to provide the user credentials (login, password) to the logon security server for centralized authentication.

The centralized user identification component and the central login panel constitute a single entry point that prevents all applications from implementing their own login panel, thereby simplifying the overall system architecture while providing a unified security framework. This feature enables to prevent the proliferation of proprietary identification modules which are difficult to control and update.

Besides, non-transactional information that are in the local cache memory can be advantageously displayed to the user, thereby reducing the amount of data that is transmitted through the computer system for granting or refusing access to an online application. The fact that only transactional data such as the user credentials are transmitted over the network contributes to reduce the response time to perform user authentication.

According to a feature, the central login panel is associated with a cache memory adapted to store static non transactional data associated to said at least one requested application, at least part of said static non transactional data being displayed to the user by the central login panel, upon display of the central login panel.

According to another feature, the static non transactional data are distributed to the cache memory by means of a Content Delivery Network architecture.

This architecture is particularly efficient for delivering the static non-transactional data on a wide scale with short response time.

According to another feature, the non transactional data are selected by the centralized user identification component based on a user current location and said at least one requested application.

According to another feature, the central login panel is hosted in a server located close to the user, such as the server being located in the same country as the user location. This feature enables to a short response time.

According to another feature, the centralized user identification component is hosted by one of the servers of the computer network, in particular the login security server.

As a result, the amount of data that is transmitted through the computer network namely to the various application servers can be greatly reduced. which enables lower bandwidth requirements and shorter response times.

According to another feature, the generic access control file size reducing component is further configured for splitting the purged central generic access control file into application-specific files so as to form a purged application-specific generic access control file prior to storing said file to said cache memory.

According to another feature, the generic access control file size reducing component is adapted to access the generic access control file upon request.

According to another feature, the generic access control file size reducing component is adapted to intercept and analyze the access grant or denial commands that are transmitted from the centralized user identification component to said at least one application server and update the generic access control file based on the analysis.

According to another feature, the generic access control file or sized- purged or reduced generic access control file is an SQL-compliant file or database, in particular SQLite-compliant.

According to another feature, the centralized user identification component is implemented with a light HTML (HypertextMarkup Language)/JQuery framework using cross-origin resource sharing technology as a communication language.

In a further aspect, a method for centralized user identification in a network comprises, at a centralized user identification component of the network:.

According to further aspects, the method comprises method steps corresponding to any one of the computer network functions set out above.

In a further aspect, a computer program product comprises program code instructions stored on a computer readable medium to execute the method steps according to the methods set out above when said program is executed on a computer.

In a still further aspect, a computer system acting as a centralized user identification component of a network is adapted to interface with at least one application server and the login security server of the network, and said centralized user identification component is configured to: receive an access request from the at least one application server, the access request comprising a list of at least one requested application; displaying a central login panel to the user, said central login panel being adapted according to the at least one requested application; receive identification data of the user from the central login panel; transmit said identification data and the list of at least one requested applications to the login security server; retrieve from the login security server an access grant or denial command for each of the at least one requested application; and send said access grant or denial command to at least one application server of the network to grant access to the at least one requested application.

In addition, in some embodiments, the computer system is further configured to execute any one of the functionalities set out above.

The present mechanisms will now be described according to a particular embodiment, by way of example only, and with reference to the following drawings in which :.

The computer network <NUM> as depicted in <FIG> is a computer reservation system that may be implemented to provide secured access to online applications for a user U. The present embodiment is described in the context of travel booking.

The computer network or CRS <NUM> comprises an application server <NUM> hosting a plurality of applications <NUM>,. For the sake of simplicity, only one application server is considered in the present embodiment but the description also applies when a plurality of servers are distributed across the Internet to provide a plurality of online services to users.

Each constitutive element of the computer network <NUM> is adapted to communicate by means of conventional means, namely via the Internet.

In order to access an online service provided by one or more applications on the application server <NUM>, the user U sends S1 by means of a terminal <NUM> an access request R1 to the application server <NUM>. The terminal <NUM> may be a personal computer such as a laptop or desktop or a mobile phone or a tablet. The access request is sent via conventional communications means (e.g. via <NUM>, Wi-Fi, Ethernet, etc). The access request R1 is generated by a client of the application server installed on the user terminal <NUM>. The access request R1 comprises a list of at least one requested application on this application server <NUM>. In other embodiments, several applications may be requested on distinct application servers (not represented).

Upon receipt of the access request R1, the application server <NUM> transmits or forwards S2 the access request R1 to a centralized user identification component <NUM> (abbreviated CUIC). The CUIC <NUM> is adapted to interface with the application server <NUM> and a login security server <NUM> (abbreviated LSS).

The LSS <NUM> is configured for deciding access for the user U based on data contained in a central generic access control file <NUM> and in the access request R1.

A generic access control (abbreviated GAC) module <NUM> is provided to store at least the access rights of registered users for each application. By definition, a registered user is a user for whom an account has been created in the computer network. In the present embodiment, the user account data including the user access rights respective to all applications are stored in the form of a single file <NUM> in a memory of the GAC module <NUM>. For instance, this file complies with SQL (Structured Query Language) and more particularly with SQLite which is well particularly well-adapted for querying and maintaining the database. In other embodiments, this information may be stored in a database, for instance a relational database. This database may comply with SQL and more particularly with SQLite.

More specifically, the CUIC <NUM> is configured for :.

In the present embodiment, the CUIC <NUM> is implemented with a light HTML/JQuery framework using cross-origin resource sharing technology as a communication language. This technology is particularly advantageous as it supports all kinds of HTML requests with a high level of security.

The CUIC <NUM> is preferably hosted in the LSS <NUM> so as to improve the latency of the user identification. In other embodiments, the CUIC <NUM> may be hosted by any one of the servers of the computer network <NUM>, wherever deemed more appropriate.

The central login panel <NUM> (abbreviated CLP) is an interface that is common to all applications. It is displayed directly on the user terminal <NUM> upon receipt of the access request by the CUIC <NUM>. The CLP <NUM> constitutes a single entry point by means of which any user requesting access to an application can centrally submit his/her credentials (i.e. registered login and password) or identification data before being directed to the requested application. Implementing the CLP <NUM> prevents from implementing a separate login panel within each application individually. This feature is particularly useful as each user interface for authentication normally has its own security requirements such as password encryption.

The CLP <NUM> may be hosted in a server <NUM> located close to the user. The proximity of this hosting server <NUM> and the user is advantageous to display more rapidly the CLP <NUM> on the user terminal <NUM>.

Therefore, implementing the CUIC <NUM> together with the CLP <NUM> according to the present invention substantially simplifies the implementation of authentication in the computer network <NUM>. This is particularly advantageous when adding new applications hosted on additional distributed application servers or upgrading security constraints or parameters for all applications at once. Implementing the CUIC <NUM> and the CLP <NUM> for more than one application advantageously provides a unified identification user experience on any of the CRS online services with a single point of entry, thereby enabling system administrators to focus on a single component and contributes to improving the CRS computer network security.

The CLP <NUM> may be associated with a local cache memory <NUM> adapted to store static non transactional data associated to the requested applications. At least part of said static non transactional data may be displayed to the user by the CLP <NUM>, upon display of the CLP. By definition, non-transactional data designate all types of non-sensible information (e.g. text, image, video, sound) excluding personal data provided by the user to perform a transaction (e.g. credit card details transmitted for booking a flight). For instance, non-transactional data may include general information which is specific to the requested application, such as the logo of the airline company from which the user intends to book a flight. Thus, the non-transactional data may be advantageously used to customize the CLP <NUM> according to the user access request R1 received by the CUIC <NUM>. Providing the non-transactional data in the local cache memory <NUM> is particularly advantageous for reducing the loading time of the information to be displayed to the user on the CLP <NUM>, especially when this information comprises high-resolution images and/or videos.

The static non transactional data may be distributed to the cache memory <NUM> by means of a Content Delivery Network architecture. This architecture is particularly well adapted to deliver efficiently the static non-transactional data on a wide scale with short response times.

The non-transactional data may be selected by the CUIC <NUM> based on the user current location and the requested application. In that case, the user location may be included in the access request R1 by the user client installed on the user terminal <NUM>. By default, the user location may be obtained from the IP address of the user terminal <NUM> used to send the access R1 by the terminal.

The CUIC <NUM> may hosted by one of the servers of the computer network <NUM>, in particular the LSS <NUM>. Preferably, the CPL <NUM> is hosted in a server located close to the user.

Authentication may be performed using a security standard such as Open ID Connect. This security standard has the advantage that it is widely used.

Once the user U has submitted his/her credentials (function S4) via the CPL <NUM> displayed on the screen of his/her terminal <NUM>, these are received by the CUIC <NUM>.

From the user access request R1 received from the application server <NUM> and from the user credentials received from the centralized CLP <NUM>, the CUIC <NUM> generates a second request R2 that includes the user credentials and the list of requested applications to the LSS <NUM> (function S5).

Upon receipt of the second request R2, the LSS <NUM> consults GAC file <NUM> maintained by the GAC module <NUM> (function S6) and retrieves therefrom the access rights of the user associated with the requested applications in the (function S7). Based on the retrieved access rights, the LSS <NUM> determines whether access should be granted or denied to the requested application for the identified user.

In response to the second request R2, the LSS <NUM> provides an grant or denial command for each of the applications to which access is requested by the user U according to the first request R1. This grant or denial command is retrieved by the CUIC <NUM> from LSS <NUM> (function S8).

Then, the grant or denial command is sent by the CUIC <NUM> to the application server <NUM> hosting the requested applications (function S9). Upon receipt of this command, the application server <NUM> grants or denies access to each of the requested applications to the user (function S10).

According to another aspect, the CRS computer network <NUM> may further comprise a generic access control file size reducing component <NUM> configured for :.

The generic access control file size reducing component or GAC file size reducer <NUM> (abbreviated GACSR) advantageously reduces the size of the generic access control file by removing therefrom any redundant and/or obsolete data.

According to the data structure employed to store the information the GAC file <NUM> (such as the user identification data and the corresponding access rights for the various applications), some redundancies may be suppressed as the same user access rights may be repeated in multiple fields of the GAC file or database. The GAC file <NUM> purged from redundant and/or obsolete data may be stored as a purged GAC file <NUM>' in a memory of the GAC module <NUM>.

According to the present embodiment, the application server <NUM> further comprises a cache memory <NUM> adapted to store one or more size-reduced GAC files <NUM> obtained from the GAC file <NUM>. These size-reduced GAC files <NUM> may be fully or partly duplicated from the purged GAC file <NUM>'. These files are transferred to the cache memory <NUM> of the application server <NUM> by conventional network communication means.

For instance, the inventors have shown that redundancy removal implemented by the GACSR <NUM> in a CRS computer network comprising about <NUM> application servers enables to drastically reduce the amount of GAC data transferred to the application servers down to <NUM> GB per hour, as compared with <NUM> GB per hour without any redundancy removal.

To further reduce the size of the size-reduced GAC files stored in the cache memory <NUM> of the application server <NUM>, the GACSR <NUM> is further configured for splitting the purged central generic access control file <NUM>' into application-specific files so as to form a purged application-specific generic access control file <NUM>" prior to storing said file to said cache memory <NUM>.

The implementation of the GACSR <NUM> drastically reduces the size of the SQLite GAC file to be duplicated from a master version obtained from the GAC file <NUM> (e.g. purged and application specific GAC file) and sent to the cache memory <NUM> of the application server <NUM>.

By sending only relevant application-specific data to the respective application servers, an update performed centrally on the original or master version of the GAC file may be applied locally to the application servers much more rapidly than if the full content of the original GAC had to be sent to all application servers regardless of the applications hosted by these servers.

The implementation of the GACSR <NUM> enables to efficiently reduce the network overall traffic and optimize usage of the network resources such as bandwidth, processing and energy. As a result, the performances of the CRS computer network <NUM> are drastically improved. In particular, users may access the requested applications with lower latencies and quicker data transfers to the application servers to facilitate the propagation of updates to the application servers. Splitting the GAC file into smaller files containing up-to-date data pertaining to the same application server allows to send dedicated updates to each application server separately. This splitting advantageously avoids having one single point of failure in case of file corruption.

The GACSR <NUM> is adapted to access the GAC file <NUM> upon request. This request may be issued automatically, for instance periodically at predetermined time intervals to maintain the file up-to-date on a relevant time basis.

Alternately, the GACSR <NUM> is adapted to intercept and analyze the access grant or denial commands C that are transmitted from the CUIC <NUM> to the application server <NUM> and update the generic access control file based on the analysis. In that case, the GACSR <NUM> interfaces not only with the GAC module <NUM> that hosts the GAC file <NUM> or different versions thereof (e.g. purged GAC file <NUM>') but also with the LSS <NUM>.

Preferably, the GACSR <NUM> interfaces with the LSS <NUM> that hosts the GAC module <NUM> by means of a single interface in order to minimize the number of interfaces that the system administrators have to manage.

<FIG> is a schematic block diagram of a computing device <NUM> for implementation of one or more embodiments, in particular servers such as the login security server <NUM>, the application server <NUM>.

The computing device <NUM> may be a device such as a workstation. The computing device <NUM> comprises a communication bus connected to:.

<FIG> visualizes a method algorithm according to some embodiments. In S1, the user terminal <NUM> transmits and the application server <NUM> receives the access request R1. In S2, the application server <NUM> transmits or forwards S2 the access request R1 to the CUIC <NUM>. In S3, the CUIC <NUM> displays the panel on the user terminal and prompts the user to enter credentials (e.g. user ID or ID for the requested application). In S4, the user terminal submits the user or application ID to the CUIC <NUM>. In S5, the CUIC <NUM> transmits the user or application ID to the LSS <NUM>. In S6, the LSS <NUM> sends the user or application ID to the GAC <NUM>. In S7, the GAC sends the access rights for the user or application back to the LSS <NUM>. In S8, the LSS <NUM> sends the access grant or denial to the CUIC <NUM>. In S9, the CUIC <NUM> sends the access grant or denial to the application server <NUM>. In S10, the application server <NUM> sends the access grant or denial to the user terminal <NUM>.

The executable code may be stored either in read only memory <NUM>, on the hard disk <NUM> or on a removable digital medium such as for example a disk. According to a variant, the executable code of the programs can be received by means of a communication network, via the network interface <NUM>, in order to be stored in one of the storage means of the communication device <NUM>, such as the hard disk <NUM>, before being executed.

The central processing unit <NUM> is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to embodiments of the invention, which instructions are stored in one of the aforementioned storage means. After powering on, the CPU <NUM> is capable of executing instructions from main RAM memory <NUM> relating to a software application after those instructions have been loaded from the program ROM <NUM> or the hard disk (HD) <NUM> for example. Such a software application, when executed by the CPU <NUM>, causes the functions S1-S10 described in reference to <FIG> and <FIG>, respectively, to be performed.

Any function of the algorithm shown in <FIG> may be implemented in software by execution of a set of instructions or program by a programmable computing machine, such as a PC ("Personal Computer"), a DSP ("Digital Signal Processor") or a microcontroller; or else implemented in hardware by a machine or a dedicated component, such as an FPGA ("Field-Programmable Gate Array") or an ASIC ("Application-Specific Integrated Circuit").

Although the present mechanisms have been described hereinabove with reference to a specific embodiment, they are not limited to this specific embodiment, and modifications will be apparent to a skilled person in the art which lie within the scope of the claims.

Claim 1:
A computer network (<NUM>) adapted to provide secured access to applications for a user, said computer network (<NUM>) comprising :
at least one application server (<NUM>) hosting a plurality of applications (<NUM>,...,<NUM>.n), said at least one application server (<NUM>) being adapted to receive an access request (R1) emitted by the user and to grant access to at least one of the plurality of applications (<NUM>,..., <NUM>.n);
a login security server (<NUM>) configured for deciding access for the user based on data contained in a central generic access control file (<NUM>) and in the access request (R1);
said computer network (<NUM>) further comprising a centralized user identification component (<NUM>) adapted to interface with the at least one application server (<NUM>) and the login security server (<NUM>), said at least one application server (<NUM>) being configured to transmit the access request (R1) to the centralized user identification component (<NUM>), said access request (R1) comprising a list of at least one requested application (<NUM>,....,<NUM>.n);
and said centralized user identification component (<NUM>) is configured for :
receiving the transmitted access request (R1);
displaying a central login panel (<NUM>) to the user, said central login panel (<NUM>) being adapted according to the at least one requested application (<NUM>,...,<NUM>.n);
receiving identification data of the user from the central login panel (<NUM>);
transmitting said identification data and the list of at least one requested applications (<NUM>,...,<NUM>.n) to the login security server (<NUM>);
retrieving from the login security server (<NUM>) an access grant or denial command for each of the at least one requested application (<NUM>,..., <NUM>.n);
sending said access grant or denial command to the at least one application server (<NUM>);
wherein the computer network (<NUM>) further comprises :
a generic access control file size reducing component (<NUM>) configured for : retrieving data contained in the central generic access control file (<NUM>), said data
including access rights to said applications for a plurality of users ;
eliminating redundant and/or obsolete data from the central generic access control file (<NUM>) so as to form a purged central generic access control file (<NUM>');
a cache memory (<NUM>) associated with the at least one application server (<NUM>) for storing at least part of the data contained in the purged central generic access control file (<NUM>).