WO2025162892A1 - Method for managing the calling of an application programming interface by a client - Google Patents

Abstract

The invention relates to a method for managing the calling of an application programming interface (API) by a software client (C), the client (C) having an identity (ID), the call being intended to execute an element (M) interfaced by the application programming interface (API), the method comprising the following steps carried out for a given call before accessing the interface (API): • extracting (XTR) the values (V) of the arguments passed as parameters by the software client (C) in the call of the application programming interface (API); • authorising (AUT) the given call to access the interface (API) according to the identity (ID) of the software client (C) and the extracted values (V); • if the given call is authorised (AUT) to access the interface (API), creating (ADD) a rule (R) comprising a value (V') obtained following the execution of the called element (M), relating to a step of subsequent authorisation of another call.

Description

Method for managing the call by a client of an application programming interface

The technical field is that of IT.

More specifically, the invention relates to a method for managing the call by a client of an application programming interface.

An application programming interface (API) is a way for a given software to give other software access to data or functionalities provided by the given software. The software that provides access to data or functionalities or in general to one of its elements provides a service to other software which are generally referred to as the clients of the service offered. This is called a client-server architecture. In this term, the concept of service (access to data or functionality or any other element through an application programming interface) is confused with the concept of server (a real or virtual machine on which one or more software programs that provide services run). This term is, however, widely used by those skilled in the art.

Client-server architectures and the use of APIs are widespread in computing. In such an architecture, a computer server is placed in a communications network in which clients are also present. Clients can send requests to the server via the communications network, allowing access to the various services offered through an API. The server will perform an access control to verify whether the client is authorized to access the requested service, and will provide it if so. The requested service could be, for example, the provision of data that will then be read by the client for further processing or the execution of a specific action. In general, a server can be queried by several different clients.

The request will be issued by the client using a given communication protocol. One protocol that can be used in this context is the HTTP protocol (acronym for Hyper Text Transfer Protocol ). This protocol is originally used to allow the transfer of information from a website to a web browser as well as web browsing in general, but the GET and POST requests present in the HTTP protocol can also be used to transfer data from a client to a server and receive data in return. This is called a web service. It can also be noted that browsing websites in general is done according to a client-server architecture, where the web browser plays the role of a client, the web server is a server, and the request from the client to the server consists of retrieving the content of a website from a server in order to be able to display it in the browser. But it is possible to use the HTTP protocol within a client-server architecture and the provision of web services to retrieve any type of data, or to control any type of action, without being limited to browsing and displaying websites. In the case where the client-server architecture uses HTTP as the communication protocol, the access control system used will be that of the HTTP protocol itself. In this case, a client will send a request using the HTTP protocol to a server identified by an address given by a uniform resource identifier, or URI (acronym for Uniform Resource Identifier ).

An API call is typically broken down into two elements. The first is the name of a called method; the second is the argument value(s) passed as parameters to the called method. For example, in the case of a web service, the called method will be defined by an HTTP protocol verb (for example, the verb GET) as well as by the called URI, and the called argument value(s) can be passed as parameters in the HTTP call. Calling the method allows access to any type of element of the service.

Let's take as an example an API that allows you to know the roaming status of a mobile phone. A telecommunications operator can define and deploy in its networks a Web service that allows you to obtain this information, or any other technique that allows you to offer an API. In the case of a Web service, the information will be obtained, for example, by making the following call:

GET http:/API/roaming_status?tel_num=’+33123456789’

Other APIs can be accessed at http:/API. In the example above, the method called is called roaming_status and a parameter called tel_num is passed as an argument, with the value +33123456789, which is the phone number for which the roaming status is requested.

In return, the client will receive a string containing the requested information. For example, a string of 'roaming=yes_country=Thailand' indicates that the requested phone is indeed roaming and is located in Thailand. Other response formats can of course be defined. In addition, the method arguments can be passed in other formats, for example, JavaScript objects using JSON ( JavaScript Object Notation ) or objects written in XML ( Extensible Markup Language ).

The example given above is in the context where the application programming interface is programmed as a web service but other API deployment techniques exist, such as CORBA (acronym for Common Object Request Broker Architecture ) or SOAP (acronym for Simple Object Access Protocol ) technology.

State of the art

An important aspect of client-server architectures and application programming interfaces is the access control technique used. A given resource must only be accessible by an authorized client. To achieve this, an access control system is implemented. Access control ensures that a given client, when calling an API to obtain a resource, is both identified and authorized to call the API method.

In the case where the client-server architecture uses HTTP as the communication protocol, the access control system used may be that of the HTTP protocol itself. In this case, as we have seen, a client will send a request using the HTTP protocol to a service identified by an address given by a uniform resource identifier, or URI (acronym for Uniform Resource Identifier ). The request will then be accepted or refused by the web server hosting the web service identified by the URI according to the conditions given by the HTTP protocol. The client provides in a header of the request its identifier and a password or a cryptographic password hash, depending on the authentication method chosen. If the client is authorized to access the resource, that is to say the URI, and if the password corresponds to the client's identifier, the request will be processed by the web server and the resource accessed by the client.

In client-server architectures, the access control system is limited to checking that the identified client has the authorization to call the method it calls and blocking it if this is not the case. To take the example given above of accessing the roaming status of a mobile phone, a client authorized to access the GET http:/API/roaming_status API can make this call for any value of the tel_num parameter, that is, for any mobile phone number.

This situation has drawbacks.

Since access control only applies to the called method, an authorized client will be able to access the requested method for all possible values of the arguments passed as parameters to the method. To return to the example of the API providing the roaming status of a mobile phone, this information can be of interest to companies outside the telecommunications sector. A bank, for example, may detect that payments are being made by credit card in Thailand and suspect fraud. By consulting the roaming status of the mobile phone of the owner of the credit card in question, the bank can obtain information on the location of the owner and confirm or deny that his credit card is the victim of fraud, if he is currently in Thailand. A telecommunications operator may therefore find it advantageous to sell a bank access to the API providing this roaming status. But the telecommunications operator must also protect the confidentiality of its customers' data. However, granting a bank access to the API will allow it to know the roaming status of all mobile phones managed by the telecom operator and not just those belonging to the bank's customers. In the case of legacy systems, it is not possible, or at least very difficult, to modify the programs developed. These may, for example, have been developed in programming languages that are no longer in use. Or, the program was developed by a supplier who declares that they can no longer or will not modify it, or at least not for an acceptable price. In the absence of the possibility of modifying the legacy system, it is therefore not possible to open access to its APIs to a third party for reasons of protecting the confidentiality of its customers' data.

This situation is common. Still in our example of the roaming status of a mobile phone, the API may have been initially developed for the internal needs of the telecommunications operator's information system, by a telecommunications systems equipment manufacturer. In such a development, for internal needs, it was not seen as interesting to be able to differentiate between different API clients. The supplier may refuse to modify the development for a reasonable price. The only solution is then a contractual solution, that is to say, to ask an external user of the API to limit their use of the API to arguments for which this use is authorized but without being able to ensure by an IT tool that this limitation is respected.

Another drawback of the current situation is the lack of scalability of access control. A given client may or may not be allowed to call a given method without specifying how the rules governing this access can evolve.

The invention improves the situation.

• Extraction d’une valeur des arguments passés en paramètre par le client logiciel dans l’appel de l’interface de programmation applicative ;
• Autorisation pour l’appel donné d’accéder à l’interface en fonction de l’identité du client logiciel et de la valeur extraite ;
• Si l’appel donné est autorisé à accéder à l’interface, la création d’une règle comprenant une valeur obtenue à la suite de l’exécution de l’élément appelé, ladite règle créée étant relative à une étape d’autorisation ultérieure d’un autre appel.

According to a first functional aspect, the invention relates to a method for managing the call by a software client of an application programming interface, said software client having an identity, said call aiming to execute an element interfaced by the application programming interface, the method comprising the following steps carried out for a given call before accessing the interface:

• Extraction of a value from the arguments passed as parameters by the software client in the call to the application programming interface;
• Authorization for the given call to access the interface based on the software client's identity and the extracted value;
• If the given call is authorized to access the interface, creating a rule including a value obtained as a result of the execution of the called element, said created rule being relative to a subsequent authorization step of another call.

Thanks to the invention, an access control is carried out which is also based on the analysis of the values of the arguments which are passed as parameters to the element called when calling the application programming interface. The element which is intended to be executed following the call to the application programming interface belongs to a software and hardware system. This element of the system which is called can be for example a method, which will execute one or more calculations and return data, or execute various actions, or a database query which will then simply provide one or more data in response, or any other computer element. The called element is a software element which relies for its execution on different hardware and software elements present in a larger system, interfaced by the application programming interface. This system will most often be a legacy system, which cannot be modified, but the invention can be applied to recently developed systems.

In one embodiment, the method also comprises a step of verifying the identity of the software client. In this case, the access control is carried out at the time of verifying the identity of the software client, i.e. at the time when it is checked that the client is authorized to call the interface.

In all cases, the control over the values passed as parameters of the call, i.e. the authorization step, is carried out before accessing the interface and therefore the execution of the element targeted by the call. As this verification is carried out before accessing the interface of the called element, it is done outside the software system that is interfaced by the application programming interface. In this way, access control that performs fine-grained management of access rights can be deployed even when the interfaced system is a legacy system, which cannot be modified.

Furthermore, the method comprises, if the given call is authorized to access the interface, a step of creating a rule comprising a value obtained following the execution of the called element, said created rule relating to a subsequent step of authorization of another call.

In one embodiment, creating a rule includes adding a rule to a rule base.

Thanks to this rule creation, the access control system according to the invention is scalable. Access control is based on a set of rules authorizing or not authorizing the client's access to the interface depending on the values of the parameters of the call to be authorized. Access control will depend on the results of the execution of the element called by the software client. This allows the system to evolve but also to easily provide a rule base with the rules necessary for its operation. During the first implementation of the method, the creation of rules will make it possible to easily create a set of authorization rules for subsequent uses of the method.

According to a first particular mode of implementation of the invention, the rule created is a rule authorizing a subsequent call from the same software client to the same application programming interface.

In this embodiment, the form of the rule created or added to a rule base is specified. This is only an authorization rule, and for exactly the same client and for the same call. This mode makes it easy to populate the rule base with the authorizations necessary for using the application programming interface.

According to another embodiment, which may be implemented alternatively or cumulatively with the previous mode, the rule created is associated with a validity period.

With this implementation, the set of rules used to define access authorizations evolves over time. An authorization can thus be given temporarily, in order to be able to carry out an operation for a limited time only, then prohibit it in order to protect the resource accessed by the call. This type of temporary authorization can particularly well apply to e-commerce operations such as the purchase of a basket collected on an e-commerce site or to operations for updating a customer account, such as validating a new password.

According to one embodiment, which may be implemented cumulatively with the previous embodiment, the validity period associated with the added rule is determined by a value obtained following the execution of the called element.

According to one embodiment, which may be implemented alternatively with the previous mode, the validity period associated with the added rule is a value fixed in advance.

Thanks to these two embodiments, the functioning of the evolution over time of the rules is specified. This evolution can be controlled by the interfaced system which provides, at the same time as the values which define the added rule, its validity period. Or the validity period is defined a priori which means that all the rules end up expiring after a certain time. These two modes can be combined, namely that the two modes can apply depending on the nature of the added rule, or the duration defined in advance can only apply if the validity period is not transmitted by a value obtained following the execution of the called element.

According to another embodiment, which may be implemented alternatively or cumulatively with the previous modes, if the call is not authorized after querying the rule base, an error is returned to the software client.

With this embodiment, information is provided to the software client if its access to the application programming interface is denied for the values of the arguments submitted as parameters. The software client can then modify its call if necessary or transmit the information to users or other software components. Its information is provided without the element or the system interfaced by the application programming interface having to intervene.

According to another embodiment, which may be implemented alternatively or cumulatively with the previous embodiments, the call is a call to a Web service using the POST verb and a rule created is a rule authorizing a subsequent call from the same software client to the same Web service using one of the verbs GET, HEADER, PUT or PATCH.

This implementation makes it easier to create rules. The client software is allowed to make an API call with a POST verb. In return, a reference is obtained, which can be used by a call with another verb, and this subsequent call is authorized by the rules.

According to another embodiment, which may be implemented alternatively or cumulatively with the previous embodiments, the call is a call to a Web service and the arguments of the called method are present in a computer object using JSON notation.

With this embodiment, the invention is applied to web services, which form a very widespread category of client-server architectures. The values of the arguments passed as parameters of the called methods can be grouped into a computer object using JSON notation. A tool such as JSONpath can then provide access to the values in question present in the object.

• Un module d’extraction d’une valeur des arguments passés en paramètre par le client logiciel dans l’appel de l’interface de programmation applicative ;
• Un module d’autorisation pour l’appel donné d’accéder à l’interface en fonction de l’identité du client logiciel et de la valeur extraite, ledit module d’autorisation étant apte à créer une règle comprenant une valeur obtenue à la suite de l’exécution de l’élément appelé lorsque l’appel donné est autorisé à accéder à l’interface, ladite règle créée étant relative à une étape d’autorisation ultérieure d’un autre appel ;

According to a first material aspect, the invention relates to a management entity managing the call by a software client of an application programming interface, said software client having an identity, said call aiming to execute an element interfaced by the application programming interface, the management entity comprising the following modules:

• A module for extracting a value from the arguments passed as parameters by the software client in the call to the application programming interface;
• An authorization module for the given call to access the interface based on the identity of the software client and the extracted value, said authorization module being able to create a rule comprising a value obtained following the execution of the called element when the given call is authorized to access the interface, said created rule being relative to a subsequent authorization step of another call;

and characterized in that, for a given call, the extraction and authorization steps are all carried out before accessing the interface.

According to an embodiment of the first material aspect, the management entity further comprises a rule base, said rules relating to the authorization for the call to access the interface.

According to another material aspect, the invention relates to a computer program capable of being implemented by a management entity, the program comprising code instructions which, when executed by a processor, carry out the steps of the management method defined above.

Finally, according to another material aspect, the invention relates to a data medium on which is recorded a computer program comprising sequences of instructions for implementing the management method defined above.

The data carrier may be any entity or device capable of storing the programs. For example, the carrier may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means such as a hard disk. On the other hand, the carrier may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention may in particular be downloaded from a network such as the Internet. Alternatively, the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question. The program according to the invention may use any type of computer technology in terms of compiled, interpreted programming languages, or a combination of both as well as in terms of operating systems.

Brief description of the figures

The invention will be better understood on reading the following description, given by way of example, and made with reference to the appended drawings in which:

represents a software client making a call to an application programming interface and a management entity managing this call according to the invention.

illustrates an example of steps implemented within the framework of an embodiment of the invention.

illustrates another example of steps implemented within the framework of another embodiment of the invention.

Detailed description

There represents a software client C, which has an identity ID. The also represents a software system S. This system S comprises an element M, for example a computer method. The element M is interfaced by an application programming interface API. The also represents a management entity 100 in charge of managing a call from the client C to the API programming interface.

• Un module 101 de vérification CHK de l’identité ID du client logiciel C ;
• Un module 102 d’extraction XTR des valeurs V des arguments passés en appel ;
• Un module 103 d’autorisation AUT de l’accès à l’interface ;
• Une base de règles DB.

In the embodiment shown in the , the management entity 100 comprises the following elements:

• A 101 module for CHK verification of the identity ID of the software client C;
• A module 102 for extracting XTR values from the arguments passed in the call;
• A 103 module for authorizing AUT access to the interface;
• A DB rule base.

In other exemplary embodiments, the management entity 100 does not include a verification module 101 or a rule base DB.

The client C, the management entity 100 and the system S are connected to each other by a communication network not shown in the . This may be the Internet network, or a private network, or a combination of several networks. The connection between the client C and the management entity 100 may be made, for example, via the Internet network, while the management entity 100 will then communicate with the system S via a private network.

The software client C runs on hardware that has the hardware architecture of a conventional computer. This hardware includes in particular a processor, a RAM type random access memory and a read-only memory such as a Flash or ROM type memory (not shown in the figure) and may include input-output devices such as keyboards and/or screens (not shown in the figure). In all cases, the hardware on which the client C runs includes communication means that allow it to access one or more communication networks. This hardware may be, for example, a computer or a smartphone or hardware components of a cloud architecture .

The software system S is also hosted in hardware that has the hardware architecture of a conventional computer. It includes in particular a processor, a RAM type random access memory and a read-only memory such as a Flash, ROM type memory (not shown in the figure) and may include input-output devices such as keyboards and/or screens (not shown in the figure). In all cases, the hardware on which the client C runs includes communication means that allow it to access one or more communication networks. This hardware may be, for example, a computer or a smartphone or hardware components of a cloud architecture or a server.

The element M present in the system S is called through the API interface. It can be a computer method, a query to a database or any other computer element. The element M includes the execution of a software part on hardware elements that can belong to the system S or be deported to external hardware elements in the case of a cloud architecture.

The software client C and the system S form a client-server architecture, that is to say that the system S offers, through the application programming interface API, the possibility for several software clients C to obtain data or to perform operations by making a call through the API interface. In the example shown here, the operation performed through the API interface is the call of the method M. The same API interface can be used to call other elements of the system S. And in addition, the system S can include other interfaces giving access to other software and hardware elements. In this way, the client C is not a monolithic program but uses data and functions rendered by the system S.

Many architectures are possible. For example, the software client C can be a mobile application running on a smartphone and which will call elements of the system S through the API interface and possibly other interfaces to obtain certain data or perform certain operations. The system S will then be a software that can run on one or more hardware servers or in a cloud architecture. The client C can also be an application hosted on a personal computer, or a web application that runs virtually in a web browser. These architectures can also use, for both the execution of the client C or the system S, virtual machine techniques or containerization of software components.

The application programming interface (API) can be implemented using several possible computing techniques. For example, the software system S can be integrated into a web server and the API interface will then be a URL offered by the web server. Other techniques are possible such as SOAP or CORBA.

The management entity 100 also has the hardware architecture of a conventional computer. This hardware includes in particular a processor, a RAM type memory and a read-only memory such as a Flash, ROM type memory (not shown in the figure) and may include input-output devices such as keyboards and/or screens (not shown in the figure). In all cases, the hardware on which the management entity 100 runs includes communication means which allow it to access one or more communication networks and in particular to be in communication with both the software client C and the system S.

The nature of the management entity 100 may, in certain embodiments, depend on the technique used to interface the element M of the system S. In the case where the system S is interfaced by a Web interface, for example, the management entity 100 may be an element of the Web server which provides access to the API interface. Other embodiments are possible depending on the interfacing technique chosen.

In any case, the management entity 100 is distinct from the system S. The system S is generally a legacy system, which cannot be modified, even if the invention can also be applied to the interfacing of new systems S.

An example of a possible embodiment of the invention is then the following.

The software client C sends a request to the API interface of the system S to execute a method M and passes values V as parameters of this request. This request or call to the API interface is first processed by the management entity 100 before any execution of an element belonging to the system S. For example, the system S is a web service and can be accessed by sending HTTP requests to it. These requests are then managed by a web server and the management entity 100 can be part of the web server's access control system.

The module 101 of the management entity 100 will first check CHK the identity ID of the software client C. For example, in a web service architecture, the identity ID of the client C is transmitted in a header of the HTTP request. In addition to the identity ID, the client C will transmit a password or a cryptographic certificate. This security data is used by the module 101 to verify that the identity ID presented by the client C is indeed the correct one. Other identity verification techniques are possible other than those used by web servers. If the CHK verification of the identity ID of the software client C fails, the method according to the invention does not continue and an error code can be sent to the software client C or a security alert or any other appropriate measure.

In other exemplary embodiments, the management entity 100 does not include a verification model 101 of the identity ID of the software client C. This identity is considered to be provided to the management entity 100.

The module 102 of the management entity 100 will then proceed to extract XTR values V from the arguments passed in the call of the method M. In the case of a Web service, for example, the request called by the client C may include a computer object of the JavaScript language recorded according to the JSON notation. A tool such as JSONpath will make it possible to find the values V passed as arguments in this object according to the JSON notation. Still in a Web service architecture, the values V can be defined in the URL parameters of the HTTP request made by the client C. If the API interface uses techniques other than a Web architecture, other methods will be used to extract XTR values V in accordance with the interfacing technology used.

It can be noted that in the case of a classic Web server, the access control system does not perform the XTR extraction of the V values. Indeed, a Web server will simply check whether a client C whose identity ID is verified CHK can or cannot call an API interface by accessing the corresponding URL. If the call is authorized for the client C whose identity ID is verified CHK, the V values are transmitted to the system S without any additional control.

The XTR extraction operation is presented here as taking place after the CHK verification operation of the identity ID of the software client C, but in other embodiments, this operation takes place before or the two operations are carried out in parallel. The order of execution of these two CHK verification and XTR extraction operations is not important in carrying out the method according to the invention.

The module 103 of the management entity receives the verified identity ID CHK of the software client C and the values V of the parameters passed as arguments to the call to the method M. In the example embodiment represented by the , this data allows the module 103 to query the rule base DB, which is represented in the figure by a question mark. The presence or absence of a rule concerning the possibility for the client C with the verified identity ID to make a call to the API interface for the method M with the values V will lead the module 103 to authorize or not the call in question. Other embodiments are possible, which do not use a rule base DB. The authorization AUT can for example be directly determined by the module 103 from information present in the module 103 itself.

In this case, in the example shown in the , the call in question is authorized AUT by module 103, which is represented by the OK symbol next to the question mark which represents the query of the rule base DB. The call of method M with the values V by client C can therefore continue up to the application programming interface API.

An essential characteristic of the method according to the invention, present in all embodiments, is that the operations of CHK verification of the identity ID (which can be carried out outside the management entity 100 and is not generally part of the method according to the invention), of XTR extraction of the values V and finally of AUT authorization of the call are executed before access to the interface of the call in question, therefore before the slightest execution of an element of the system S linked to the call. In other words, all the operations of the method according to the invention take place outside the system S, which allows them to be carried out within the framework of a legacy system S which cannot be modified under any circumstances. The main advantage of the invention lies in this possibility of application to an API interface of a legacy system S which cannot be modified.

Once the call is authorized AUT, it is transmitted to the API interface. The call then accesses the API interface. This API interface will then transmit the call to the element of the system S which will carry out the method M, with the value(s) V as argument. The execution of the method M interfaced by the application programming interface API will produce the value V'. Other values can be produced depending on the nature of the method M called. Actions not producing return values can also be carried out by the system S. This value V' is obtained by the software client C as a result of the client C calling the method M through the API interface. In certain embodiments of the invention, not shown in the , the obtained value V' will be used by the management entity 100 to add a new authorization rule AUT to the rule base DB using the obtained value V'.

There , for its part, presents an example of steps and message exchanges implemented within the framework of an embodiment of the invention.

In the example illustrated by the , the architecture of the software client C and the system S which includes the element M interfaced by the API interface is a Web architecture. The messages exchanged to access the services of the system S interfaced by the API interface, and in particular the element M, are HTTP requests including HTTP verbs such as GET, POST, PUT etc. Other implementations are possible using other application programming interface query techniques.

In the example of the , the software client C issues an HTTP request to a system S to obtain the roaming status of a mobile phone. In our example, the system S may be a legacy system, present in the information system of a telecommunications operator. In a classic Web architecture, the access control of the Web server only concerns the possibility for a given client C to request a Web service. It is up to the Web service to ensure that the request can relate to such and such a value. In our example, the system S cannot be modified and provides the roaming status for a given number num in return for an HTTP GET status(num) request without checking that the software client C is legitimate to obtain this information. This situation is classic for a system S intended only to provide information to other applications in the information system of the telecommunications operator which are therefore by nature legitimate to obtain the information from the system S.

It may be relevant for the telecommunications operator that manages system S to open up the possibility of accessing the web services of system S to third-party partners. For example, a bank may wish to know the roaming status of its customers in order to improve its fight against fraud. Software client C may then be an element of a bank's information system which, in the presence of suspicious activity abroad in the account of one of its customers, will be able to check, using the roaming status, whether the customer is actually present abroad or not. However, it must be ensured that software client C will not be able to access information relating to customers of the telecommunications operator other than those who have given their authorization for this information to be accessible.

However, the S system cannot generally be modified. Fine-grained access rights management cannot be added to it. The access control implemented by the web server to provide access to the S system API interface is also not suitable. The invention is particularly useful in this situation.

The software client C, for example a component of a bank's information system, wants to query the application programming interface (API) of the system S to find out the roaming status of a mobile phone. This information can be accessed by sending the HTTP request GET status(num1) to the API interface.

The management entity 100 is, for example, in this embodiment, a component of the web server that provides access to the API interface in the form of HTTP requests. The management entity 100 will check CHK the identity ID of the software client C and extract XTR the values V from the call to the API interface. This is the telephone number num1. In other embodiments, this verification is carried out by another entity that then provides and confirms the identity ID of the software client C to the management entity 100.

There represents in a rectangle the operation carried out by the authorization module 103. In the example shown here, the module 103 proceeds by querying a rule base DB. Other embodiments are possible not involving a rule base. Two rules present in the rule base DB indicate on the one hand that the query of the roaming status request is possible in general for the client C whose identity ID is verified and furthermore that this query is authorized OK for the telephone number num1.

The module 103 of the management entity 100 will therefore authorize AUT access to the API interface of the call by the client C whose identity is ID of the request giving the roaming status for the telephone number num1. This call therefore continues towards the application programming interface API which interfaces the system S. The latter is ready to respond and will therefore respond to the software client C. As the query technology of the API interface is a Web service, the system S first responds with a 200 OK information message which is a standard message of the HTTP protocol.

System S, which is a legacy system, without modification, responds and gives the roaming status through the API interface, which it does every time it is requested and is available. The information is transferred to the software client C.

Later, the software client C wants to query the roaming status for the phone number num2.

In this case, querying the rule base DB by module 103 shows that the software client C whose identity ID has been checked CHK is not authorized NOK to obtain the roaming status of the phone number num2. The information can be explicitly given in a rule of the DB, as shown in the , or, in other examples, the absence of a rule explicitly authorizing client C's access to the information will be sufficient for module 103 not to authorize AUT to continue the call and to access the API interface.

The call from client C is therefore not authorized AUT and the management entity 100 responds with a 403 Forbidden information message which is a standard message of the HTTP protocol to the software client C. Other standard messages can be used preferably, for example the 404 Not Found message in order not to provide information to a possible attacker. In this exemplary embodiment, the call is not authorized AUT to access the API interface by the management entity 100 after querying the rule base DB, and consequently, an error is returned to the software client.

Here, the call is not forwarded to the API interface of system S. Since this legacy system could not be modified, if the call had been forwarded, system S would have executed the call and provided a response. Customer C, an element of a bank's information system, in the absence of the invention, could access the roaming status of any mobile phone, which would be a significant security vulnerability for the telecommunications operator's information system. The invention therefore makes it possible to open the API interfaces of legacy systems S to third parties, without having to modify them, and while preserving their security.

The example of the is given in the context of opening the API of an information system in the field of telecommunications but the invention can be applied in any other industrial or commercial field in which it is desired to open the interfaces of information systems.

There , for its part, presents another example of steps and message exchanges implemented within the framework of an embodiment of the invention.

In this example, as in that of the , the architecture of the software client C and the system S is a Web architecture and the messages exchanged to access the services of the system S interfaced by the API interface are HTTP requests including HTTP verbs such as GET, POST, PUT etc. Other implementations are possible using other application programming interface query techniques such as SOAP or CORBA or others.

In the example of the , the system S is an element of the information system of a telecommunications operator. The invention can be applied in any industrial field in addition to that included in the examples presented here.

In our example, the objective is to allow a client of the operator to carry out certain management operations by itself. To do this, a software client C can call the API interface of the system S by sending an HTTP POST request mgmt(num) to indicate its desire to carry out certain management actions (translation of the English management , abbreviated to mgmt) for the telephone number num in the future.

The management entity 100 will carry out an access control as described in the example of the in order to ensure that this request is authorized. The software client C can be, for example, a mobile application, hosted in the smartphone whose telephone number is num and this application can have a unique identifier ID. In the example presented here, the authorization module 103 uses a DB rule base to decide whether or not a given call can access the API interface. The management entity 100 can then have in its DB rule base that only the software client C provided with the identifier ID is authorized AUT to post the HTTP request POST mgmt(num) to the system S. This authorization method AUT, already described in the , is not further detailed here.

In return, the system S transmits to the client C the information message 200 OK which is a standard message of the HTTP protocol then provides the client C with a value V', namely in this example a management identifier hdlr1 (abbreviated from the English handler ) which will subsequently allow the software client C to carry out management operations by addressing other requests to the API interface of the system S.

In one embodiment of the invention, the management entity 100 retrieves this value V' in return and uses it to create a new rule. This operation is represented in the by a rectangle in which a rule is added to the DB base, said rule consisting of authorizing the identifier ID (that of client C) to carry out the management operation data_inc for the management identifier hdlr1. In other embodiments, the created rule can be managed outside a DB rule base, for example by programming another system. This management operation has for example the effect of increasing the data plan allocated to the telephone number corresponding to the management identifier hdlr1. Other rules, corresponding to other management operations, can of course be added.

In the following, as shown in the , the software client C can actually call the API interface with the HTTP request PUT data_inc(hdlr1). This request is authorized AUT by the management entity since the corresponding rule was previously added to the rule base DB using the return value V', namely the management identifier hdlr1. The effect of this request will then be, for example, to increase the data plan assigned to the telephone number corresponding to the management identifier hdlr1. On the other hand, the same HTTP request made by the same software client C but for another management identifier hdlr2 will not be authorized. In this case, the management entity 100 responds with a 403 Forbidden information message which is a standard message of the HTTP protocol to the software client C.

In some embodiments, the added R rule ADD is associated with a validity period. The added R rule ADD will therefore only be active for a limited duration. The validity period can be transmitted in the arguments obtained in return from the call and execution of the element M. In other embodiments, the validity period is defined a priori by the management entity 100. The two embodiments can be combined. Some types of added R rules ADD can have a validity period provided in return by the element M while others will have a predefined duration. The predefined duration can also be a default validity period which will be applied if a duration is not present in the values provided in return from the call of the element M.

Thanks to the invention, without modifying the legacy system S, which cannot integrate an added access control system, it is therefore possible to set up management operations carried out by software clients located outside the information system in which the system S is located. The use of management identifiers makes it possible to avoid attacks where telephone numbers are guessed by attackers knowing how to query the system S.

Finally, it should be noted here that, in this text, the term “module” can correspond to a software component as well as to a hardware component or a set of hardware and software components, a software component itself corresponding to one or more computer programs or sub-programs or, more generally, to any element of a program capable of implementing a function or a set of functions as described for the modules concerned. In the same way, a hardware component corresponds to any element of a hardware assembly capable of implementing a function or a set of functions for the module concerned (integrated circuit, smart card, memory card, etc.).

Claims (7)

Method for managing the call by a software client (C) of an application programming interface (API), said software client (C) having an identity (ID), said call aiming to execute an element (M) interfaced by the application programming interface (API), the method comprising the following steps carried out for a given call before accessing the interface (API):

• Extraction (XTR) of a value (V) from the arguments passed as a parameter by the software client (C) in the call to the application programming interface (API);
• Authorization (AUT) for the given call to access the interface (API) based on the identity (ID) of the software client (C) and the extracted value (V);
• If the given call is authorized (AUT) to access the interface (API), the creation (ADD) of a rule (R) comprising a value obtained (V') following the execution of the called element (M), said created rule (R) being relative to a subsequent authorization step of another call.

Management method according to claim 1 characterized in that the rule (R) created is a rule authorizing a subsequent call from the same software client (C) to the same application programming interface (API). Management method according to one of claims 1 or 2 characterized in that the created rule (R) is associated with a validity period. Management entity (100) managing the call by a software client (C) of an application programming interface (API), said software client (C) having an identity (ID), said call aiming to execute an element (M) interfaced by the application programming interface (API), the management entity (100) comprising the following modules:

• A module (102) for extracting (XTR) a value (V) from the arguments passed as a parameter by the software client (C) in the call to the application programming interface (API);
• An authorization module (103) (AUT) for the given call to access the interface (API) as a function of the identity (ID) of the software client (C) and the extracted value (V), said authorization module being, if the given call is authorized to access the interface (API), capable of creating a rule (R) comprising a value obtained (V') following the execution of the called element (M), said created rule (R) being relative to a subsequent authorization step of another call;

and characterized in that, for a given call, the extraction (XTR) and authorization (AUT) steps are all performed before accessing the interface (API). Management entity (100) according to claim 5 further comprising a rule base (DB), said rules relating to the authorization (AUT) for the call to access the interface (API). A computer program capable of being implemented by a management entity, the program comprising code instructions which, when executed by a processor, performs the steps of the management method defined in claim 1. Data medium, on which is recorded a computer program comprising a sequence of instructions for implementing the management method according to claim 1 when it is loaded into and executed by a processor.