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

Abstract

Method for managing the call by a client of an application programming interface The invention relates to a method for managing the call by a software client (C) of an application programming interface (API), said 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): Verification (CHK) of the identity (ID) of the software client (C); Extraction (XTR) of the values (V) of the arguments passed as parameters by the software client (C) in the call of the application programming interface (API); Authorization (AUT) for the given call to access the interface (API) according to the identity (ID) of the software client (C) and the extracted values (V). Figure 1

Description

Title of the invention: Method for managing the call by a client of an application programming interface Technical field

[0001] The technical field is that of IT.

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

[0003] An application programming interface (API) is a means 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 that are generally referred to as the clients of the service provided. 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.

[0004] Client-server architectures and the use of APIs are very widespread in computing. In such an architecture, a computer server is placed in a communication network in which clients are also present. The clients can send requests to the server via the communication network to access 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 this is the case. The requested service could be, for example, the provision of data which will then be read by the client for further processing or the execution of a particular action. In general, a server can be queried by several different clients.

[0005] 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, translation from English web service. It can also be noted that the consultation of 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 the framework of 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 the navigation and display of 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).

[0006] Calling an API 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 TURI, 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.

[0007] 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:

[0008] GET http: / / API / roaming_status?tel_num='+33123456789'

[0009] 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.

[0010] In return, the client will receive a string containing the requested information. For example, a string '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 in JavaScript objects that use JSON (JavaScript Object Notation) or objects written in XML (Extensible Markup Language).

[0011] 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 technology (acronym for Common Object Request Broker Architecture) or SOAP (acronym for Simple Object Access Protocol). State of the art

[0012] An important point of client-server architectures and application programming interfaces is the access control technique chosen. Indeed, a given resource must only be able to be accessed by an authorized client. For this, an access control system is implemented. Access control ensures that a given client, when calling an API to obtain a resource, is on the one hand identified and on the other hand authorized to call the API method.

[0013] 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 according to 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 hash of the password, depending on the authentication mode 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.

[0014] In client-server architectures, the access control system is limited to verifying 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 access to the roaming status of a mobile phone, a client authorized to access the GET http: / / API / roaming_status API will be able to make this call for any value of the tel_num parameter, that is to say for any mobile phone number.

[0015] This situation has drawbacks.

[0016] 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 may be of interest to companies outside the telecommunications sector. A bank, for example, may detect that payments are made by credit card in Thailand and suspect fraud. By checking the roaming status of the credit card owner's mobile phone, the bank can obtain information about the owner's location and confirm or deny that their credit card is the victim of fraud, if they are currently in Thailand. A telecom operator may therefore find it advantageous to sell a bank access to the API providing this roaming status. However, the telecom operator must also protect the confidentiality of its customers' data. Giving a bank access to the API will allow the bank to know the roaming status of all mobile phones managed by the telecom operator, 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.For example, these may have been developed in programming languages that are no longer in use. Or, the program may have been developed by a supplier who claims to no longer be able or willing to modify it, or at least not at an acceptable price. Since there is no way to modify 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.

[0017] 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 clients of the API. 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 his use of the API to arguments for which this use is authorized but without being able to ensure by a computer tool that this limitation is respected.

[0018] Another disadvantage 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 the possibilities for evolving the rules governing this access.

[0019] The invention improves the situation. Statement of the invention

[0020] 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: performed for a given call before accessing the interface: • Verification of the identity of the software client; • Extraction of the values of 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 identity and the extracted values.

[0021] 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.

[0022] This check is performed at the time of verification of the identity of the software client, that is to say at the time when it is checked that the client is indeed authorized to call the interface. But, in addition to this standard access control, an additional check is performed, relating to the arguments passed to the application programming interface, before authorizing access to the interface and therefore the execution of the element targeted by the call. As this check is performed before access to the interface of the called element, it is done outside the software system which is interfaced by the application programming interface. In this way, the access control which performs fine-grained management of access rights can be deployed even when the interfaced system is a legacy system, which cannot be modified.

[0023] According to a first particular embodiment of the invention, the method comprises, if the given call is authorized to access the interface, a step of adding to a rule base a rule comprising a value obtained following the execution of the called element, said added rule relating to a subsequent authorization step of another call.

[0024] Thanks to this first mode, 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.

[0025] According to a second particular mode of implementation of the invention, which may be implemented alternatively or cumulatively with the previous mode, a rule added to the rule base is a rule authorizing a subsequent call from the same software client to the same application programming interface.

[0026] In this second embodiment, the form of the added rule is specified. Here, it 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.

[0027] According to another embodiment, which may be implemented alternatively or cumulatively with the previous modes, the rule added to the rule base is associated with a validity period.

[0028] Thanks to this embodiment, the rule base 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 to 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 the validation of a new password.

[0029] 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.

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

[0031] Thanks to these two embodiments, the operation of the evolution over time of the rule base 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.

[0032] According to another embodiment, which may be implemented alternatively or cumulatively with the preceding modes, if the call is not authorized after inter- rule base modification, an error is returned to the software client.

[0033] With this embodiment, information is provided to the software client if its access to the application programming interface is refused for the values of the arguments submitted as parameters. The software client will thus be able to 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.

[0034] According to another embodiment, which may be implemented alternatively or cumulatively with the preceding embodiments, the call is a call to a Web service using the POST verb and an added rule 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.

[0035] Thanks to this embodiment, the constitution of the rule base is facilitated. The software client is authorized to make a call to the API 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 in the rule base.

[0036] 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 the JSON notation.

[0037] 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 transmitted as parameters of the called methods can be grouped in a computer object using JSON notation. A tool such as JSONpath can then provide access to the values in question present in the object.

[0038] 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 software client identity verification module; • A module for extracting the values of 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 values;

[0039] and characterized in that, for a given call, the verification, extraction and authorization steps are all performed before accessing the interface.

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

[0041] 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.

[0042] 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.

[0043] 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. Furthermore, 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 can 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

[0044] 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:

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

[0046] [Fig.2] illustrates an example of steps implemented within the framework of an embodiment of the invention.

[0047] [Fig.3] illustrates another example of steps implemented within the framework of another embodiment of the invention. Detailed description

[0048] [Fig.l] represents a software client C, which has an identity ID. [Fig.l] 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 APL. [Fig.l] also represents a management entity 100 in charge of managing a call from client C to the API programming interface.

[0049] In the exemplary embodiment shown in [Fig.l], 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 call ; • A 103 module for authorizing AUT access to the interface; • A DB rule base.

[0050] In other exemplary embodiments, the management entity 100 does not include a rule base DB.

[0051] The client C, the management entity 100 and the system S are connected to each other by a communication network not shown in [Fig.l]. 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.

[0052] 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.

[0053] 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.

[0054] 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 IT element. Element M includes the execution of a software part on hardware elements which can belong to the system S or be transferred to external hardware elements in the case of a cloud architecture.

[0055] The software client C and the system S form a client-server architecture, that is to say that the system S offers, via 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 represented here, the operation performed through the API interface is the call of the method M. The same API interface can make it possible to call other elements of the system S. And furthermore, 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.

[0056] 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 carry out certain operations. The system S will then be 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, both for the execution of the client C or the system S, virtual machine techniques or containerization of software components.

[0057] 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.

[0058] The management entity 100 also 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, 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.

[0059] 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 management 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.

[0060] In all cases, 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.

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

[0062] The software client C sends an execution request to the API interface of the system S of 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 elements 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.

[0063] The module 101 of the management entity 100 will first verify 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 (translation of the English headef) 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.

[0064] 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.

[0065] It can be noted that in the case of a conventional Web server, the access control system does not perform the XTR extraction of the V values. Indeed, a Web server will simply check that 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 S system without any additional controls.

[0066] 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.

[0067] 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 exemplary embodiment represented by [Fig.l], these data allow 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.

[0068] In this case, in the example shown in [Fig.l], the call in question is authorized AUT by the module 103, which is represented by the OK symbol opposite the question mark which represents the interrogation of the rule base DB. The call of the method M with the values V by the client C can therefore continue up to the application programming interface APL

[0069] 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, XTR extraction of the values V and finally 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 in connection with 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 in any case. 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.

[0070] 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 an 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 client software C as a result of the call by the client C of the method M through the API interface. In certain embodiments of the invention, not shown in [Fig.l], the obtained value V' will be used by the management entity 100 to add to the rule base DB a new authorization rule AUT using the obtained value V'.

[0071] [Fig.2], for its part, presents an example of steps and message exchanges implemented within the framework of an embodiment of the invention.

[0072] In the example illustrated by [Fig.2], the architecture of the software client C and of 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.

[0073] In the example of [Fig.2], the software client C sends 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 request GET status(num) without checking that the software client C is legitimate to obtain this information.This situation is typical for a system S intended solely to provide information to other applications in the telecommunications operator's information system which are therefore by nature legitimate in obtaining information from the system S.

[0074] It may be relevant for the telecommunications operator that manages the system S to open up to third-party partners the possibility of accessing the Web services of the system S. For example, a bank may wish to know the roaming status of its customers in order to improve the fight against fraud. The software client C may then be an element of the information system of a bank which, in the presence of suspicious activities abroad of the account of one of its customers, will be able to check, using the roaming status, whether he is actually present abroad or not. However, it must be ensured that the 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.

[0075] However, the system S cannot generally be modified. Fine management of access rights cannot be added to it. The access control carried out by the Web server for giving access to the API interface of the system S is also not suitable. The invention is of particular interest in this situation.

[0076] The software client C, for example an element of a bank's information system, wishes to query the application programming interface API of the system S to find out the roaming status of a mobile phone. This information is accessible by sending the HTTP request GET status(numl) to the API interface.

[0077] The management entity 100 is for example, in this embodiment, a component of the Web server which 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 of the call to the APL interface. This is in this case the telephone number numl.

[0078] [Fig.2] represents in a rectangle the operation carried out by the authorization module 103. In the example represented here, the module 103 proceeds by interrogating a rule base DB. Two rules present in the rule base DB indicate on the one hand that the interrogation of the roaming status request is possible in general for the client C whose identity ID is verified and furthermore that this interrogation is authorized OK for the telephone number numl.

[0079] 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 numl. 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.

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

[0081] Subsequently, the software client C wishes to query the roaming status for the telephone number num2.

[0082] In this case, the query of the rule base DB by the module 103 shows that the software client C whose identity ID has been verified CHK is not authorized NOK to obtain the roaming status of the telephone number num2. The information can be explicitly given in a rule of the DB base, as indicated in [Fig.2], or, in other examples, the absence of a rule explicitly authorizing the access of the client C to the information will be sufficient for the module 103 not to authorize AUT the continuation of the call and to access the APL interface

[0083] 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.

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

[0085] The example of [Fig.2] 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.

[0086] [Fig. 3], for its part, presents another example of steps and message exchanges implemented within the framework of an embodiment of the invention.

[0087] In this example, as in that of [Fig.2], the architecture of the software client C and of 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 comprising HTTP verbs such as GET, POST, PUT etc. Other implementations are possible using other application programming interface request techniques such as SOAP or CORBA or others.

[0088] In the example of [Fig. 3], 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.

[0089] 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.

[0090] The management entity 100 will carry out an access control as described in the example of [Fig.2] 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 to the system S the HTTP request POST mgmt(num). This authorization method AUT, already described in [Fig.2], is not further detailed here.

[0091] 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 hdlrl (abbreviated from the English handlef) 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.

[0092] In one embodiment of the invention, the management entity 100 retrieves this value V' in return and uses it to create a new rule added ADD to the rule base DB. This operation is represented in [Fig.3] by a rectangle in which a rule is added to the DB base, said rule consisting of authorizing the identifier ID (that of the client C) to carry out the management operation data_inc for the management identifier hdlrl. This management operation has for example the effect of increasing the data package allocated to the telephone number corresponding to the management identifier hdlrl. Other rules, corresponding to other management operations, can of course be added.

[0093] In the following, as shown in [Fig.3], the software client C can actually call the API interface with the HTTP request PUT data_inc(hdlrl). This request is authorized AUT by the management entity since the corresponding rule was previously added in the rule base DB using the return value V', namely the management identifier hdlrl. The effect of this request will then be, for example, to increase the data plan allocated to the telephone number corresponding to the management identifier hdlrl. 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.

[0094] 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 period. 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 M element 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 M element call.

[0095] 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.

[0096] Finally, let us point out here that, in the present 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

Claims

1. 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): • Verification (CHK) of the identity (ID) of the software client (C); • Extraction (XTR) of the values (V) of the arguments passed as parameters by the software client (C) in the call of the application programming interface (API); • Authorization (AUT) for the given call to access the interface (API) according to the identity (ID) of the software client (C) and the extracted values (V).

2. Management method according to claim 1 characterized in that it comprises, if the given call is authorized (AUT) to access the interface (API), the addition (ADD) in a rule base (DB) of a rule (R) comprising a value obtained (V') following the execution of the element (M) called, said added rule (R) being relative to a subsequent authorization step (AUT) of another call.

3. Management method according to claim 2 characterized in that a rule (R) added to the rule base (DB) is a rule authorizing a subsequent call from the same software client (C) to the same application programming interface (API).

4. Management method according to one of claims 2 or 3 characterized in that the rule added (R) in the rule base (DB) is associated with a validity period.

5. 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 (101) for verifying (CHK) the identity (ID) of the software client (C); • A module (102) for extracting (XTR) the values (V) of the arguments passed as parameters 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) based on the identity (ID) of the software client (C) and the extracted values (V); and characterized in that, for a given call, the verification (CHK), extraction (XTR) and authorization (AUT) steps are all carried out before accessing the interface (API).

6. 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).

7. 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.

8. Data carrier, 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.

Images