System and method for securely activating API

Abstract

A computer-implemented method for securely activating an API includes the steps of pre-authorizing, by a software module providing the API, a user who wishes to activate the API, accepting a command issued by the user to activate the API, and automatically activating, by the software module, the API upon determining that the pre-authorization is valid. According to the embodiment of the invention, strong security is provided, and theoretically, unlimited verification modes can be implemented according to requirements before a user pre-authorizes unmanned operation of the sensitive application program interface.

Description

Technical Field

[0001] The present invention relates to API (Application Programming Interface) in computer systems, and more particularly to the management of API activation. Background Art

[0002] An API is a set of rules or protocols that allow software applications running on information processing devices to communicate with each other, enabling them to exchange data, features, and functionality. APIs simplify application development by allowing developers to integrate data, services, and functionality from other applications rather than building everything from scratch. For computer servers, an important category of APIs is management APIs, which allow applications running outside the controller to access data and services of the server's dedicated controller. An example of such a dedicated controller is the baseboard management controller (BMC).

[0003] However, in the prior art, if the API is related to substantial system management, there are risks in providing the API to external applications or users. For example, the hard disk secure erase (secureerase) API will erase all hard disk data on a group of servers. It not only deletes the data on the hard disk, but also takes more severe (and more time-consuming) measures, such as overwriting the hard disk space with 1s and 0s. For another example, the restart operating system API will stop the execution of workloads on the server. Because some system management operations are dangerous, it is necessary to ensure that the operations are performed with caution. How to enable users to confirm destructive operations that may be performed by sensitive APIs while keeping these operations automated has always been a difficult problem. Summary of the invention

[0004] Therefore, a first aspect of the present invention provides a computer-implemented method for securely activating an API (secure API). The method comprises the following steps: a software module providing the API pre-authorizes a user who wishes to activate the API, accepts a command to activate the API from the user, and automatically activates the API after determining that the pre-authorization is effective.

[0005] In some embodiments, the step of performing pre-authorization further includes verifying the identity of the user, receiving an indication from the user that the API is to be activated; and receiving one or more conditions for running the API from the user.

[0006] In some embodiments, the step of verifying the identity of the user further includes one or more of: providing an obfuscation test to the user, and requiring the user to log in using login credentials.

[0007] In some embodiments, the step of verifying the user identity further includes: logging into the software module by the user inputting a first username and a first password, and performing pre-authorization verification on the user by the user inputting a second username and a second password.

[0008] In some embodiments, the first username and the first password are different from the second username and the second password, respectively.

[0009] In some embodiments, the one or more conditions are selected from the following conditions: a time period for running the API; a number of times the API is run; and one or more targets for the API to take effect.

[0010] In some embodiments, the API is applicable to multiple information processing devices. The one or more targets are one or more of the multiple information processing devices determined in the list specified by the user.

[0011] In some embodiments, the user does not have administrative rights over the software module.

[0012] In some embodiments, the method further comprises the step of generating a script by a user. The script comprises a command to activate the API. The step of receiving the instruction to activate the API issued by the user further comprises the step of the user running the script after the software module providing the API pre-authorizes the user who wishes to activate the API.

[0013] In some embodiments, the method further includes the step of checking, by the software module, whether one or more conditions specified in the script match corresponding conditions specified in the pre-authorization.

[0014] In some embodiments, the step of performing pre-authorization is performed through a graphical user interface or a command line.

[0015] In some embodiments, the method further includes a step of, before the pre-authorization step, the user specifying an API to be activated to the software module.

[0016] According to another aspect of the present invention, a system for securely activating an API is provided. The system includes one or more processors; and a memory storing one or more programs, the one or more programs being configured to be executed by the one or more processors. The one or more programs include instructions for executing or facilitating the execution of a computer-implemented method, the computer-implemented method comprising the following steps: a software module providing an API pre-authorizes a user who wishes to activate the API, accepts a command issued by the user to activate the API, and the software module automatically activates the API after determining that the pre-authorization is effective.

[0017] According to another aspect of the present invention, there is provided a non-transitory computer-readable medium having instructions stored thereon. When executed by one or more processors, the instructions cause the one or more processors to perform a computer-implemented method, wherein the method comprises the following steps: a software module providing an API pre-authorizes a user who wishes to activate the API, accepts a command issued by the user to activate the API, and the software module automatically activates the API after determining that the pre-authorization is effective.

[0018] Therefore, the present invention provides a method and system that can automatically activate an API, but such automatic activation requires sufficient authorization or user confirmation to avoid accidental execution of sensitive APIs. For example, sensitive APIs may be destructive. In an exemplary embodiment, destructive operations are performed using scripts, unattended, but the scripts are only executed when pre-authorization is in effect. Therefore, in the process of automatically activating sensitive APIs, not only is user attention not required, but user confirmation is also performed in the form of pre-authorization when activating the API, which authorizes the user and activates the API, thereby preventing any accidental or malicious activation of the API. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The above and further features of the present invention will be apparent from the following description of preferred embodiments, which are provided by way of example only in conjunction with the accompanying drawings, in which:

[0020] Figure 1 is a schematic diagram showing an exemplary system for securely activating an API according to one embodiment of the present invention.

[0021] Figure 2 is a flow chart of a method for securely activating an API according to one embodiment of the present invention.

[0022] Figure 3 Shows the potential Figure 2 An exemplary GUI (graphical user interface) for pre-authorization is provided in accordance with the method of claim 1.

[0023] The above and other features of the present invention will become more apparent from the following description.The following description is made by way of example only with reference to the following drawings. DETAILED DESCRIPTION

[0024] The present invention may be a system, method and / or computer program product. The computer program product may include a computer-readable storage medium (or medium) having computer-readable program instructions thereon for causing a processor to perform various aspects of the present invention.

[0025] A computer-readable storage medium may be a tangible device that can retain and store instructions for use by an instruction execution device. For example, a computer-readable storage medium may be, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer floppy disk, a hard disk, a dynamic random access memory (DRAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disk read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device (such as a punch card or a raised structure in a groove with instructions recorded thereon), and any suitable combination of the above. The computer-readable storage medium used herein should not be understood as a transient signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (such as a light pulse through an optical fiber), or an electrical signal transmitted through a wire.

[0026] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to a respective computing / processing device, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to a computer-readable storage medium in the corresponding computing / processing device for storage.

[0027] The computer-readable program instructions for performing the operation of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages, such as Smalltalk, C++ or similar languages) and conventional program programming languages ​​(such as "C" programming languages ​​or similar programming languages). The computer-readable program instructions may be executed completely on the user's computer, may be executed partially on the user's computer as an independent software package, may be executed partially on the user's computer, may be executed partially on a remote computer, or may be executed completely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network (including a local area network or a wide area network), or may be connected to an external computer (for example, via the Internet of an Internet service provider). In certain embodiments, the electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) may execute the computer-readable program instructions by utilizing the state information of the computer-readable program instructions, so as to personalize the electronic circuit, thereby performing various aspects of the present invention.

[0028] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present invention. It is understood that each block in the flowchart illustrations and / or block diagrams and combinations of blocks in the flowchart illustrations and / or block diagrams can be implemented by computer-readable program instructions.

[0029] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a data processing device, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce means for implementing the functions / actions specified in one or more blocks in the flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium, which may direct a computer, a programmable data processing device, and / or other device to operate in a specific manner, so that the computer-readable storage medium having the instructions stored therein comprises an article of manufacture, which includes instructions for implementing various aspects of the functions / behaviors specified in the flowchart and / or block diagram blocks.

[0030] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device, thereby producing a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / behaviors specified in the flowchart and / or block diagram blocks.

[0031] The flowcharts and block diagrams in the figure illustrate the possible implementation architecture, functions and operations of the system, method and computer program product according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment or partial instruction, including one or more executable instructions for implementing a specified logical function. In certain alternative embodiments, the functions marked in the blocks may not appear in the order marked in the figure. For example, two blocks displayed in succession may actually be executed substantially simultaneously, or sometimes the blocks may be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagram and / or flowchart illustration and the combination of blocks in the block diagram and / or flowchart illustration can be implemented by a dedicated hardware-based system that can perform specified functions or behaviors, or a combination of dedicated hardware and computer instructions.

[0032] As used herein, a list with the conjunction "and / or" includes any single item in the list or combination of items in the list. For example, a list of A, B, and / or C includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. For example, "one or more of A, B, and C" includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C. For example, "one of A, B, and C" includes only A, B, or C, but not a combination of A, B, and C. "A member selected from the group of A, B, and C" includes one and only one of A, B, or C, but not a combination of A, B, and C. As used herein, "a member selected from the group consisting of A, B, and C and combinations thereof" includes only A, only B, only C, a combination of A and B, a combination of B and C, a combination of A and C, or a combination of A, B, and C.

[0033] Now watch Figure 1 , Figure 1An example system in which sensitive APIs can be safely activated is shown. The system includes multiple servers 20, all of which are connected to system management software 22. The system management software 22 runs as a software module on a system management device (SMA, not shown in the figure), which can be a physical machine such as an administrator management server or a virtual machine such as a kernel-based virtual machine (KVM). An example of the system management software 22 is Lenovo XClarity Manager (LXCA). In order for each server 20 to communicate with the system management software 22, the server 20 includes a dedicated controller (such as a service processor, not shown in the figure), which communicates directly with the system management software 22 via Ethernet and / or USB. For example, the dedicated controller can be used to perform one or more of the following functions: monitoring server status, configuring the server, installing an operating system (OS), and updating the firmware of the server 20. In one example, the dedicated controller is a Lenovo XClarity controller, which integrates service processor functions, super I / O, video controller, and remote presentation. In another example, the service processor is a traditional BMC, which is a specialized service processor used to remotely monitor the physical status of a host system (such as a computer, network server, or other hardware device). The BMC is used to remotely monitor and manage the host system.

[0034] The server 20 is connected to and managed by the system management software 22. Since the dedicated controller is a processor independent of the main processor (such as the CPU), the system management software 22 can perform management functions on the server 20 including the dedicated controller without the intervention of the operating system (OS).

[0035] In order to provide its management functions to users, the system management software 22 provides an API that can be activated based on external requests from the system management software 22 or SMA. As a specific example, LXCA provides a REST (Representational State Transfer) API that can be used to access XClarityAdministrator data and services from applications running outside the XClarityAdministrator framework. The REST application program interface allows XClarityAdministrator functionality to be integrated into other software, whether the software is running on the same system as the XClarityAdministrator server or on a remote system within the same network. These APIs are based on the REST architecture and are accessed via the HTTPS protocol.

[0036] Among the APIs provided by the system management software 22, at least some are sensitive, which means that they may interfere with the normal operation of the server 20 or even be destructive. Examples of sensitive APIs include hard disk secure erasure, restarting the operating system, restoring server configuration data, turning the power on or off, restarting the server, etc. Therefore, sensitive APIs cannot be activated at will, especially by anyone who is not properly verified or authorized. Figure 1 In the system shown, a user can access the system management software 22 and request activation of APIs including sensitive APIs by operating an information processing device 24 that communicates with the system management software 22. The information processing device 24 can be a desktop computer, an information kiosk, a mobile phone, a laptop, a tablet computer, or any other computing device that provides a user interface and input means so that a user using the information processing device 24 can request activation of an API provided by the system management software 22, for example, by sending a command to the latter. It should be noted that although Figure 1 The system management software 22 shown in the figure is separate from the information processing device 24, but the information processing device 24 can be the same machine that hosts the system management software 22, or it can be a different machine that is remotely connected to the physical machine or virtual machine that hosts the system management software 22.

[0037] It should be noted that Figure 1 The server 20 shown in is also an information processing device, and it should be noted that there is no limitation on the type of information processing device that the system management software 22 can manage using the API. On the contrary, as long as the information processing device includes one or more hardware components (such as a service processor) that allow the system management software 22 to manage it, then the present invention can be applied. Examples of other information processing devices that can be managed by the system management software 22 include, but are not limited to, personal computers, kiosks, workstations, and / or data center devices other than servers. In general, all information processing devices include one or more processors and memory. In the description herein, the term "data processing device" can be used interchangeably with "information processing apparatus."

[0038] Please see Figure 2 , Figure 2 Shows the steps to safely activate the API method for Figure 1 It should be noted that Figure 2 The method is not only applicable to Figure 1 Instead, other systems and information processing devices may also use Figure 2 The methods in are managed through the API. In addition, for ease of understanding, Figure 2LXCA is used as an example of system management software. The method starts at step 30, where a user wishes to activate an API to securely erase storage drives (e.g., hard disks) on three servers. The three servers are Figure 2 In the example, the LXCA is identified as node1, node2 and node3 respectively. Before, at or after step 30, LXCA, which is system management software providing hard disk secure erasure API, starts running in step 34 so that LXCA is ready to receive requests from users and perform pre-authorization described later.

[0039] Next, when LXCA is ready, the user logs in to LXCA to pre-authorize the use of the hard disk secure erase API. This process is shown as two steps, namely steps 32 and 36, to show that both the user and the system management software have actions. Similar to the above description, the user can operate directly on the information processing device that hosts LXCA, or on an information processing device different from the SMA that hosts LXCA, in which case network communication needs to be established between the user and LXCA. In any case, the user logs in to the graphical user interface of LXCA in step 36. Logging in to LXCA is part of user authentication, and the login can be one or more of a confusion test of the user (such as a verification code test), biometric verification, and login using credentials such as a username and password. It is best to use two-factor authentication (2FA) to combine two different authentication methods to strengthen security. Login is necessary because the user may not have the default administrator privileges of LXCA, and authentication ensures that important data on the storage drives of the three servers will not be accidentally erased by unauthorized users.

[0040] After the user successfully logs in to LXCA, in step 38, the user starts the sensitive API pre-authorization dialog box, an example of which is as follows Figure 3 As shown. In step 40, the user fills in the user ID and password in the dialog box to obtain pre-authorization to use the hard disk secure erase API. It should be noted that although the user ID and password entered in the dialog box may be the same as the user ID and password used to log in to LXCA (not shown) in step 36, for better security control, it is better to use different user names and / or different passwords during pre-authorization. This is because there may be many users who have the right to log in to LXCA to perform different operations, but the activation of sensitive APIs such as the hard disk secure erase API may only be performed by a few users, so these "super users" need a second credential for logging in to LXCA in order to pre-authorize the sensitive API.

[0041] In step 42, the user provides an indication that the hard disk secure erase API is to be used, for example, in Figure 3In the dialog box, enter the string " / nodes / secureEraseDrives". In this way, the user specifies the API to be activated to LXCA. In the dialog box, the user can enter various types of APIs as long as LXCA supports them. For example, in addition to the hard disk secure erase API, the user can also enter APIs such as " / nodes / poweron".

[0042] Next, from steps 44 to 48, the user will input various conditions for running the hard disk secure erase API into LXCA. In step 44, the user specifies the storage drive to be erased by providing a server list including node 1, node 2, and node 3. These three servers then become the targets for the hard disk secure erase API to execute. It can be seen that the server list input to LXCA is the same as the server list included by the user in the above script. Then, in step 46, the user specifies the time period for activating the hard disk secure erase API. In this example, the time period is half an hour from 10:20 am to 10:50 am. Figure 2 and Figure 3 As shown, the specified time period may optionally include a date, so that the user can schedule the API to be activated after more than one day. In step 48, the user specifies the number of hard disk secure erase APIs to be executed, which is three times in this example, meaning that the same erase operation will be repeated three times on each storage drive.

[0043] After entering the conditions for running the secure erase API, the user performs a final identity verification in step 50, that is, Figure 3 The user enters a captcha string in the dialog box shown. This is to ensure that the content entered in the dialog box is not written by a robot or other computer program. Finally, to complete the pre-authorization, the user clicks the "pre-authorization" button in the dialog box in step 52 (as shown in FIG. Figure 3 As shown), authorize the use of this " / nodes / secureEraseDrives" API. Subsequently, LXCA will verify the user's identity by checking the user ID and password entered in step 40, and check whether the user passes the verification code check in step 50. If there is no problem with these verifications, the pre-authorization is completed and effective.

[0044] Now that the pre-authorization has been completed, the method flow returns to the user side, and in step 54, the user writes a script to use / nodes / secureEraseDrive to securely erase the hard disk data of node 1, node 2, and node 3. In other words, the script contains commands to securely erase the hard disks of the three servers. The reason for using the script is that the API needs to be activated in an unattended manner. In this embodiment, the script also contains various conditions for activating the API, such as a server list (node ​​1 / node 2 / node 3 as shown in step 56), a timer period and / or date, the number of times the API is allowed to run, etc. After writing the script, the user runs the script in step 56 to start the unattended automatic hard disk secure erasure process. The above script contains a call to the hard disk secure erasure API. When the script is executed, LXCA receives the script and the call to the hard disk secure erasure API.

[0045] In step 58, the LXCA compares the usage time period and date entered in step 46 during the pre-authorization process with the current time and date when the script is run to determine whether the sensitive API can be run now. For example, if the date entered is many days later than the current date when the script is run, the LXCA will not take any action, but will suspend the API activation until the specified date arrives. If the LXCA determines that the date and time to run the API have arrived, then in the next step 60, the LXCA will compare the pre-authorized number of sensitive API usages with the actual number of API usages to determine whether the sensitive API can (continue to) run. If the maximum number of API executions has been reached, the API will not be activated again. On the contrary, if the API still has an allowed usage time, then the method will continue, and in step 62, the LXCA will compare the pre-authorized server list entered by the user in step 44 with the server list in the script entered by the user in step 54 to see if the two server lists match each other. If so, the script can continue to run, but if it does not match, the user will be warned and the API will not be activated to avoid accidentally erasing the hard drive. Finally, in step 64, if the server lists match each other, LXCA will activate the hard disk secure erase API according to the conditions previously input by the user (i.e., within a given time period and a given number of hard disk secure erases), thereby performing hard disk secure erase. At this point, the activation of the hard disk secure erase API has been completed.

[0046] It can be seen that Figure 2The method of activating sensitive APIs provided by the present invention shown has many advantages over traditional methods. Traditionally, for scripts that call sensitive APIs and perform system management, the process often requires human intervention to confirm the prompted operations, which is a process that requires participation. This method is undoubtedly labor-intensive because some operations (such as secure erasure of disk drives) require repeated erasures many times, which may take hours, and the user needs to be on standby all the time. On the other hand, some traditional methods use tokens in application program interfaces, which do not require human attention, but tokens cannot provide sufficient security guarantees because when tokens need to be sent and received multiple times between different parties, tokens may be issued and transmitted in an unsafe manner. In addition, the granularity of tokens is often insufficient, for example, tokens are only applicable to one session, and conditions such as time periods and the number of repeated operations cannot be specified. In other words, tokens may not be suitable for complex management tasks, and multiple tokens may further reduce security. In contrast, the embodiments of the present invention provide robust security. In theory, as many verifications as needed can be implemented before users perform pre-authorized operations on sensitive application program interfaces. This is particularly useful because the user (the user of the script) and the administrator of the system management software are different parties, so the user does not automatically have management rights to the system management software. However, once pre-authorization is completed, the user can run the script, and the entire API activation process is unattended and extremely efficient.

[0047] At this point, the exemplary embodiments of the present invention have been fully described. Although specific embodiments have been mentioned in the description, it will be apparent to those skilled in the art that the present invention can be implemented by variations of these specific details. Therefore, the present invention should not be construed as being limited to the embodiments described herein.

[0048] Although the present invention has been described in detail and in the accompanying drawings and the foregoing description, it should be regarded as exemplary rather than restrictive. It goes without saying that the present invention only exemplarily shows and describes the embodiments and does not limit the scope of the present invention in any way. It is understood that any feature described herein can be used in any embodiment. The exemplary embodiments of the present invention are not mutually exclusive, nor are they exclusive of other embodiments not described herein. Therefore, the present invention also provides an embodiment comprising a combination of one or more of the above-mentioned illustrative embodiments. Without departing from the spirit and scope of the present invention, the present invention described herein may be modified and varied, and therefore, only the limitations specified in the appended claims should be applied.

[0049] For example, although in Figure 1-3In the example shown, the number of servers that need to erase storage drives is three, but those skilled in the art will appreciate that the number of information processing devices that need to execute sensitive APIs is not limited. There can be only one information processing device that applies the API, or any other number of information processing devices.

[0050] Likewise, in Figure 2-3 The sensitive API used as an example in the embodiment is the hard disk secure erase API, but this does not mean to limit the present invention in any way. By using the method and system provided by the embodiment of the present invention, any other sensitive API similar to the above example, or even any API (whether sensitive API or non-sensitive API) can be activated.

[0051] In a variation of the preferred embodiment, APIs can be divided into different categories, and even different tiers / categories can be assigned to sensitive APIs. Users who can log into the system management software and pre-authorize and activate APIs can also be categorized, and different user groups can be given different user credentials, so that for any given user, once he or she logs in and passes the authentication, the APIs he or she can pre-authorize or activate are limited to the APIs assigned according to his or her rights or user groups.

[0052] like Figure 2-3 The pre-authorization shown is based on a graphical user interface, but in a variant of the preferred embodiment, the pre-authorization can also be based on a command line, since the user can provide all the required information via a text string.

[0053] Although the pre-authorization based API activation method according to the embodiment of the present invention can be used independently, those skilled in the art should be aware that in some variations, the method can be used in combination with other conventional methods. For example, even if the above-mentioned pre-authorization mechanism is implemented, a token can still be implemented in the same system as a security check mechanism to activate the use of sensitive APIs.

[0054] exist Figure 2-3 In the exemplary embodiment shown, the hard disk secure erase API provided by LXCA is used as an example to describe the method in this embodiment. More generally, the methods provided by the embodiments of the present invention can be used to authorize sensitive APIs in general BMCs. In addition, these methods can also be used to authorize operating system APIs or commands. Some operating systems provide hard disk secure erase APIs or commands, and the methods provided by the embodiments of the present invention can be used to authorize such operating system hard disk erase APIs or commands.

Claims

1. A computer-implemented method for securely activating an API, comprising the following steps: The software module providing the API pre-authorizes the user who wishes to activate the API; Receiving an instruction from the user to activate the API; as well as After determining that the pre-authorization is effective, the software module automatically activates the API.

2. The computer-implemented method according to claim 1, wherein the step of pre-authorizing, by the software module providing the API, a user who wishes to activate the API further comprises the following steps: verifying the identity of said user; receiving an indication from the user to activate the API; as well as One or more conditions for running the API are received from a user.

3. The computer-implemented method of claim 2, wherein the step of verifying the identity of the user further comprises one or more of: providing an obfuscation test to the user; and requiring the user to log in using login credentials.

4. The computer-implemented method of claim 3, wherein the step of verifying the identity of the user further comprises the steps of: The user logs into the software module by inputting a first user name and a first password; as well as The pre-authorization is verified by the user inputting a second user name and a second password.

5. The computer-implemented method of claim 4, wherein the first username and the first password are different from the second username and the second password, respectively.

6. The computer-implemented method of claim 2, wherein the one or more of the conditions are selected from the following: the time period during which the API is to be run; the number of times the API was run; and One or more targets for which the API is to be validated.

7. A computer-implemented method according to claim 6, wherein the API is applicable to multiple information processing devices; and the one or more targets are one or more of the multiple information processing devices determined in the user-specified list.

8. The computer-implemented method of claim 1, wherein a user does not have administrative rights to the software module.

9. The computer-implemented method according to claim 1 further includes the step of generating a script by the user, wherein the script includes a command to activate the API; the step of receiving an instruction from the user to activate the API further includes the user running the script after the step of pre-authorizing the user who wishes to activate the API by the software module providing the API.

10. The computer-implemented method of claim 9, further comprising the step of checking, by the software module, whether one or more conditions specified in the script match corresponding conditions specified in the pre-authorization.

11. The computer-implemented method of claim 1, wherein the step of pre-authorizing, by the software module providing the API, a user who wishes to activate the API is performed through a graphical user interface or a command line.

12. The computer-implemented method of claim 1, further comprising, prior to the pre-authorization step, a step in which the user specifies to the software module the API to be activated.

13. A system for securely activating an API, comprising: one or more processors; as well as A memory storing one or more programs configured to be executable by the one or more processors, the one or more programs including instructions for performing or facilitating the performance of the computer-implemented method of claim 1.

14. A non-transitory computer readable medium having stored thereon instructions which, when executed by one or more processors, cause the one or more processors to perform the computer-implemented method of claim 1.

Images