CN107465650B - Access control method and device - Google Patents
Access control method and device Download PDFInfo
- Publication number
- CN107465650B CN107465650B CN201610395197.2A CN201610395197A CN107465650B CN 107465650 B CN107465650 B CN 107465650B CN 201610395197 A CN201610395197 A CN 201610395197A CN 107465650 B CN107465650 B CN 107465650B
- Authority
- CN
- China
- Prior art keywords
- access request
- access
- authentication
- white list
- api
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/105—Multiple levels of security
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Storage Device Security (AREA)
- Computer And Data Communications (AREA)
Abstract
The application discloses an access control method and device. Receiving an access request of an API (application program interface), and performing access control according to a preset query list, access control information corresponding to the access request and the preset query list; when the access request is judged to pass the access control, performing authentication according to authentication information corresponding to the access request and a preset first white list; accepting the access request when it is determined that the access request passes the authentication. Authentication is achieved through two-level control and the range of control granularity is refined.
Description
Technical Field
The application belongs to the field of cloud computing, and particularly relates to an access control method and device.
Background
Authentication (authentication) refers to verifying whether a user has the right to access a system. Traditional authentication is verified by means of a password. This approach presupposes that each user obtaining the password is already authorized. When the user is established, a password is allocated to the user, and the password of the user can be specified by an administrator or can be applied by the user.
However, the weakness of this method is obvious, once the password is stolen or the user loses the password, the situation is very troublesome, the administrator needs to modify the password of the user again, and before the password is modified, the legal identity of the user needs to be verified manually.
Meanwhile, in the prior art, the access is authenticated by taking the access key through the API, the access control granularity range is often large, and the access control authority is controlled by adopting one mode and lacks of a grading mechanism.
To overcome the disadvantages of this authentication approach, a more reliable access control method is needed.
Disclosure of Invention
In view of this, the present application provides an authentication method and apparatus.
In order to solve the above technical problem, the present application discloses an authentication method, including:
receiving an access request of an API (application program interface), and performing access control according to access control information corresponding to the access request and a preset query list;
when the access request is judged to pass the access control, performing authentication according to authentication information corresponding to the access request and a preset first white list;
accepting the access request when it is determined that the access request passes the authentication.
Wherein the method further comprises: and when the access request is judged not to pass the access control according to the access control information, acquiring a second white list, and authenticating the access request according to the second white list.
The obtaining of the access control information of the access request specifically includes: and acquiring the source IP address of the access request and the visitor signature corresponding to the access request.
Wherein, determining that the access request passes the access control according to the access control information specifically includes: and inquiring a preset IP address list according to the source IP of the access request and/or inquiring a preset visitor signature list according to a visitor signature corresponding to the access request, and judging whether the access request passes the access control according to a preset strategy.
The acquiring of the authentication information corresponding to the access request specifically includes: obtaining semantics of an API corresponding to the access request and information of a source application corresponding to the access request, and obtaining the preset first white list corresponding to the source application according to the information of the source application.
Wherein, judging that the access request passes the authentication according to the authentication information and a preset first white list specifically comprises: and inquiring the first white list according to the semantics of the API and the information of the source application, and judging whether the access request has permission on the target of the access request.
Wherein the first white list comprises: the corresponding relation between the API which sends the access request and the source application; and/or, the corresponding relation between the API sending the access request and the target information;
the second white list includes: and the API sending the access request corresponds to the source application and the target information.
Wherein the method further comprises: modifying the first white list and the second white list to dynamically adjust the authentication granularity of the access control and the authentication.
The application also discloses an authentication device, including:
the access control module is used for receiving an access request of the API and carrying out access control according to access control information corresponding to the access request and a preset query list;
the authentication module is used for authenticating according to authentication information corresponding to the access request and a preset first white list when the access request is judged to pass the access control;
and the first response module is used for accepting the access request when the access request is judged to pass the authentication according to the authentication information and a preset first white list.
The apparatus further comprises a second response module: and when the access request is judged not to pass the access control according to the access control information, the second response module is used for acquiring a second white list and authenticating the access request according to the second white list.
The access control module is specifically configured to: and acquiring the source IP address of the access request and the visitor signature corresponding to the access request.
The access control module is specifically configured to: and inquiring a preset IP address list according to the source IP of the access request and/or inquiring a preset visitor signature list according to a visitor signature corresponding to the access request, and judging whether the access request passes the access control according to a preset strategy.
Wherein, the authentication module is specifically configured to: obtaining semantics of an API corresponding to the access request and information of a source application corresponding to the access request, and obtaining the preset first white list corresponding to the source application according to the information of the source application.
The authentication module is specifically configured to query the first white list according to the semantics of the API and the information of the source application, and determine whether the access request has a right to a target of the access request.
Wherein the first white list comprises: the corresponding relation between the API which sends the access request and the source application; and/or the corresponding relation between the API sending the access request and the target information;
the second white list includes: and the API sending the access request corresponds to the source application and the target information.
Wherein the apparatus further comprises an authentication granularity adjustment module configured to modify the first whitelist and the second whitelist to dynamically adjust the access control and the authentication granularity of the authentication.
Compared with the prior art, the application can obtain the following technical effects:
1) the access initiated by the API is authenticated through the semantics of the API, so that the complexity of authenticating the access KEY on the API belt is avoided, and the trouble caused by losing the access KEY is also avoided;
2) the authentication granularity can be controlled in any range by modifying the first white list and the second white list to adjust the authentication granularity;
3) and a two-stage control mode of access control and authentication is adopted, so that the security of accessed data is further ensured.
Of course, it is not necessary for any one product to achieve all of the above-described technical effects simultaneously.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application and are incorporated in and constitute a part of this application, illustrate embodiment(s) of the application and together with the description serve to explain the application and not to limit the application. In the drawings:
FIG. 1 is an exemplary diagram of a typical application scenario in accordance with an embodiment of the present application;
FIG. 2 is a flowchart of a technique according to a first embodiment of the present application;
FIG. 3 is a schematic structural diagram of an apparatus according to a third embodiment of the present application;
fig. 4 is a technical flowchart of an example application scenario of the present application.
Detailed Description
Embodiments of the present application will be described in detail with reference to the drawings and examples, so that how to implement technical means to solve technical problems and achieve technical effects of the present application can be fully understood and implemented.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include non-transitory computer readable media (transient media), such as modulated data signals and carrier waves.
As used in the specification and in the claims, certain terms are used to refer to particular components. As one skilled in the art will appreciate, manufacturers may refer to a component by different names. This specification and claims do not intend to distinguish between components that differ in name but not function. In the following description and in the claims, the terms "include" and "comprise" are used in an open-ended fashion, and thus should be interpreted to mean "include, but not limited to. "substantially" means within an acceptable error range, and a person skilled in the art can solve the technical problem within a certain error range to substantially achieve the technical effect. Furthermore, the term "coupled" is intended to encompass any direct or indirect electrical coupling. Thus, if a first device couples to a second device, that connection may be through a direct electrical coupling or through an indirect electrical coupling via other devices and couplings. The description which follows is a preferred embodiment of the present application, but is made for the purpose of illustrating the general principles of the application and not for the purpose of limiting the scope of the application. The protection scope of the present application shall be subject to the definitions of the appended claims.
It is also noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a good or system that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such good or system. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a commodity or system that includes the element.
Fig. 1 is a diagram illustrating an exemplary application system according to an embodiment of the present application. Fig. 1 is a cloud computing Cluster automation operation and maintenance System, which at least includes a storage manager Master, a basic service Cluster, a Client and a server Cluster. The storage manager Master is a service used for storing management metadata of the operation and maintenance System in the cloud computing automation operation and maintenance System; the Cluster of the basic Service runs the basic Service of the operation and maintenance System in the Cluster, such as Service 1-Service N in FIG. 1; the Client exists on all the System managed machines and is used for completing the management work of the operation and maintenance System on the machines managed by the System and the applications running on the machines, such as clients 1-Client N shown in FIG. 1; the server cluster is a cluster where all services of an operation and maintenance System are located, generally comprises five machines and mainly operates key services of the operation and maintenance System; all services inside and outside the operation and maintenance System communicate with the storage manager Master through the API with semantics. The following section will further describe an implementation process of an access control method in such a typical cloud computing cluster automation operation and maintenance system in combination with the embodiment shown in fig. 2.
Fig. 2 is a technical flowchart of a first embodiment of the present application, and in conjunction with fig. 2, an access control method according to the present application may be implemented by the following steps:
step S210: receiving an access request of an API (application program interface), and performing access control according to access control information corresponding to the access request and a preset query list;
step S220: when the access request is judged to pass the access control, performing authentication according to authentication information corresponding to the access request and a preset first white list;
step S230: accepting the access request when it is determined that the access request passes the authentication.
Specifically, in step S210, when the storage manager Master receives an access request sent through the semantic API, access control information of the access request is first obtained, where the access control information may include a source IP address (the source IP address may also be sent in a bound manner with the access request, or may be sent by being encapsulated in the access request) parsed according to the access request, and an accessor signature carried by the access request. The authentication method of the application needs to undergo two-stage control, and the access control information is used for access control.
The signature of the visitor is the information of the visitor sending the access request, when an application calls the API, the built-in signature service can default to make a signature for the visitor, and the visitor information calling the API can be known by analyzing the signature of the visitor. Meanwhile, in the embodiment of the application, the access request is analyzed, and the source IP address sending the access request is obtained.
It should be noted that the "access request" described in this application includes at least one of read/write/delete/create/call of the target information, and is not described in detail later.
Specifically, the access control may be implemented in two possible ways:
firstly, an IP address list with access authority is preset, when the source IP address in the access control information is obtained, the preset IP address list is inquired according to the source IP address, if the inquiry can be made, the source IP has the access authority to a storage manager Master, and the authentication information of the access request can be further obtained through access control.
Secondly, an accessor signature list with access authority is preset, when an accessor signature corresponding to the access request in the access control information is obtained, the preset accessor signature list is inquired according to the accessor signature, if the accessor signature list can be matched, the access request is judged to pass the access control, and the authentication information corresponding to the access request can be further obtained.
It should be noted that, of course, the two access control manners may be used alone or in combination for authentication, and the application is not limited thereto.
Specifically, in step S220, after it is determined that the access request passes the access control, further, the authentication information corresponding to the access request is obtained. The authentication information further includes semantics of an API corresponding to the access request and information of a source application corresponding to the access request. And after the information of the source application corresponding to the access request is obtained, obtaining a preset first white list corresponding to the information of the source application. The authentication information may be carried in the access request, or may be obtained by binding and analyzing the access request.
In the cloud computing cluster automatic operation and maintenance System, when any other service accesses the storage manager Master, only a unique mode is adopted, namely, the APIs have different semantics, and each semantic is defined by a worker according to the requirement. When the access request does not contain the target information of the access, the storage manager Master can determine the behavior of the API by analyzing the semantics, namely, the access request sent by the API specifically accesses the data. Therefore, the application uses the semantics of the API for authentication, and can directly obtain the target content of the access request through the semantics of the API, that is, the access request is a certain application/service managed by the storage manager Master, and even a certain part of metadata information of the certain application/service.
After obtaining the semantics of the API corresponding to the access request, analyzing the semantics of the API to obtain the information of the source application corresponding to the access request, and querying a preset first white list corresponding to the source application according to the information of the source application. Specifically, the first white list includes: the corresponding relation between the API which sends the access request and the source application; and/or the corresponding relation between the API sending the access request and the target information.
For example: the first white list may be presented in the form of the following table one:
Or in the form:
in table one, names 1 to 3 are semantics of different APIs, a1 to a5 are source applications that issue access requests, and S with different reference numbers represents accessible target information.
According to the first white list shown in the above table, the API with the semantic Name1 can be used to access the source application active application or service as a1\ a2\ A3, and other applications or services in the cloud computing operation and maintenance System have no access right through the API Name 1. Similarly, the source application or service that can access data through the API with the semantic Name2 is a1\ A3, and except for a1/A3, an access request issued through this API has no access right to any data managed in the Master.
Further, as shown in the above table, when a1 accesses S1 through the API with the semantic Name1, only part of information or data such as S11\ S13\ S14 of S1 can be accessed, whereas when a1 accesses S1 through the API with the semantic Name2, part of information or data such as S12\ S15 of the service S1 can be accessed. The above table is only one way of existence of the first white list, which may also appear in the following form:
watch two
In table two, the source application accessing the data in the Master through the API with the semantic Name1 is only a1\ a2\ A3, and in addition, when other applications access the data in the Master through the API with the semantic Name1, the data cannot pass through the authentication. Similarly, only applications or services such as A2\ A3\ A4\ A5 and the like can access the Master through the semantic API of Name 3.
Comparing the above table one and table two, the control granularity of the first whitelist is different for the two different versions. According to the mode of table one, the matching rule of the first white list has two layers, the first layer is the matching rule of the API with different semantics and the application/service sending the request, and the second layer contains the matching rule of the API with different semantics and the specific information/data in the Master. However, in table two, there is only one layer of matching rules, and the granularity of control over authentication is obviously larger than that shown in table one. Of course, the existence mode of the first white list shown in the first table and the second table can be adjusted according to requirements. The above table contents are for illustrative purposes only and do not limit the present application in any way.
Specifically, in step S220, the access request is authenticated according to the authentication information, and only the first white list needs to be queried according to the authentication information to determine whether the access request is allowed to be accessed, and if not, the access request is returned with error information of access failure.
It should be noted that, when it is determined that the access request does not pass the access control according to the access control information, a second white list is obtained, and the access request is authenticated according to the second white list. Specifically, the second white list includes: and the API sending the access request corresponds to the source application and the target information. The second white list may exist as table three below:
watch III
As shown in table three, for an access request that fails access control, the access request is responded according to the matching rule of the second access white list.
In this embodiment, for an access request sent by the API, access control information and authentication information of the access request are respectively obtained, and the access request is controlled in two stages, so that ordered and strict authentication of the cloud computing cluster automatic operation and maintenance system is realized. Compared with the traditional mode of authenticating the access initiated by the API through the semantics of the API, the authentication mode provided by the embodiment of the application directly performs behavior analysis and authentication on the received access request through the semantics of the API, avoids inconvenience caused by password loss, and is direct and efficient; secondly, in the embodiment of the application, a two-stage control mode is adopted, so that the safety of the accessed data is further ensured.
In the second embodiment of the present application, modifying the granularity range of authentication may be implemented by the following implementation manners:
modifying the first white list and the second white list to dynamically adjust the authentication granularity of the access control and the authentication.
Following the embodiment corresponding to fig. 2, the first white list corresponding to table one is modified to further reduce the granularity range of authentication. Table four is a possible modification of table one, as follows:
watch four
As shown in table four, through modification of the first access white list, the access request initiated by Master through a certain semantic API is further refined and controlled.
The target information which can be accessed by the access request initiated by the semantic API Name1 is S11\ S13\ S14, and according to the white list, the access request can only carry out the reading operation on S11, the writing operation on S13 and the deleting operation on S14, and any operation except the operations has no authority. Of course, the above tables and their contents are used only by way of example and do not limit the present application in any way.
Specifically, when performing granularity control, the source application, the accessible target information, and the access type in table four may be modified according to requirements and the granularity may be further refined, which is not described herein.
The second white list corresponding to table three is modified so as to further reduce the granularity range of authentication, which is similar to the first white list, and details are not repeated here.
In this embodiment, the access granularity range controlled by the authority can be freely scaled by modifying the filtering rules of the first white list and the second white list. Compared with the prior art, the method and the device can further narrow the control strength range of the access authority, thereby realizing further strict and detailed authentication and improving the safety of accessed data.
Fig. 3 is a schematic structural diagram of a device according to a third embodiment of the present application, and with reference to fig. 3, an access control device according to the present application specifically includes an authentication module access control module 310, an authentication module 320, and a first response module 330.
The access control module 310 is configured to receive an access request of an API, and perform access control according to access control information corresponding to the access request and a preset query list;
the authentication module 320 is configured to authenticate according to authentication information corresponding to the access request and a preset first white list when it is determined that the access request passes the access control;
the first response module 330 is configured to accept the access request when it is determined that the access request passes the authentication according to the authentication information and a preset first white list.
The apparatus further comprises a second response module 340: and when the access request is judged not to pass the access control according to the access control information, the second response module is used for acquiring a second white list and authenticating the access request according to the second white list.
The access control module 310 is specifically configured to: and acquiring the source IP address of the access request and the visitor signature corresponding to the access request.
The access control module 310 is specifically configured to: and inquiring a preset IP address list according to the source IP of the access request and/or inquiring a preset visitor signature list according to a visitor signature corresponding to the access request, and judging whether the access request passes the access control according to a preset strategy.
The authentication module 320 is specifically configured to: and acquiring the semantics of the API corresponding to the access request and the information of the source application corresponding to the access request.
The authentication module 320 is further specifically configured to: and acquiring a first white list corresponding to the source application according to the information of the source application.
The authentication module 320 is specifically configured to query the first white list according to the semantics of the API and the information of the source application, and determine whether the access request has a right to a target of the access request.
Wherein the first white list comprises: the corresponding relation between the API which sends the access request and the source application; and/or the corresponding relation between the API sending the access request and the target information;
the second white list includes: and the API sending the access request corresponds to the source application and the target information.
Wherein the apparatus further comprises an authentication granularity adjustment module 350 configured to modify the first white list and the second white list to dynamically adjust the access control and the authentication granularity of the authentication.
The apparatus shown in fig. 3 can execute the method described in the embodiments shown in fig. 1 and fig. 2, and the implementation principle and the technical effect are not described again.
Examples of the applications
The following will describe in detail a specific implementation manner of an authentication method in a specific application scenario with reference to fig. 4.
The Ali space-based cloud computing cluster automation operation and maintenance system needs to store a large amount of Meta information, the TjMaster is a center for storing and exchanging the Meta information of the whole space-based system, the correctness of the TjMaster data is related to the stability and the availability of the whole space-based system, and the only access entrance of the TjMaster is a semantic API.
In the space-based system, because the space-based system manages a large number of clusters, each service and client of the space-based system can perform read-write access to the TjMaster through the semantic API provided by the TjMaster, and for the metadata managed by the TjMaster, not every application can read/write, so that the read/write of each service needs to be authenticated, the semantic of the API is adopted in the space-based system to perform authentication, and the read/write permission of each service to different metadata is controlled.
The access of the TjMaster Meta data is mainly divided into two categories, one category is a space-based client which is distributed on all space-based managed machines, and one space-based client exists in each space-based managed machine; the other type is interplanetary services which are mainly distributed in a space-based cluster, the space-based cluster consists of about 5 machines, each key service of the TjMaster and the space-based is operated on the space-based cluster, the space-based services have different functions, and the access requirement on Meta information on the TjMaster is also related to the service function.
In order to implement the permission control of the access of the TjMaster, the access of the semantic API to the TjMaster is controlled through two-stage control by adopting the authentication method.
Firstly, when the tjMaster receives an access request of the API, access control information of the access request is obtained first, so that the access request is subjected to access control. Specifically, the access control information may be a source IP address corresponding to the access request or a signature of the visitor, so that the received access request is distinguished from an external access or an internal access of the space-based cluster according to the access control information.
And when the access request is judged to be from the space-based cluster, further acquiring the authentication information of the access request. Specifically, the authentication information includes semantics of an API corresponding to the access request and information of a source application of the access request, and after the information of the source application is obtained, a first white list corresponding to the source application is obtained. Specifically, the first white list lists a corresponding relationship between an access request and an application, that is, which applications can be accessed by an access from the inside of the space based; further, the white list also exemplifies the correspondence between the semantics of the API that issues the access request and the source application, that is, which applications from the inside of the space base can issue the access request through a specific API; further, the white list also exemplifies which target information has access right from the access request sent by the source application in the space base through a specific API.
And when the access request is judged to pass the authentication according to the filtering rule of the first white list, namely the access request has the authority to access the target accessed by the access request, the access request is accepted, and if the access request does not pass the authentication, error information of access failure is returned.
It should be noted that both the first white list and the second white list may be modified, so that the matching rules of the white lists may be changed from the control granularity of limited authentication.
In addition, it should be noted that, if the access request does not pass the access control, that is, when it is determined that the access request is from inside the non-space-based cluster according to the source IP address of the access request or the visitor signature, the second white list corresponding to the non-space-based cluster is obtained. Specifically, the second white list lists the access request and a corresponding relationship between the access control information of the access request and the target information of the source application. I.e. whether a particular piece of information from outside the sky-based cluster has access to a source application.
Specifically, a white list is listed in a code implementation format as follows:
the semantics of the AddMachine API are that Meta information of one machine is added to TjMaster, and the white list defines four fields (allowed _ field) that the API allows to operate, whether the API call source comes from a space-based cluster (if is _ public, the API can come from the space-based cluster), and an application (allowed _ apps) that allows to call. From this white list, we can see that a request issued through the Addmachine semantic API will modify four fields and can only be called by service from the space-based cluster, and can only allow machine _ manager and sealing _ service calls.
The foregoing description shows and describes several preferred embodiments of the invention, but as aforementioned, it is to be understood that the invention is not limited to the forms disclosed herein, but is not to be construed as excluding other embodiments and is capable of use in various other combinations, modifications, and environments and is capable of changes within the scope of the inventive concept as expressed herein, commensurate with the above teachings, or the skill or knowledge of the relevant art. And that modifications and variations may be effected by those skilled in the art without departing from the spirit and scope of the invention as defined by the appended claims.
Claims (17)
1. An access control method, comprising:
receiving an access request of an API (application program interface), and performing access control according to access control information corresponding to the access request and a preset query list;
when the access request is judged to pass the access control, performing authentication according to authentication information corresponding to the access request and a preset first white list; wherein the authentication information corresponding to the access request includes: the semantics of an API corresponding to the access request and the information of a source application corresponding to the access request;
accepting the access request when it is determined that the access request passes the authentication.
2. The method of claim 1, wherein the method further comprises:
and when the access request is judged not to pass the access control according to the access control information, acquiring a second white list, and authenticating the access request according to the second white list.
3. The method according to claim 1, wherein the access control information corresponding to the access request specifically includes:
the source IP address of the access request and the visitor signature corresponding to the access request.
4. The method of claim 3, wherein determining that the access request passes the access control specifically comprises:
and inquiring a preset IP address list according to the source IP of the access request and/or inquiring a preset visitor signature list according to a visitor signature corresponding to the access request, and judging whether the access request passes the access control according to a preset strategy.
5. The method of claim 1, further comprising,
and acquiring the preset first white list corresponding to the source application according to the information of the source application.
6. The method of claim 5, wherein the determining that the access request is authenticated specifically comprises:
and inquiring the first white list according to the semantics of the API and the information of the source application, and judging whether the access request has permission on the target of the access request.
7. The method of claim 2,
the first white list includes: the corresponding relation between the API which sends the access request and the source application; and/or, the corresponding relation between the API sending the access request and the target information;
the second white list includes: and the API sending the access request corresponds to the source application and the target information.
8. The method of claim 7, wherein the method further comprises:
modifying the first white list and the second white list to dynamically adjust the authentication granularity of the access control and the authentication.
9. An access control apparatus, comprising:
the authentication module access control module is used for receiving an access request of the API and carrying out access control according to access control information corresponding to the access request and a preset inquiry list;
the authentication module is used for authenticating according to authentication information corresponding to the access request and a preset first white list when the access request is judged to pass the access control; wherein the authentication information corresponding to the access request includes: the semantics of an API corresponding to the access request and the information of a source application corresponding to the access request;
and the first response module is used for accepting the access request when the access request is judged to pass the authentication according to the authentication information and a preset first white list.
10. The apparatus of claim 9, wherein the apparatus further comprises a second response module to:
and when the access request is judged not to pass the access control according to the access control information, the second response module is used for acquiring a second white list and authenticating the access request according to the second white list.
11. The apparatus of claim 9, wherein the access control module is specifically configured to:
and acquiring the source IP address of the access request and the visitor signature corresponding to the access request.
12. The apparatus of claim 11, wherein the access control module is specifically configured to:
and inquiring a preset IP address list according to the source IP of the access request and/or inquiring a preset visitor signature list according to a visitor signature corresponding to the access request, and judging whether the access request passes the access control according to a preset strategy.
13. The apparatus of claim 9, wherein the authentication module is specifically configured to:
and acquiring the semantics of the API corresponding to the access request and the information of the source application corresponding to the access request.
14. The apparatus of claim 13, wherein the authentication module is further specifically configured to:
and acquiring the preset first white list corresponding to the source application according to the information of the source application.
15. The apparatus of claim 14, wherein the authentication module is specifically configured to query the first white list according to the semantics of the API and the information of the source application, and determine whether the access request has permission for a target of the access request.
16. The apparatus of claim 10,
the first white list includes: the corresponding relation between the API which sends the access request and the source application; and/or, the corresponding relation between the API sending the access request and the target information;
the second white list includes: and the API sending the access request corresponds to the source application and the target information.
17. The apparatus of claim 16, wherein the apparatus further comprises an authentication granularity adjustment module;
the authentication granularity adjusting module is configured to modify the first white list and the second white list to dynamically adjust the authentication granularity of the access control and the authentication.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610395197.2A CN107465650B (en) | 2016-06-06 | 2016-06-06 | Access control method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610395197.2A CN107465650B (en) | 2016-06-06 | 2016-06-06 | Access control method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN107465650A CN107465650A (en) | 2017-12-12 |
| CN107465650B true CN107465650B (en) | 2020-10-27 |
Family
ID=60545623
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610395197.2A Active CN107465650B (en) | 2016-06-06 | 2016-06-06 | Access control method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN107465650B (en) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN108471409B (en) * | 2018-03-15 | 2019-09-03 | 苏州思必驰信息科技有限公司 | The application programming interfaces authentication configuration method and system of voice dialogue platform |
| CN110414226A (en) * | 2018-04-28 | 2019-11-05 | 北京安天网络安全技术有限公司 | A kind of security maintenance method and system based on common-denominator target protection |
| CN109492358A (en) * | 2018-09-25 | 2019-03-19 | 国网浙江省电力有限公司信息通信分公司 | A kind of open interface uniform authentication method |
| CN109739806A (en) * | 2018-12-28 | 2019-05-10 | 安谋科技（中国）有限公司 | Memory pool access method, internal storage access controller and system on chip |
| CN110647540A (en) * | 2019-08-13 | 2020-01-03 | 平安普惠企业管理有限公司 | Business data query method and device, computer equipment and storage medium |
| CN112738100B (en) * | 2020-12-29 | 2023-09-01 | 北京天融信网络安全技术有限公司 | Authentication method, device, authentication equipment and authentication system for data access |
| CN112733103A (en) * | 2021-01-11 | 2021-04-30 | 浪潮云信息技术股份公司 | Interface access control method and device |
| CN117336101B (en) * | 2023-11-29 | 2024-02-23 | 南京中孚信息技术有限公司 | Fine-grained network access control method, system, equipment and medium |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1816192A (en) * | 2005-02-04 | 2006-08-09 | 法国无线电话公司 | Process for the secure management of the execution of an application |
| CN101034990A (en) * | 2007-02-14 | 2007-09-12 | 华为技术有限公司 | Right management method and device |
| CN103514052A (en) * | 2013-08-15 | 2014-01-15 | 飞天诚信科技股份有限公司 | Multi-application mutually-accessing method and smart card |
| CN104317626A (en) * | 2014-11-13 | 2015-01-28 | 北京奇虎科技有限公司 | Application software permission control method, device and system for terminal equipment |
| CN105404796A (en) * | 2015-10-21 | 2016-03-16 | 浪潮电子信息产业股份有限公司 | JavaScript source file protection method and apparatus |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8775618B2 (en) * | 2010-08-02 | 2014-07-08 | Ebay Inc. | Application platform with flexible permissioning |
-
2016
- 2016-06-06 CN CN201610395197.2A patent/CN107465650B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1816192A (en) * | 2005-02-04 | 2006-08-09 | 法国无线电话公司 | Process for the secure management of the execution of an application |
| CN101034990A (en) * | 2007-02-14 | 2007-09-12 | 华为技术有限公司 | Right management method and device |
| CN103514052A (en) * | 2013-08-15 | 2014-01-15 | 飞天诚信科技股份有限公司 | Multi-application mutually-accessing method and smart card |
| CN104317626A (en) * | 2014-11-13 | 2015-01-28 | 北京奇虎科技有限公司 | Application software permission control method, device and system for terminal equipment |
| CN105404796A (en) * | 2015-10-21 | 2016-03-16 | 浪潮电子信息产业股份有限公司 | JavaScript source file protection method and apparatus |
Also Published As
| Publication number | Publication date |
|---|---|
| CN107465650A (en) | 2017-12-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107465650B (en) | Access control method and device | |
| US11308126B2 (en) | Different hierarchies of resource data objects for managing system resources | |
| US10404708B2 (en) | System for secure file access | |
| KR102355480B1 (en) | System and method for supporting security in a multitenant application server environment | |
| US20200327244A1 (en) | System for database access restrictions using ip addresses | |
| US11675774B2 (en) | Remote policy validation for managing distributed system resources | |
| US10951661B1 (en) | Secure programming interface hierarchies | |
| US10263994B2 (en) | Authorized delegation of permissions | |
| US7865521B2 (en) | Access control for elements in a database object | |
| US10831915B2 (en) | Method and system for isolating application data access | |
| CN108289098B (en) | Authority management method and device of distributed file system, server and medium | |
| US8589569B2 (en) | Method and apparatus for invoking a plug-in on a server | |
| WO2021013033A1 (en) | File operation method, apparatus, device, and system, and computer readable storage medium | |
| US10528749B2 (en) | Methods and apparatus for containerized secure computing resources | |
| KR20150052010A (en) | Network system for implementing a cloud platform | |
| US20110270885A1 (en) | Security configuration systems and methods for portal users in a multi-tenant database environment | |
| US10650387B2 (en) | User access to a registry of business entity definitions | |
| US20200233907A1 (en) | Location-based file recommendations for managed devices | |
| CN114417303A (en) | Login authentication management method, device, processor and machine-readable storage medium | |
| US20120079278A1 (en) | Object security over network | |
| CN111090839B (en) | Resource operation authority management method and device, electronic equipment and storage medium | |
| US10789179B1 (en) | Decentralized access management in information processing system utilizing persistent memory | |
| CN111444483A (en) | Authentication method, device and equipment | |
| US20240143825A1 (en) | Sidecar data services for enforcing data policies | |
| US20240064148A1 (en) | System and method for managing privileged account access |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |