Cross-microservice authentication and authorization

Abstract

The authorization policy defines the permissions exposed by the microservices. When a microservice is invoked, it contains an access token. An application identifier, uniquely identifying the invoking application, is extracted from this token. The access pattern used by the invoking application to obtain the access token and make the invoice to the microservice is identified. Based on the application identifier and the identified access pattern, the permissions granted to the invoking application can be identified in the authorization policy. Based on the granted permissions, an authorization decision is made regarding whether to authorize the invoice.

Description

Background Technology

[0001] Computing systems are widely used. Some computing systems host services that can be accessed by one or more different organizations or tenants. Some services are written as relatively large applications that handle multiple different aspects of the service. For example, a service might be written as a single application that handles an organization's email, to-do list, and calendar functions.

[0002] However, recently, such services are often decomposed into microservices. Within the context of the overall service or computing system, microservices are loosely coupled with other microservices. Thus, for example, one microservice might perform email functionality, while a separate microservice performs functionality related to to-do lists, and yet another microservice performs scheduling tasks in a calendar system.

[0003] It is not uncommon for microservices to expose application programming interfaces (APIs). Other microservices (or other requesting entities) can call the API to perform various tasks.

[0004] The above discussion provides only general background information and is not intended to help determine the scope of the subject matter for which protection is sought. Summary of the Invention

[0005] The authorization policy defines the permissions exposed by the microservices. When a microservice is invoked, it includes an access token. An application identifier, uniquely identifying the invoking application, is extracted from the access token. The access pattern used by the invoking application to obtain the access token and invoke the microservice is identified. Based on the application identifier and the identified access pattern, the permissions granted to the invoking application can be identified in the authorization policy. Based on the granted permissions, an authorization decision is made regarding whether to authorize the invoice.

[0006] This summary is provided to introduce a selection of concepts in a simplified form, which will be further described in the detailed description below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to aid in determining the scope of the claimed subject matter. The claimed subject matter is not limited to implementations that address any or all of the shortcomings mentioned in the background. Attached Figure Description

[0007] Figure 1 This is a block diagram of an example computing system architecture.

[0008] Figure 2 This is a block diagram showing a more detailed example of an authorization decision generator.

[0009] Figure 3A and Figure 3B The illustration shows the explanation in Figure 1The flowchart shown is an example of a computing system architecture that performs authentication and authorization operations on requests between microservices.

[0010] Figure 4 This shows what is deployed in a cloud computing architecture. Figure 1 The diagram shows a block diagram of the computing system architecture.

[0011] Figure 5 This is a block diagram illustrating an example of the computing environment that can be used in the architecture shown in the previous diagram. Detailed Implementation

[0012] When using multiple different microservices to implement a service, the microservices typically need to communicate with each other to provide acceptable performance for the overall service. However, none of the microservices need to have full access to data controlled by all the other microservices.

[0013] Consider the example mentioned above, and suppose the services include a to-do list (or task management) microservice, a calendar microservice, an email microservice, etc. A user on a mobile app might want to access their to-do list and perform administrative actions (such as adding or deleting list items). In this case, the user can interact with the mobile app that interacts with the to-do list microservice. However, the task list data might be owned by the calendar microservice. Therefore, the user could request the to-do list microservice to perform actions on the task list data. In this case, the to-do list microservice must make an interaction request to the calendar microservice that owns the task list data.

[0014] In such a scenario, the to-do list microservice does not need full access to all calendar data. For example, the to-do list microservice does not need access to meetings scheduled on the user's calendar. Therefore, permissions granted by the calendar microservice should restrict the permissions granted to the to-do list microservice to only access the task list data on the calendar microservice. Furthermore, the to-do list microservice should authenticate itself with the calendar microservice before granting any permissions to the calendar microservice.

[0015] This type of authorization and authentication management can be very difficult to control across microservices. Furthermore, when adding new microservices or modifying existing ones, it becomes difficult to control changes to the authentication and authorization processes corresponding to those microservices.

[0016] Therefore, this description pertains to a central microservice authorization and authentication computation system (collectively referred to as the microservice AUTH computation system). Each microservice has authentication metadata and authorization policy metadata. The authentication metadata identifies the microservice and can be used to request access tokens to access different microservices. The authorization policy metadata defines the types of permissions that a microservice exposes to other microservices or other requesting entities (such as mobile device applications, web applications, etc.), and it uses different access patterns to define the permissions granted to different microservices (or requesting entities). Although the authentication and authorization metadata correspond to specific microservices, they are managed within the central microservice AUTH computation system. In this way, it is easier to make changes to the authentication and authorization metadata during runtime and to adapt it to new or modified microservices.

[0017] Figure 1 This is a block diagram illustrating an example of a computing system architecture 100, in which a microservice AUTH computing system 102 is shown to be accessed by multiple different microservices 104-106 that implement services provided by a service computing system 108. Figure 1 It is also shown that users 114-116 can use multiple different user computing systems 110-112 to access one or more microservices 104-106 via network 117. User computing systems 110-112 can be implemented on various types of user devices, such as mobile devices, laptops, desktop computers, etc.

[0018] Network 117 can be a variety of different types of networks. It can include, for example, wide area networks, local area networks, cellular networks, near field communication networks, or any of a variety of other networks or combinations thereof.

[0019] exist Figure 1 In this context, user computing system 110 is shown generating user interface 118 for user 114 to interact with. User 114 illustratively interacts with user interface 118 to control and manipulate user computing system 110, as well as portions of microservices 104-106 in service computing system 108.

[0020] User computing system 112 is shown generating user interface 120 for user 116 to interact with. User 116 interacts with user interface 120 to control and manipulate user computing system 112 and some parts of microservices 104-106 in service computing system 108.

[0021] The microservice AUTH computing system 102 illustratively includes one or more processors or servers 122, authentication storage 124, authorization storage 126, one or more authentication servers 128, one or more authorization servers 130, an interaction processing system 132, and is capable of including various other items 134. The authentication storage 124 is capable of including a set of authentication metadata 136-138 corresponding to each microservice 104-106.

[0022] Microservices 104-106 can access authentication server 128 to obtain authentication statements (e.g., tokens) that can be used to access other microservices. Therefore, authentication server 128 can include metadata exchange system 140, authentication statement generator / token issuer 142, token verification component 144, front-end system 146, and can include other items 148.

[0023] Frontend system 146 can expose interfaces for access by microservices 104-106, or it can be accessed by microservices 104-106 and by authentication server 130 in other ways. For example, when microservice 104 wants to access microservice 106, it can call the API exposed by frontend system 146 in authentication server 128 to obtain an access token. Metadata interaction system 140 interacts with authentication store 124 to obtain authentication metadata corresponding to microservice 104 (and / or microservice 106). Authentication statement generator / token issuer 142 can issue tokens to microservice 104, which microservice 104 can use to access microservice 106.

[0024] The authorization store 126 can include multiple sets of authorization policy metadata (e.g., multiple authorization policies) 150-152. In one example, a separate authorization policy 150-152 is stored for each microservice 104-106. Each authorization policy defines which microservices are allowed to access the microservice corresponding to the authorization policy (e.g., the receiving microservice) (e.g., the requesting microservice). It also defines the specific permissions granted to the requesting microservice. In one example, this is achieved by using the application identifier (App ID) of the requesting microservice and its access pattern used to request that access. This will be described in more detail below.

[0025] Authorization server 130 includes a metadata interaction system 154, an authorization decision maker 156, and a front-end system 158, and can include other items 160. For example, suppose microservice 104 is requesting access to microservice 106 (e.g., microservice 104 is the requesting microservice, and microservice 106 is the receiving microservice). Upon requesting access, microservice 104 invokes microservice 106 and provides an access token. The requested permissions can be provided along with the access token and the request, or assigned upon access. Microservice 106 can provide this information to authorization server 130 via front-end system 158. Authorization server 130 can verify the token and obtain an App ID, either directly or using authentication server 128. Authorization decision maker 156 then identifies the access pattern used by requesting microservice 104 and, in conjunction with the App ID, uses metadata interaction system 154 to obtain an applicable authorization policy 150. Once an applicable authorization policy (or multiple policies) is identified, the authorization decision generator 156 can identify the permissions to be granted to the requesting microservice 104 within that policy (or those policies). It can then determine whether the access requested by microservice 104 is included in those permissions. If so, it can issue a decision to grant the requested access. Conversely, if the requested access is not within the scope of permissions granted according to the authorization policy, the authorization decision generator 156 can issue a decision to deny the access request as an unauthorized request.

[0026] Figure 2 A block diagram of an example of the authorization decision generator 130 is shown in more detail. Figure 2 The authorization decision generator 130 is shown to include an App ID extractor 162, an access pattern identifier component 164, an applicable authorization policy identifier component 166, a permission identifier 168, a decision generation component 170, a decision output component 172, and may include other items 174. The App ID extractor 162 extracts the App ID from the access token, and the access pattern identifier component 164 identifies the access pattern used by the requesting microservice 104. Some examples of access patterns are based on user interaction requests (e.g., "Get my to-do list items"), while others may be some form of background processing (e.g., "Send a reminder about a due task in the to-do list"). These can be treated differently. For example, a background process may not need to have the same level of access as a user interaction process.

[0027] Using this information, given the identified access pattern, the applicable authorization policy identifier component 166 can identify all applicable authorization policies 150-152, and the permission identifier 168 can identify the permissions granted through those policies. The decision generation component 170 then analyzes the granted permissions to determine whether they include the permissions requested by the requesting microservice 104. If yes, the decision output component 172 outputs a decision to grant the requested access. If no, the decision output component 172 outputs a decision to deny the requested access.

[0028] Figure 3A and Figure 3B The diagram illustrates an example of how architecture 100 manages the authentication and access operations for access requests made on a receiving microservice (e.g., microservice 106).

[0029] First, assume that microservices 104-106 register with microservice AUTH computing system 102. This is indicated by box 180 in the flowchart of Figure 3. When a microservice registers, authentication metadata 136-138 also registers with microservice AUTH computing system 102. This authentication metadata describes what is allowed for access by the microservice and is anchored to available permissions, access modes, and other partition information (e.g., the set of permissions allowed in Geolocation 1 is different from the set of permissions allowed in Geolocation 2). The authentication metadata illustratively includes an app ID, uniquely identifying the microservice that registered it. This is indicated by box 182 in the flowchart of Figure 3. Microservices can register with microservice AUTH computing system 102 in other ways, and the authentication metadata can also include other items. This is indicated by box 184.

[0030] Similarly, assume that the authorization policy metadata 150-152 (also referred to as the authorization policy) corresponding to each microservice 104-106 is registered with the microservice AUTH computing system 102. This is indicated by box 186. In one example, each authorization policy includes a policy identifier 188 that uniquely identifies the policy. The authorization policy also illustratively includes the identity and description of the corresponding microservice. This is indicated by box 190. It includes the context in which authentication is permitted, such as what certificates it must present, and whether it can be partitioned on a logical or physical partition basis. For example, it is possible to allow a microservice to authenticate microservices on Geolocation1, but not microservices on Geolocation2. Thus, additional control is provided over which targets a microservice can authenticate to. The authorization policy can also include permissions exposed by the corresponding microservice to other microservices (or requesting entities) that may request access. This is indicated by box 192. It includes the identity of the microservice (or other requesting entity) with permissions to access the microservice. This is indicated by box 194. In one example, when a microservice registers with the microservice AUTH computing system 102, the identity is an application identifier in the authentication metadata corresponding to the microservice. The authorization policy also illustratively includes permissions granted for multiple different access modes. This is indicated by box 196. The authorization policy can also include additional or different data, as indicated by box 198.

[0031] As an example, a set of authorization policy metadata (e.g., authorization policy 150) can be implemented as a JSON-encoded file, such as the file illustrated in Table 1 below.

[0032] Table 1

[0033]

[0034] As can be seen, the authorization policy includes the name of the corresponding microservice and a unique identifier that uniquely identifies the authorization policy. This includes the time the authorization policy was created and a Boolean field indicating whether the specific authorization policy is enabled. If not enabled, it will not be considered at runtime. The exemplary authorization policy shown in Table 1 also includes an alias for the policy owner. The owner can be an individual or a group, such as a team. This includes an identifier for the URL corresponding to the microservice (in the example shown in Table 1, it is an API) and the permissions manifested by the API. It also includes a set of authorization permissions for access tokens for various different types of access modes.

[0035] The access patterns used in the examples shown in Table 1 include a set of authorization permissions for direct access, where the device or web application requests an access token directly from the token issuer and uses that token to authenticate the microservice (e.g., an API). The authorization policy includes a set of authorization permissions for protected forwarding access (using a protected forwarding token or PFT). This type of access pattern is used when a middleware service or microservice receives an access token issued to a device or web application and forwards it along with an API request to the ultimately accessed microservice. Figure 1 The authorization policies shown also include authorization permissions for access patterns implemented for High Privileged Access (or HPA). This access pattern is used when a service or microservice does not have an access token, and an access token is requested from the token issuer without any proof of the authenticated subject (such as background processing), and further access is granted to a wide range of tenants (even, for example, authorizing impersonation of users within the tenant).

[0036] Now consider each access mode in more detail. The direct access mode has permissions applied to an access token issued to an application (e.g., a requesting entity), which are directly played or forwarded by the application. The application is identified by the App ID in the token. This means that permissions listed in the authorization policy for a specific App ID are granted, in addition to any other permissions that may already exist in the access token for that App ID. Permissions in the authorization policy can be granted differently depending on whether the token is issued to a requesting entity as a user or to a requesting entity as an application. To grant direct permissions to an application, add a section to the “ClientAccessProtocol” shown in Table 1. This section includes attributes for: the application's friendly name, the application's identity (app ID), authorized user permissions for the delegated token, and authorized application permissions for the application-only token. An example of the client access protocol section is shown in Table 2.

[0037] Table 2

[0038]

[0039] Configuring permissions for an access mode implemented as a protected forwarding access mode applies to the access token issued to the application and then forwarded by a middleware service or API. Access permissions can include two aspects. One aspect is that it will accept access tokens forwarded by a specific service or API, and the second aspect is that it will assign additional permissions based on the service or API that forwards the access token and / or the permissions in the forwarded access token.

[0040] We will now discuss examples further illustrating the protected forwarding access pattern. Suppose a client issues an access token to service A, which then submits the token to the final microservice or API. This means the "front-door service" (the service that initially issues the token to it) is service A, and the "downstream API" is the final API or microservice that receives the token. In another scenario supported by this example, suppose a client issues a token to a first service B, which forwards the token to service A, and service A then sends the token to the final API or microservice. In this scenario, the "front-door service" is service B, the "actor" remains service A, and the "downstream API" remains the final API or microservice that receives the token. Also suppose, for the sake of this example, the client is also able to send a token to service C, which forwards it to service A, which in turn forwards it to the final API or microservice. In this case, the "front-door service" is service C, the "actor" remains service A, and the "downstream API" remains the final API or microservice that receives the token.

[0041] In this example, to allow access in the downstream API, rules must be granted to reflect the presence of actor A who forwards the token, and possibly different front-door services invoked through actor A. A simplified structure allowing the above example might be as shown in Table 3. Information that should be known to configure access permissions for this protocol includes the actor's friendly name, the actor's app ID, the friendly name of any front-door service, the allowed audience or sites, and the expected permissions in the token.

[0042] Table 3

[0043]

[0044] High-privileged access grants a first-party access service broad access to the final microservice or API that requests access, including the ability to impersonate any user of the final microservice or API. High-privileged access is manifested in the ability of a first-party invoking service to use any of a variety of different access protocols.

[0045] The attributes used to grant high-privileged access to an application include the friendly name of the calling first-party service, the app ID of the calling first-party service, and the account type, which define the range of data that the calling first-party service is allowed to access. These attributes also include indications about whether the calling first-party service will use a POP authenticator, a token indicating whether the first-party service is allowed to use a single reusable token to claim its identity, filters defining user impersonation permissions that the first-party service is allowed to access, and filters defining app-only permissions that the first-party service is allowed to access. To grant high-privileged access to a first-party service, a section is added to the “HighPrivilegedAccessProtocol” section of the authorization policy illustrated in Table 1. An example of this is shown in Table 4 below.

[0046] Table 4

[0047]

[0048] Returning to the flowchart shown in Figure 3, let's now assume that authorization policies 150-152 have been stored in the microservice AUTH computing system 102. This description will focus on a microservice that accesses a second microservice using an access token. For the purposes of this example, we will assume that microservice 104 is the requesting microservice (or requesting entity) and microservice 106 is the microservice that receives the call or request and is being accessed (the receiving microservice).

[0049] According to this example, requesting microservice 104 requests an access token from authentication server 128 to access receiving microservice 106. This is indicated by box 200 in the flowchart of Figure 3. Authentication statement generator / token issuer 142 then issues a token based on authentication metadata (stored in storage 124) corresponding to microservice 104 and / or microservice 106. The token will include the app ID for requesting microservice 104, and may also include permissions corresponding to the token. This is indicated by box 202.

[0050] Once the requesting microservice 104 receives the token, it invokes the receiving microservice 106, which includes the token, for access. The invocation of the receiving microservice 106 along with the access token is indicated by box 204 in the flowchart of Figure 3.

[0051] For the authentication server receiving microservice 106 (in Figure 1In the example shown, authentication server 128 then verifies the access token provided by microservice 104. This is indicated by box 206. Authorization server 130 then identifies any applicable authorization policies 150-152 in authorization store 126. This is indicated by box 208. For example, app ID extractor 162 is able to extract the app ID from the access token, and access pattern identifier component 164 is able to identify the access pattern used by requesting microservice 104. Based on the app ID and access pattern, applicable authorization policy identifier component 166 is able to identify the applicable authorization policy, and permission identifier 168 is able to identify the permissions to be assigned to requesting microservice 104. Identifying the applicable authorization policy based on the app ID is indicated by box 210 in the flowchart of Figure 3, and identifying it based on the access pattern used by requesting microservice 104 is indicated by box 212. Authorization server 130 is also able to identify applicable authorization policies and permissions in other ways, and this is indicated by box 214.

[0052] The decision generation component 120 then applies permissions to the call made by the requesting microservice 104 to determine whether the call is authorized (e.g., whether the permissions in the applicable authorization policy include the permissions in the request or call made by microservice 104). This is indicated by box 216 in the flowchart of Figure 3.

[0053] The decision output component 172 then provides the decision to the receiving microservice 106, indicating whether the decision grants or denies access to the requesting microservice 104. The output of the decision to the receiving microservice 106 is indicated by box 218 in the flowchart of Figure 3.

[0054] In one example, all interactions with the microservice AUTH computing system 102 can be tracked by the interaction processing system 132. Therefore, for the purposes of this discussion, it is assumed that the interaction processing system 132 is detecting and tracking interactions between various microservices and their interactions with the microservice AUTH computing system 102. For example, the interaction processing system 132 can include a logging system 220, a risk analysis system 222, and other items 224. The logging system 220 can log various interactions so that they can be analyzed later. The risk analysis system 222 can be configured to associate interactions with risk levels. For example, for a specific access pattern, permissions may be divided into different risk categories or levels. The greater the granted permission, the higher the risk category. This can be based on access patterns, the audience allowed access, or other methods.

[0055] Therefore, once a call is made from microservice 104 to microservice 106, the call can be submitted to risk analysis system 222, which assigns a risk level associated with the call. Thus, even if authorization decision generator 156 outputs a decision to grant the requested access, risk analysis system 222 may also output a risk level indicator indicating the risk level corresponding to the requested access. Therefore, receiving microservice 106 (or the management user of microservice 106 notified of the risk level) can overturn the decision to grant the requested access and instead deny the requested access based on the risk level associated with it. Therefore, a risk level assessment is output in addition to the decision of authorization decision generator 156, as indicated by box 226 in the flowchart of Figure 3. The decision can include other items or can be output in other ways, as indicated by box 228.

[0056] Log system 220 also records the interactions and can record the decision output of authorization decision generator 156. This recording of interactions is indicated by box 230 in the flowchart of Figure 3. Risk analysis system 222 can generate risk assessments using a risk assessment model. The model can be trained based on interactions and other criteria to classify various requests for access into different risk levels. In such an example, interactions recorded by logging system 220 can be provided to risk analysis system 222, which can add data representing the interactions to the risk assessment model. In this way, the model can be trained to improve its use. This is indicated by box 232 in the flowchart of Figure 3.

[0057] It should be noted that the access patterns mentioned in this article are merely examples. They should also be expanded to include other access patterns.

[0058] It will be noted that the above discussion has described a variety of different systems, components, and / or logic. It will be appreciated that such systems, components, and / or logic units can include hardware items (such as processors and associated memory, or other processing components, some of which are described below) that perform the functions associated with those systems, components, and / or logic units. Additionally, said systems, components, and / or logic units can include software loaded into memory and subsequently run by a processor, server, or other computing component, as described below. said systems, components, and / or logic units can also include different combinations of hardware, software, firmware, etc., some examples of which are described below. These are merely some examples of the different structures that can be used to form the systems, components, and / or logic described above. Other structures can also be used.

[0059] Processors and servers have been mentioned in this discussion. In one example, the processor and server include a computer processor with associated memory and timing circuitry, not shown separately. It is a functional part of the system or device to which it belongs, activated by and facilitating the function of other components or items in those systems.

[0060] Similarly, many user interface displays have been discussed. They can take many different forms and can incorporate a variety of user-actuable input mechanisms. For example, these user-actuable input mechanisms can be text boxes, checkboxes, icons, links, drop-down menus, search boxes, etc. They can also be actuated in various ways. For example, they can be actuated using click devices (such as trackballs or mice). They can be actuated using hardware buttons, switches, joysticks or keyboards, thumb switches or thumb pads, etc. They can also be actuated using virtual keyboards or other virtual actuators. Furthermore, if the screen displaying the display is a touch-sensitive screen, it can be actuated using touch gestures. Likewise, if the device displaying the display has a voice recognition component, it can be actuated using voice commands.

[0061] Many data storage methods have already been discussed. It is worth noting that each of these can be broken down into multiple data storage methods. For the system accessing them, all can be local or remote; or some can be local while others can be remote. All these configurations are envisioned in this paper.

[0062] Similarly, the accompanying diagram illustrates multiple boxes with functionality belonging to each box. It will be noted that fewer boxes can be used, thus requiring fewer components to perform the functionality. Likewise, more boxes can be used with functionality distributed among more components.

[0063] Figure 4 Is Figure 1The block diagram of architecture 100 shown herein, except that its components are set within a cloud computing architecture 500. Cloud computing provides computing, software, data access, and storage services without requiring end users to know the physical location or configuration of the system providing the service. In various examples, cloud computing provides services over a wide area network (such as the Internet) using appropriate protocols. For example, cloud computing providers offer applications over a wide area network and can access them via a web browser or any other computing component. The software or components of architecture 100, along with the corresponding data, can be stored on servers in remote locations. Computing resources in a cloud computing environment can be consolidated at remote data center locations or distributed. Cloud computing infrastructure can provide services over shared data centers, even if it appears to be a single access point for a user. Therefore, the components and functions described herein can be provided from a service provider in a remote location using a cloud computing architecture. Alternatively, they can be provided from conventional servers, or they can be installed directly on client devices, or otherwise.

[0064] The description is intended to include both public and private cloud computing. Cloud computing (both public and private) provides a largely seamless pool of resources and reduces the need for managing and configuring the underlying hardware infrastructure.

[0065] Public clouds are managed by a vendor and typically support multiple consumers using the same infrastructure. Similarly, unlike private clouds, public clouds free end users from managing the hardware. Private clouds can be managed by the organization itself, and the infrastructure is usually not shared with other organizations. The organization still maintains the hardware to some extent, such as through installation and maintenance.

[0066] exist Figure 4 In the example shown, some items are related to Figure 1 Those shown are similar and can be numbered similarly. Figure 4 Specifically, it is shown that the microservice AUTH computing system 102 and the service computing system 108 can reside in the cloud 502 (which can be public, private, or a combination of some public and others private). Therefore, users 114-116 access those systems through the cloud 502 using user computing systems 110, 112 (which can be located on user devices).

[0067] Figure 4 It also depicts another example of cloud architecture. Figure 4The illustration also envisions that some components can be located within cloud 502, while others cannot. By way of example, data stores 124 and 126 can be located outside of cloud 502 and accessed through cloud 502. In another example, interactive processing system 132 (or other items) can be located outside of cloud 502. Regardless of its location, it can be directly accessed by user devices via a network (WAN or LAN), it can be hosted as a service at a remote site, or it can be provided as a service through the cloud or accessed by a connectivity service residing in the cloud. All these architectures are envisioned in this document.

[0068] It will also be noted that Architecture 100, or parts thereof, can be deployed on a variety of different devices. Some of these devices include servers, desktop computers, laptops, tablets, or other mobile devices such as handheld computers, mobile phones, smartphones, multimedia players, personal digital assistants, etc.

[0069] Figure 5 This is one example of a computing environment where architecture 100 or a portion thereof can be deployed, for example. (Reference) Figure 5 An exemplary system for implementing some embodiments includes a computing device in the form of a computer 810 programmed as described above. Components of computer 810 may include, but are not limited to, a processing unit 820 (which may include a processor or server from previous figures), system memory 830, and a system bus 821 that couples various system components, including system memory, to the processing unit 820. System bus 821 may be any of a variety of bus architectures, including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example and not limitation, such architectures include Industry Standard Architecture (ISA) buses, Micro Channel Architecture (MCA) buses, Enhanced ISA (EISA) buses, Video Electronics Standards Association (VESA) local buses, and Peripheral Component Interconnect (PCI) buses (also referred to as mezzanine buses). Regarding Figure 1 The described memory and program can be deployed in Figure 5 In the corresponding part.

[0070] Computer 810 typically includes a variety of computer-readable media. Computer-readable media can be any available medium accessible to computer 810, and includes volatile and non-volatile media, removable and non-removable media. By way of example, and not limitation, computer-readable media can include computer storage media and communication media. Computer storage media are distinct from and do not include modulated data signals or carrier waves. They include hardware storage media, including volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital universal disk (DVD) or other optical disc storage, cassette tape, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to computer 810. Communication media typically embody other data in computer-readable instructions, data structures, program modules, or transport mechanisms, and includes any information delivery medium. The term "modulated data signal" refers to a signal whose one or more characteristics are set or altered in a manner that encodes information in the signal. By way of example and not limitation, communication media include wired media such as wired networks or direct wired connections, and wireless media such as acoustic, RF, infrared, and other wireless media. Any combination of the above should also be included within the scope of computer-readable media.

[0071] System memory 830 includes computer storage media in the form of volatile and / or non-volatile memory, such as read-only memory (ROM) 831 and random access memory (RAM) 832. The basic input / output system 833 (BIOS) is typically stored in ROM 831 and contains basic routines that facilitate the transfer of information between components within computer 810, for example, during startup. RAM 832 typically contains data and / or program modules that are readily accessible to and / or currently operated by processor unit 820. By way of example and not limitation, Figure 5 The operating system 834, application program 835, other program modules 836, and program data 837 are shown.

[0072] Computer 810 may also include other removable / non-removable volatile / non-volatile computer storage media. This is just one example. Figure 5A hard disk drive 841 is shown that reads from or writes to a non-removable, non-volatile magnetic medium, and an optical disk drive 855 that reads from or writes to a removable, non-volatile optical disk 856, such as a CD-ROM or other optical medium. Other removable / non-removable, volatile / non-volatile computer storage media that may be used in the exemplary operating environment include, but are not limited to, magnetic tape cartridges, flash memory cards, digital multifunction disks, digital videotapes, solid-state RAM, solid-state ROM, etc. The hard disk drive 841 is typically connected to the system bus 821 via a non-removable memory interface such as interface 840, and the optical disk drive 855 is typically connected to the system bus 821 via a removable memory interface such as interface 850.

[0073] Alternatively or additionally, the functions described herein may be performed at least in part by one or more hardware logic components. For example, but not limited to, hardware logic components of the illustrated types that may be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), etc.

[0074] The above discussion and Figure 5 The drive and its associated computer storage media shown provide storage for computer-readable instructions, data structures, program modules, and other data for the computer 810. Figure 5 For example, hard disk drive 841 is shown storing operating system 844, application programs 845, other program modules 846, and program data 847. Note that these components may be the same as or different from operating system 834, application programs 835, other program modules 836, and program data 837. Operating system 844, application programs 845, other program modules 846, and program data 847 are given different numbers here to indicate that they are at least different copies.

[0075] Users can input commands and information into computer 810 via input devices such as keyboard 862, microphone 863, and pointing devices 861 such as mouse, trackball, or touchpad. Other input devices (not shown) may include joysticks, game controllers, satellite antennas, scanners, etc. These and other input devices are typically connected to processing unit 820 via user input interface 860 coupled to the system bus, but may be connected via other interfaces and bus structures such as parallel ports, game ports, or Universal Serial Bus (USB). Visual display 891 or other types of display devices are also connected to system bus 821 via an interface such as video interface 890. In addition to a monitor, the computer may include other peripheral output devices such as speakers 897 and printer 896, which may be connected via output peripheral interface 895.

[0076] Computer 810 operates in a network environment using a logical connection to one or more remote computers (e.g., remote computer 880). Remote computer 880 may be a personal computer, handheld device, server, router, network PC, peer-to-peer device, or other public network node, and typically includes many or all of the elements described above with respect to computer 810. Figure 5 The logical connections described include Local Area Networks (LANs) 871 and Wide Area Networks (WANs) 873, but may also include other networks. This network environment is common in offices, enterprise-wide computer networks, intranets, and the Internet.

[0077] When used in a LAN networking environment, computer 810 connects to LAN 871 via a network interface or adapter 870. When used in a WAN networking environment, computer 810 typically includes a modem 872 or other unit for establishing communication over a WAN 873 (e.g., the Internet). The modem 872, which may be internal or external, can be connected to system bus 821 via user input interface 860 or other suitable mechanism. In a networking environment, program modules or portions thereof depicted with respect to computer 810 may be stored in a remote memory storage device. This is by way of example and not limitation. Figure 5 The remote application 885 is shown residing on the remote computer 880. It should be understood that the network connection shown is exemplary and other methods can be used to establish a communication link between computers.

[0078] It should also be noted that the different examples described herein can be combined in different ways. That is, parts of one or more examples can be combined with parts of one or more other examples. All of this is conceived in this document.

[0079] Example 1 is a computer-implemented method that includes:

[0080] Receive an access request and access token from the requesting entity for the microservice.

[0081] The identity of the requesting entity is obtained from the access token;

[0082] Identify the access pattern used by the requesting entity to obtain the access token and request access to the microservice;

[0083] Based on the identity of the requesting entity and the identified access pattern, the permissions corresponding to the microservice in the access policy are identified; and

[0084] Generate an authorization output indicating the authorization determination for the access request.

[0085] Example 2 is a computer-implemented method of any or all of the foregoing examples, and further includes:

[0086] The access token is verified before authorization is granted.

[0087] Example 3 is a computer-implemented method of any or all of the foregoing examples, wherein verifying the access token includes:

[0088] Identify the access permissions corresponding to the access token; and

[0089] Verify that the requested access is included in the access permissions.

[0090] Example 4 is a computer-implemented method of any or all of the foregoing examples, wherein generating the authorization determination includes:

[0091] If the permission identified from the access policy includes the requested access, then the authorization output of the authorized access request is generated.

[0092] Example 5 is a computer-implemented method of any or all of the foregoing examples, wherein generating the authorization determination includes:

[0093] If the permissions identified from the access policy do not include the requested access, then an authorization output is generated denying the access request.

[0094] Example 6 is a computer-implemented method of any or all of the foregoing examples, and also includes:

[0095] Register authentication metadata for the requesting entity and for the microservice with the authentication server;

[0096] The authentication server receives an access token request from the requesting entity, requesting the access token; and

[0097] The access token is issued from the authentication server to the requesting entity based on the authentication metadata.

[0098] Example 7 is a computer-implemented method of any or all of the foregoing examples, wherein identifying the access pattern includes:

[0099] The entity that issued the access token to it is identified as an application that directly sent the access token to the microservice; and

[0100] The access mode is identified as a direct access mode, and the identification of the permissions corresponding to the application in the access policy includes identifying the permissions in the access policy based on the identity of the application and the fact that the access mode is a direct access mode.

[0101] Example 8 is a computer-implemented method of any or all of the foregoing examples, wherein identifying the access pattern includes:

[0102] The requesting entity that issues the access token is identified as the application that sends the access token to the intermediate microservice, which then forwards the access token to the microservice; and

[0103] The access pattern is identified as a protected forwarding access pattern, and the identification of the permissions corresponding to the application in the access policy includes identifying the permissions in the access policy based on the identity of the application and the fact that the access pattern is a protected forwarding access pattern.

[0104] Example 9 is a computer-implemented method of any or all of the foregoing examples, wherein identifying the access pattern includes:

[0105] Identify that the requesting entity issuing the access token is a service or microservice that obtains the access token without providing authentication for a specific set of permissions; and

[0106] The access pattern is identified as a high-privilege access pattern, wherein identifying the permissions in the access policy corresponding to the application includes identifying the permissions in the access policy based on the identity of the service or microservice including the request entity and the fact that the access pattern is a high-privilege access pattern.

[0107] Example 10 is a computer-implemented method of any or all of the foregoing examples, and also includes:

[0108] The interaction processing system records interaction information, which includes the access request, the identity of the microservice, the identity of the requesting entity, the access mode indicator, the permission, the access policy identifier, and the authorization output indicating the authorization determination.

[0109] Example 11 is a computer-implemented method of any or all of the foregoing examples, and also includes:

[0110] A risk assessment model is generated based on the recorded interaction information, and the risk assessment model is configured to identify the risk assessment level based on the interaction information provided to the risk assessment model during runtime operation.

[0111] Example 12 is a computer-implemented method of any or all of the foregoing examples, and further includes:

[0112] The risk assessment model is used to generate runtime risk assessment levels corresponding to the interaction information provided to the risk assessment model during the runtime operation; and

[0113] Return the risk assessment model with the authorization defined.

[0114] Example 13 is a computer system comprising:

[0115] One or more processors; and

[0116] A memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform the following steps:

[0117] Receive an access request and access token from the requesting entity for the microservice.

[0118] The identity of the requesting entity is obtained from the access token;

[0119] Identify the access pattern used by the requesting entity to obtain the access token and request access to the microservice;

[0120] Based on the identity of the requesting entity and the identified access pattern, the permissions corresponding to the microservice in the access policy are identified; and

[0121] Generate an authorization output indicating the authorization determination for the access request.

[0122] Example 14 is a computer system of any or all of the foregoing examples, wherein the instructions cause the one or more processors to perform the following steps:

[0123] The access token is verified before authorization is granted.

[0124] Example 15 is a computer system of any or all of the foregoing examples, wherein verifying the access token includes:

[0125] Identify the access permissions corresponding to the access token; and

[0126] Verify that the requested access is included in the access permissions.

[0127] Example 16 is a computer system of any or all of the foregoing examples, wherein generating the authorization determination includes:

[0128] If the permission identified from the access policy includes the requested access, then an authorization output is generated that authorizes the access request; and.

[0129] If the permissions identified from the access policy do not include the requested access, then an authorization output is generated denying the access request.

[0130] Example 17 is a computer system of any or all of the foregoing examples, wherein identifying the access pattern includes:

[0131] The entity that issued the access token to it is identified as an application that directly sent the access token to the microservice; and

[0132] The access mode is identified as a direct access mode, and the identification of the permissions corresponding to the application in the access policy includes identifying the permissions in the access policy based on the identity of the application and the fact that the access mode is a direct access mode.

[0133] Example 18 is a computer system of any or all of the foregoing examples, wherein identifying the access pattern includes:

[0134] The requesting entity that issues the access token is identified as the application that sends the access token to the intermediate microservice, which then forwards the access token to the microservice; and

[0135] The access pattern is identified as a protected forwarding access pattern, and the identification of the permissions corresponding to the application in the access policy includes identifying the permissions in the access policy based on the identity of the application and the fact that the access pattern is a protected forwarding access pattern.

[0136] Example 19 is a computer system of any or all of the foregoing examples, wherein identifying the access pattern includes:

[0137] Identify that the requesting entity issuing the access token is a service or microservice that obtains the access token without providing authentication for a specific set of permissions; and

[0138] The access pattern is identified as a high-privilege access pattern, wherein identifying the permissions in the access policy corresponding to the application includes identifying the permissions in the access policy based on the identity of the service or microservice including the request entity and the fact that the access pattern is a high-privilege access pattern.

[0139] Example 20 is a computing system that includes:

[0140] One or more processors; and

[0141] A memory storing instructions that, when executed by one or more processors, cause the one or more processors to perform the following steps:

[0142] Receive an access request and access token from the requesting entity for the microservice.

[0143] The identity of the requesting entity is obtained from the access token;

[0144] Identify the access pattern used by the requesting entity to obtain the access token and request access to the microservice;

[0145] Based on the identity of the requesting entity and the identified access pattern, the permissions corresponding to the microservice in the access policy are identified.

[0146] Generate an authorization output indicating the authorization determination regarding the access request;

[0147] The interaction processing system records interaction information, which includes the access request, the identity of the microservice, the identity of the requesting entity, the access mode indicator, the permission, the access policy identifier, and the authorization output indicating the authorization determination.

[0148] A risk assessment model is generated based on the recorded interaction information, and the risk assessment model is configured to identify the risk assessment level based on the interaction information provided to the risk assessment model during runtime operation.

[0149] The risk assessment model is used to generate runtime risk assessment levels corresponding to the interaction information provided to the risk assessment model during the runtime operation; and

[0150] Return the risk assessment model with the authorization defined.

[0151] Although the subject matter has been described in language specific to structural features and / or methodological actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are disclosed as exemplary forms for implementing the claims.

Claims

1. A computer-implemented method, comprising: Receive an access request and access token from the requesting entity for the microservice. The identity of the requesting entity is obtained from the access token; Identify the access pattern used by the requesting entity to obtain the access token and request access to the microservice; Based on the identity of the requesting entity and the identified access pattern, the permissions corresponding to the microservice in the access policy are identified. as well as Based on the identified permissions, generate an authorization output indicating the authorization determination regarding the access request. The access pattern identification includes one of the following: (1) Identify that the requesting entity that issues the access token to it is an application that directly sends the access token to the microservice; and The access mode is identified as a direct access mode, and the identification of the permissions corresponding to the application in the access policy includes identifying the permissions in the access policy based on the identity of the application and the fact that the access mode is a direct access mode. (2) Identify that the requesting entity issuing the access token is an application that sends the access token to an intermediate microservice, which forwards the access token to the microservice; and The access pattern is identified as a protected forwarding access pattern, and the identification of permissions corresponding to the application in the access policy includes identifying the permissions in the access policy based on the application's identity and the fact that the access pattern is a protected forwarding access pattern; or (3) Identify that the requesting entity that issues the access token to it is a service or microservice that obtains the access token without providing authentication for a specific set of permissions; and The access pattern is identified as a high-privilege access pattern, and the identification of the permissions corresponding to the service or microservice in the access policy includes: identifying the permissions in the access policy based on the identity of the service or microservice including the request entity and the fact that the access pattern is a high-privilege access pattern.

2. The computer-implemented method according to claim 1, further comprising: The access token is verified before authorization is granted.

3. The computer-implemented method according to claim 2, wherein, Verifying the access token includes: Identify the access permissions corresponding to the access token; and Verify that the requested access is included in the access permissions.

4. The computer-implemented method according to claim 1, wherein, Generating the authorization determination includes: If the permission identified from the access policy includes the requested access, then the authorization output that authorizes the access request is generated.

5. The computer-implemented method according to claim 4, wherein, Generating the authorization determination includes: If the permissions identified from the access policy do not include the requested access, then an authorization output is generated denying the access request.

6. The computer-implemented method according to claim 1, further comprising: Register authentication metadata for the requesting entity and for the microservice with the authentication server; The authentication server receives an access token request from the requesting entity, requesting the access token. as well as The access token is issued from the authentication server to the requesting entity based on the authentication metadata.

7. The computer-implemented method according to claim 1, further comprising: The interaction processing system records interaction information, which includes the access request, the identity of the microservice, the identity of the requesting entity, the access mode indicator, the permission, the access policy identifier, and the authorization output indicating the authorization determination.

8. The computer-implemented method according to claim 7, further comprising: A risk assessment model is generated based on the recorded interaction information, and the risk assessment model is configured to identify the risk assessment level based on the interaction information provided to the risk assessment model during runtime operation.

9. The computer-implemented method according to claim 8, further comprising: The risk assessment model is used to generate a runtime risk assessment level corresponding to the interaction information provided to the risk assessment model during the runtime operation; as well as Return the risk assessment model with the authorization defined.

10. A computer system, comprising: One or more processors; as well as A memory storing instructions that, when executed by the one or more processors, cause the one or more processors to perform the following steps: Receive an access request and access token from the requesting entity for the microservice. The identity of the requesting entity is obtained from the access token; Identify the access pattern used by the requesting entity to obtain the access token and request access to the microservice; Based on the identity of the requesting entity and the identified access pattern, the permissions corresponding to the microservice in the access policy are identified. as well as Based on the identified permissions, generate an authorization output indicating the authorization determination regarding the access request. The access pattern identification includes one of the following: (1) Identify that the requesting entity that issues the access token to it is an application that directly sends the access token to the microservice; and The access mode is identified as a direct access mode, and the identification of the permissions corresponding to the application in the access policy includes identifying the permissions in the access policy based on the identity of the application and the fact that the access mode is a direct access mode. (2) Identify that the requesting entity issuing the access token is an application that sends the access token to an intermediate microservice, which forwards the access token to the microservice; and The access pattern is identified as a protected forwarding access pattern, and the identification of permissions corresponding to the application in the access policy includes identifying the permissions in the access policy based on the application's identity and the fact that the access pattern is a protected forwarding access pattern; or (3) Identify that the requesting entity that issues the access token to it is a service or microservice that obtains the access token without providing authentication for a specific set of permissions; and The access pattern is identified as a high-privilege access pattern, and the identification of the permissions corresponding to the service or microservice in the access policy includes: identifying the permissions in the access policy based on the identity of the service or microservice including the request entity and the fact that the access pattern is a high-privilege access pattern.

11. The computer system according to claim 10, wherein, The instructions cause the one or more processors to perform the following steps: The access token is verified before authorization is granted.

Images