Keyless authentication scheme for computing services

Abstract

This document discloses a keyless authentication technique for computing services in a distributed computing system. An exemplary technique includes, upon receiving a command to instantiate a computing service, transmitting a request to an authentication service for an identity assertion token corresponding to the application executing the instantiation of the computing service. The exemplary technique can also include, upon receiving the requested identity assertion token, storing the received identity assertion token in a container and modifying an entry in a configuration file within the container that allows the instantiated computing service to access the stored identity assertion token and use it to authenticate with the authentication service.

Description

Background Technology

[0001] Remote or “cloud” computing systems typically utilize a large number of remote servers located in data centers to provide computing, storage, networking, and other computing services. These remote servers can be interconnected via computer networks to form one or more computing clusters. Each remote server in a computing cluster can host one or more virtual machines (“VMs”), containers, virtual switches, load balancers, and other types of virtualization components for resource sharing. During operation, VMs or containers facilitate the execution of user applications to provide corresponding computing services to users. Summary of the Invention

[0002] The present invention is provided in a simplified form to introduce selected concepts, 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 limit the scope of the claimed subject matter.

[0003] In a specific computing facility, a remote server can provide computing services to multiple subscribers or "tenants" through the virtualization of computing, storage, networking, or other suitable types of physical resources. For example, the server can execute appropriate instructions on its operating system to provide a hypervisor for managing multiple virtual machines hosted on the server. The server can also provide a container manager for managing multiple containers on the server. Each virtual machine or container can execute a suitable application to provide computing services to the tenant's users. In this way, multiple tenants can share physical resources as computing services on the server. On the other hand, a single tenant can also consume physical resources from multiple servers, storage devices, or other suitable components of the computing facility as a single computing service.

[0004] In a specific computing facility, various computing services can interact with each other when providing computing services to tenants. For example, computing services can be organized as platform services and microservices supporting those platform services. For instance, a platform service could be an email exchange service configured to handle email receiving, forwarding, synchronization, and other suitable operations. An exemplary email exchange service is provided by Microsoft Corporation of Redmond, Washington. The email exchange service allows users to access user content such as emails and attachments in their mailboxes. To provide this content, the email exchange service relies on one or more microservices. For example, during operation, the mailbox microservice can authenticate itself and then provide emails to the email exchange service, which in turn can deliver the received emails to the user's client device. In another example, the calendar microservice can be configured to provide data on calendar items, reminders, or other appropriate content to the email exchange service after authentication.

[0005] To facilitate interaction among computing services, the computing facility can implement an authentication service configured to enable microservices to authenticate with the platform service and / or with each other. For example, the authentication service can be configured to receive authentication requests from microservices. In response, the authentication service can be configured to verify the requesting microservice's certificate according to an authentication scheme. After certificate verification, the authentication service can be configured to generate a security token based on the microservice's authentication profile and transmit it to the microservice. The authentication profile can contain information such as token acquisition configuration, identity, and / or other suitable information. The microservice can then use the received security token to authenticate itself with the platform service (or other suitable computing service) in order to provide content to the platform service or perform other suitable actions against the platform service.

[0006] In a specific computing facility, during the acquisition of a security token, a microservice can present a digital certificate as a certificate to an authentication service. The digital certificate can be signed with the private key issued to the microservice by the authentication authority. The authentication service can then authenticate the received digital certificate using the microservice's public key, verify the microservice's identity based on the digital certificate, and issue a security token upon successful verification.

[0007] As the number of microservices increases, so does the amount of certificate data, such as private and public keys, digital signatures, and fingerprints. Managing this amount of certificate data becomes a significant overhead, as each microservice may require different cryptographic keys for different operating environments. For example, correctly updating expired cryptographic keys can be time-consuming and error-prone. Furthermore, when microservices are delivered by running applications within isolated guest operating systems (“guest OS”) (such as containers), the microservices may not have access to any certificate data residing on the host machine residing on the guest OS. This means the microservice may be unable to generate or provide valid digital certificates to authentication services for obtaining security tokens. Deploying microservices in an isolated guest OS also prevents them from utilizing client-server authentication, such as Windows authentication, because the isolation of the guest OS prevents the microservice's identity from being visible outside the guest OS.

[0008] Several embodiments of the disclosed technology can overcome the aforementioned drawbacks by implementing a keyless authentication scheme that does not utilize cryptographic keys or digital certificates. In a particular implementation, a bearer token authentication scheme can be implemented for microservices deployed within an isolated operating system (such as a container). For example, a container manager (or other suitable type of entity) on a server can be configured to receive commands from a user or another computing service to instantiate the microservice by executing the corresponding application within a container managed by the container manager. In response, the container manager can transmit a request for a bearer token to an authentication service, hereinafter referred to as an identity assertion token or "identity token" associated with the microservice.

[0009] Upon receiving a request from the container manager, the authentication service can be configured to determine the identities of the container manager and the application corresponding to the microservice based on the received request. The authentication service then queries a database of authorization policy records to determine whether to allow the container manager to receive identity assertion tokens for the microservice and whether to allow the issuance of identity assertion tokens for the application to run in a container managed by the container manager. In response to determining that the issuance of identity assertion tokens is permitted, the authentication service generates data representing the identity assertion token issued to the microservice (and the running application) and transmits it to the container manager. The identity assertion token can include data identifying the container manager, the application, the microservice, and the identity of the application and / or the microservice, or other suitable information. In one embodiment, the identity assertion token can be configured as a JSON network token. In other embodiments, the identity assertion token can be a binary-encoded token, an Extensible Markup Language (“XML”)-encoded token, or a token otherwise appropriately encoded.

[0010] Upon receiving an identity assertion token from an authentication service, the container manager can be configured to cause the application to run within the container to instantiate the microservice. The container manager can also make the received identity assertion token accessible to the container and the application running within it. For example, the container manager can store the received identity assertion token within the container or at another suitable location accessible to the container and the running application. The container manager can also be configured to associate the identity of the running application (e.g., an application identifier) ​​with the stored identity assertion token and create entries in a configuration file (e.g., a registry file) that allow the running application to access the stored identity assertion token.

[0011] During operation, a microservice's security client can be configured to determine whether the application is running in an isolated OS (e.g., a container) or on a host machine by querying a configuration file. If the application is determined to be running inside a container, the security client can initialize a keyless caller configured to access an authentication service via a computer network. For example, the keyless caller can be configured to submit a request for a security token to the authentication service, along with a stored identity assertion token. Upon receiving the request, the authentication service can be configured to verify the received identity assertion token to authenticate the microservice's identity in response to the received request. Based on the verified identity, the authentication service can then determine whether a security token can be issued to the application with the verified identity by querying a database of authorization policy records. After determining that a security token can be issued, the authentication service can be configured to generate a security token and issue it to the application, which can then use the security token to authenticate the microservice to a platform service or other suitable computing service. In this way, the microservice can perform hot authentication with other computing services without using digital certificates or managing certificate data.

[0012] In other implementations, client-server authentication can be implemented for microservices deployed on a host that also provides authentication services. For example, a server (or virtual machine) can be configured to execute appropriate instructions to provide authentication and application services. Upon receiving a command to instantiate a microservice, the application service can be configured to execute the corresponding application to provide the microservice. The application service can also assign user accounts from the host to the instantiated microservice. In a particular embodiment, the user account can be an account with the lowest privilege level on the host. The user account is visible within the host but not from outside the host. The user account expires when the microservice terminates on the host or at another suitable point in time. In other embodiments, the user account can have a higher privilege level and / or other suitable characteristics.

[0013] During operation, a microservice can be configured to determine whether the corresponding application is running on the same host as the authentication service. In response to the determination that the application is running on the same host, the microservice can be configured to initialize a keyless caller, which is configured to perform client-server authentication (e.g., Windows authentication) using the assigned user account through the authentication service. Upon successful authentication, the authentication service can be configured to issue a security token to the microservice for interaction with other suitable computing services. This allows the microservice to authenticate with other computing services without using digital certificates or managing certificate data. In other implementations, when client-server authentication is unavailable or fails, the microservice can be configured to initiate certificate-based authentication using the authentication service as an alternative.

[0014] Several embodiments of the disclosed technology can improve the performance of cloud computing systems by eliminating or at least reducing the management of digital certificates and associated certificate data. By implementing identity assertion tokens for microservices, the authentication service can issue security tokens to microservices by verifying their identity based on the identity assertion tokens instead of digital certificates. Alternatively, by hosting the microservices and authentication service on the same host, client-server authentication can be used to authenticate the microservices, such as Windows authentication using user accounts of the microservices on the host. This avoids digital certificate verification and other related operations. Therefore, computing, networking, storage, or other types of computing resources in the computing facility can be saved, while improving the performance of the computing facility. Attached Figure Description

[0015] Figure 1 This is a schematic diagram illustrating a keyless authentication distributed computing system that implements computing services according to an embodiment of the disclosed technology.

[0016] Figure 2 The illustration shows an embodiment based on the disclosed technology. Figure 1 A schematic diagram of specific hardware and software components of a distributed computing system.

[0017] Figure 3A and Figure 3B The illustration shows an embodiment according to the present technology. Figure 1 A schematic block diagram of an exemplary organization providing computing services in a distributed computing system.

[0018] Figures 4A-4C This is a schematic block diagram illustrating keyless authentication using bearer token authentication in a distributed computing system according to an embodiment of the present technology.

[0019] Figure 5 This is a schematic block diagram illustrating keyless authentication using client-server authentication in a distributed computing system according to an embodiment of the present technology.

[0020] Figure 6A and Figure 6B This is a flowchart illustrating various aspects of a keyless authentication process for implementing computing services according to an embodiment of the present technology.

[0021] Figure 7 It is suitable for use Figure 1 Computing devices that are specific components of a distributed computing system. Detailed Implementation

[0022] The following describes specific embodiments of systems, devices, components, modules, routines, data structures, and processes for implementing keyless authentication of computing services in distributed computing systems. Specific details of the components are included in the following description to provide a thorough understanding of specific embodiments of the disclosed technology. Those skilled in the art will also understand that the technology can have additional embodiments. References may also be made without further elaboration. Figure 1-7 The technique is practiced in the context of several details of the described embodiments.

[0023] In one example, a "distributed computing system" can be a computing facility having a computer network that interconnects multiple host machines or hosts with each other or with an external network (e.g., the Internet). Examples of such a computing facility could include data centers for providing cloud computing services. The computing network can include multiple network devices. "Network devices" can be physical network devices, examples of which include routers, switches, hubs, bridges, load balancers, security gateways, or firewalls. A "host" or "host device" can include a computing device configured to implement, for example, one or more virtual machines, containers, or other suitable virtualization components. For example, a host can include a remote server having a hypervisor configured to support one or more virtual machines, containers, or other suitable types of virtual components. In another case, a host can also include a desktop computer, laptop computer, smartphone, network-enabled home appliance (e.g., a camera), or other suitable computing device configured to implement one or more containers or other suitable types of virtual components.

[0024] In another example, a "hypervisor" can include computer software, firmware, and / or hardware that creates, manages, and runs one or more virtual machines on a host machine. A "virtual machine" or "VM" is a simulation of a physical computing system using computer software. Different virtual machines can be configured to provide suitable computing environments to execute different processes for the same or different users on a single host machine. During operation, the hypervisor on the host machine can present different virtual machines with virtual operating platforms to the hardware resources on the host machine and manage the execution of various processes for the virtual machines.

[0025] In another example, a "container" can include software packages containing software fragments within a complete file system that includes computer code (e.g., executable instructions), a runtime environment, system tools, system libraries, device drivers, or other suitable components sufficient to execute the software fragments. Containers running on a single host or virtual machine can share the same operating system kernel and can use system memory or virtual memory. Containers can offer similar resource isolation and allocation advantages as virtual machines. However, different architectural approaches allow containers to be more portable and efficient than virtual machines. For example, a virtual machine typically includes one or more applications, the necessary binaries and libraries for the applications, and the entire operating system. In contrast, a container can include an application and all its dependencies, but share the operating system kernel with other containers on the same host. Thus, containers can be more resource-efficient and flexible than virtual machines. An example container is the Windows Server container from the Microsoft Corporation of Redmond, Washington. Another example container is a Linux container or LXC. Docker is a popular mechanism for packaging and delivering containers, provided by Docker, Inc., San Francisco, California.

[0026] In yet another example, "computing service" or "cloud service" can include one or more computing resources provided via a computer network such as the Internet. Exemplary cloud services include Software as a Service ("SaaS"), Platform as a Service ("PaaS"), and Infrastructure as a Service ("IaaS"). SaaS is a software distribution technology in which a software application is hosted by a cloud service provider in, for example, a data center and accessed by users via a computer network. PaaS typically includes the delivery of an operating system and associated services via a computer network without the need for downloading or installation. IaaS typically includes outsourced equipment to support storage, hardware, servers, network devices, or other components, all of which are accessible via a computer network.

[0027] In another example, an "authentication scheme" can include a different set of requirements for certificates, processes, and / or protocols, or other different operational characteristics related to the authentication process. For example, bearer authentication is an authentication scheme that utilizes data packets called bearer tokens. A bearer token is a secret string typically generated by a server in response to a token request. A bearer token allows an entity presenting the bearer token (e.g., a user, device, or computing service) to access specific computing resources or perform computing operations. In another example, client-server authentication (such as Windows authentication) is an authentication scheme that hashes the entered username and password before sending them across the network. In yet another example, certificate authentication uses digital certificates issued by a trusted certification authority to identify users, machines, devices, or computing services before authorizing access to resources, networks, applications, etc. Other examples can include challenge handshake authentication, scalable authentication, and other suitable authentication schemes.

[0028] In yet another example, the "authentication service" could be a computing service, such as another computing service, configured to facilitate the authentication process upon receiving an authentication request from a requester. An exemplary authentication service is the Security Token Service ("STS"), a cross-platform open standard component of the Single Sign-On Infrastructure Framework. Within this claims-based identity framework, the STS is responsible for issuing, validating, updating, and revoking security tokens. Security tokens issued by the STS can then be used to identify the holder of the security token (e.g., the computing service) to other computing services for accessing resources and / or performing appropriate actions.

[0029] A "security token" or "access token" can be a digital data packet containing a security certificate used for login sessions and to identify entities, entity groups, entity privileges(s), and, in some cases, application-specific credentials. An exemplary security token can include a random string consisting of various fields and their values, such as an identifier, a login session identifier, a user identifier, a default owner, and / or other suitable fields. As described below, an authentication service can issue a security token to a computing service. The computing service can then authenticate to other computing services by presenting the security token.

[0030] In another example, an "identity assertion token" or "identity token" can be a digital data packet containing a secure certificate for an identity under which an application executes to provide computing services. In one example, an identity assertion token can be issued by an authentication service to an application running in a container, virtual machine, or other suitable type of guest operating system. The identity assertion token can include data such as the application's application identifier and the identity name associated with the identity under which the application executes. In other examples, the identity assertion token can be issued by other suitable entities or computing services and include additional and / or different information.

[0031] In a specific computing facility, authenticating one computing service to another may involve obtaining a security token from an authentication service. However, before issuing the security token, the authentication service may require the requesting computing service to authenticate itself according to an authentication scheme. For example, during the acquisition of the security token, a microservice may present a digital certificate as credentials to the authentication service. The digital certificate can be signed with the private key issued to the microservice by the authentication authority. The authentication service can then authenticate the received digital certificate using the microservice's public key, verify the microservice's identity based on the digital certificate, and issue the security token upon successful verification.

[0032] As the number of microservices increases, so does the amount of certificate data, such as private and public keys, digital signatures, and fingerprints. Managing this amount of certificate data becomes a significant overhead, as each microservice may require different cryptographic keys for different operating environments. For example, correctly updating expired cryptographic keys is time-consuming and error-prone. Furthermore, when microservices are delivered by running applications within an isolated guest operating system (“guest OS”) (such as a container), the microservices may not have access to any certificate data residing on the host machine residing on the guest OS. This means the microservice may be unable to generate or provide a valid digital certificate to an authentication service to obtain a security token. Deploying microservices in an isolated guest OS also prevents them from utilizing client-server authentication, such as Windows authentication, because the isolation of the guest OS prevents the microservice’s identity from being visible outside the guest OS.

[0033] Several embodiments of the disclosed technology can overcome the aforementioned drawbacks by implementing a keyless authentication scheme that does not use cryptographic keys or digital certificates. In certain implementations, a bearer token authentication scheme can be implemented for microservices deployed within an isolated operating system (such as a container). In other implementations, client-server authentication can be implemented for microservices deployed on a host that also provides authentication services. By implementing identity assertion tokens for microservices, the authentication service can issue security tokens to microservices by verifying their identity based on the identity assertion tokens rather than digital certificates. Alternatively, by co-locating the microservices and authentication services on the same host, client-server authentication can be used to authenticate the microservices, such as Windows authentication using a user account of the microservice on the host. This avoids digital certificate verification and other related operations. Therefore, computing, networking, storage, or other types of computing resources in the computing facility can be saved, while improving the performance of the computing facility, as described below. Figure 1-7 A more detailed description.

[0034] Figure 1This is a schematic diagram illustrating a distributed computing system 100 with a keyless authentication host implementing computing services, according to an embodiment of the disclosed technology. (As shown in...) Figure 1 As shown, the distributed computing system 100 can include a computer network (shown as "underlying network 108") interconnected with multiple host machines of server 106, multiple client devices 102 of user 101, and resource manager 110. Resource manager 110 can be a cluster controller, infrastructure controller, database controller, and / or other suitable type of controller configured to monitor and manage the resources and operations of server 106 and / or other components in the distributed computing system 100. Even in Figure 1 The image shows specific components of the computing system 100, but in other embodiments, the computing system 100 may also include network storage devices, a maintenance manager, and / or other components besides or replacing them. Figure 1 Other suitable components (not shown) of the components shown.

[0035] As in Figure 1 As shown, the underlying network 108 can include multiple network devices 112 interconnecting multiple servers 106 with client devices 102. In a particular embodiment, the servers 106 can be organized into racks, action zones, groups, sets, or other suitable partitions. For example, in the illustrated embodiment, the servers 106 are divided into three clusters, designated as first, second, and third clusters 107a-107c, respectively. In the illustrated embodiment, each cluster in clusters 107a-107c is operatively coupled to a corresponding network device 112a-112c, which is typically referred to as a "top-rack" or "TOR" network device. The TOR network devices 112a-112c can then be operatively coupled to additional network devices 112 to form a hierarchical, planar, mesh, or other suitable type of network topology. The computer network allows communication between the servers 106 and client devices 102. In other embodiments, multiple host machine sets 107a-107c can share a single network device 112 or can have other suitable arrangements.

[0036] Server 106 can be individually configured to provide computing, storage, and / or other suitable cloud computing services to individual users 101. For example, see the following reference. Figure 2 In more detail, each server in server 106 is capable of initiating and maintaining one or more virtual machines 144 (as in...) upon request from user 101. Figure 2(As shown in the diagram). User 101 can then utilize the instantiated virtual machine 144 to perform appropriate processes for computing, communication, and / or other suitable tasks. In a particular embodiment, one of the servers 106 can provide the virtual machine 144 to multiple users 101. In other embodiments, multiple servers 106 can host the virtual machine 144 for one or more users 101a-101c.

[0037] Client devices 102 may each include a computing device that facilitates access by the corresponding user 101 to various computing services provided by server 106 via the underlying network 108. For example, in the illustrated embodiment, client device 102 individually includes a desktop computer. In other embodiments, client device 102 may also include a laptop computer, tablet computer, smartphone, or other suitable computing device. Although for illustrative purposes... Figure 1 The illustration shows three users 101, but in other embodiments, the distributed computing system 100 can facilitate access to cloud and / or other suitable types of computing services provided by the server 106 and / or other components in the distributed computing system 100, by any suitable number of users 101 or administrators.

[0038] Figure 2 The illustration shows an embodiment of the disclosed technology capable of... Figure 1 A schematic diagram of the overlay network 108' implemented on the underlying network 108. Figure 2 For clarity, only [the text] is shown. Figure 1 Specific components of the underlying network 108. For example, in Figure 2 As shown, the first server 106a and the second server 106b may each include a processor 132, a memory 134, and a network interface 136 operably coupled to each other. The processor 132 may include one or more central processing units, microprocessors, field-programmable gate arrays, and / or other suitable logic devices. The memory 134 may include volatile and / or non-volatile media (e.g., ROM; RAM, disk storage media; optical storage media; flash memory devices, and / or other suitable storage media) and / or other types of computer-readable storage media configured to store data received from the processor 132 and instructions for the processor 132 (e.g., instructions for performing operations referenced below). Figure 6A and Figure 6B (Instructions for the methods discussed). Network interface 136 may include network interface cards, connection converters, and / or other suitable types of input / output devices, which are configured to accept input from other components on the overlay network 108' and provide output to them.

[0039] First server 106a and second server 106b can individually contain in memory 134 instructions executable by processor 132 to enable individual servers 106a and 106b to provide hypervisors 140 (individually identified as first and second hypervisors 140a and 140b). Hypervisors 140 can be individually configured to create, monitor, terminate, and / or otherwise manage one or more virtual machines 144 organized into tenant site 142. For example, as in... Figure 2 As shown, the first server 106a is capable of providing a first management program 140a to manage the first and second tenant sites 142a and 142b respectively. The second server 106b is capable of providing a second management program 140b to manage the first and second tenant sites 142a' and 142b' respectively. Although the management program 140b is... Figure 2 While individually represented as software components, in other embodiments, the hypervisor 140 may also include firmware and / or hardware components.

[0040] Tenant sites 142 can each include multiple virtual machines 144 for a specific tenant. For example, both first server 106a and second server 106b can host tenant sites 142a and 142a' for first user 101a. Both first server 106a and second server 106b can host tenant sites 142b and 142b' for second user 101b. Each virtual machine 144 can be executing an application 147 or process corresponding to an operating system, middleware, and / or a suitable application. The executed application 147 can each correspond to one or more computing services. Examples of such computing services can include platform services, microservices, authentication services, as referenced below. Figure 3A and Figure 3B More detailed discussion. The first and second servers 106a and 106b, or the virtual machines 144 hosted on them, are also capable of supporting container management by container manager 160 (in... Figure 4A (As shown) manages and individually executes one or more containers 162 of one or more applications 147, as referenced below. Figure 4A and 4B More detailed description.

[0041] Also in Figure 2As shown, the computing system 100 can include an overlay network 108' having one or more virtual networks 146 interconnecting tenant sites 142a and 142b across first and second servers 106a and 106b. For example, a first virtual network 146a interconnects first tenant sites 142a and 142a' at the first server 106a and the second server 106b. A second virtual network 146b interconnects second tenant sites 142b and 142b' at the first server 106a and the second server 106b. Even though a single virtual network 146 is shown to correspond to a single tenant site 142, in other embodiments, multiple virtual networks (not shown) may be configured to correspond to a single tenant site 146.

[0042] Virtual machine 144 on virtual network 146 can be accessed via underlying network 108 ( Figure 1 They can communicate with each other even if virtual machines 144 are located on or hosted on different servers 106. Communication within each virtual network 146 can be isolated from other virtual networks 146. In certain embodiments, communication can be allowed to cross from one virtual network 146 to another in a controlled manner via a security gateway or otherwise. A virtual network address can correspond to one of the virtual machines 144 in a particular virtual network 146. Therefore, different virtual networks 146 can use the same one or more virtual network addresses. Exemplary virtual network addresses can include IP addresses, MAC addresses, and / or other suitable addresses.

[0043] In operation, server 106 can facilitate communication between virtual machine 144 and / or application 147 executing within virtual machine 144. For example, processor 132 of first server 106a can perform appropriate network communication operations to facilitate communication between first virtual machine 144a and network interface 136 on first server 106a, underlying network 108 (…). Figure 1 The network interface 136 on the first server 106b and the second server 106b send packets to the second virtual machine 144b via the virtual network 146a. In this way, the first virtual machine 144a of the tenant site 142a on the first server 106a can cooperate with another virtual machine 144b on the other server 106b to execute appropriate applications or processes 147 in order to provide appropriate computing services to the user 101.

[0044] Figure 3A and Figure 3B This is a schematic block diagram of a distributed computing system 100 according to an embodiment of the present technology, the distributed computing system 100 having an authentication service 156 configured for keyless authentication. Figure 3A and Figure 3BAs well as in other figures herein, individual software components, objects, classes, modules, and routines can be computer programs, procedures, or processes written in C, C++, C#, Java, and / or other suitable programming languages. Components can include, but are not limited to, one or more modules, objects, classes, routines, properties, processes, threads, executables, libraries, or other components. Components can be in source code or binary form. Components can also include aspects of pre-compiled source code (e.g., classes, properties, procedures, routines), compiled binary units (e.g., libraries, executables), or artifacts instantiated and used at runtime (e.g., objects, processes, threads).

[0045] Components within a system can take different forms. As an example, a system may include a first component, a second component, and a third component. These components can include, but are not limited to: the first component being an attribute in the source code, the second component being a binary compiled library, and the third component being a system of threads created at runtime. Computer programs, procedures, or processes can be compiled into objects, intermediate code, or machine code and presented for execution by one or more processors of a personal computer, tablet computer, web server, laptop computer, smartphone, and / or other suitable computing device.

[0046] Similarly, components may include hardware circuitry. In certain examples, hardware can be considered rigid software, while software can be considered fluidized hardware. As an example only, software instructions in a component may be programmed into a programmable logic array circuit or designed as a hardware component with appropriate integrated circuits. Likewise, hardware can be emulated by software. Various implementations of source code, intermediate code, and / or object code and associated data may be stored in computer memory, including read-only memory, random access memory, disk storage media, optical storage media, flash memory devices, and / or other suitable computer-readable storage media. As used herein, the term "computer-readable storage media" does not include propagated signals.

[0047] As in Figure 3A As shown, the distributed computing system 100 can be configured to provide computing services organized as a collection of platform services 152 and microservices 154 configured to support platform services 152 within a service platform 150. For example, platform service 152' could be an email exchange service configured to handle email receiving, forwarding, synchronization, and other suitable operations. An exemplary email exchange service is provided by Microsoft Corporation of Redmond, Washington. Service. After authenticating the email exchange service, it allows user 101 ( Figure 1This allows access to content such as emails and email attachments in the corresponding mailbox. To provide such content, the email exchange service can rely on one or more microservices (154) for support. For example, the email exchange service can rely on the mailbox microservice (in...) Figure 3A The example microservice 154 is shown in the image below and can be used for email or other suitable types of content.

[0048] To facilitate operation between the paired platform service 152 and microservice 154, the distributed computing system 100 can also provide an authentication service 156 operably coupled to a network storage device 118 containing an authentication policy 111. The configuration file 111 can individually contain information such as token acquisition configuration and / or other suitable information. During operation, the authentication service 156 can be configured to receive authentication requests 155 for security tokens 157 from the microservice 154 (as in...). Figure 3B (As shown in the image). In response, as in... Figure 3B As shown, authentication service 156 can be configured to initiate an authentication process with microservice 152 to verify the security certificate of microservice 154 according to the selected authentication scheme. After certificate verification, authentication service 156 can be configured to generate a security token 158 (or other suitable security item) and transmit it to microservice 154. Microservice 154 can then use the received security token 158 to authenticate itself with platform service 152 (or other suitable computing service) to provide content 158 ​​to platform service 152 or perform other suitable actions on platform service 152. Subsequently, platform service 152 can forward the received content to user 101's client device 102 (…). Figure 1 During the acquisition of security token 156, distributed computing system 100 can achieve keyless authentication from microservice 154 to authentication service 156, as described in the following reference. Figure 4A-5 More detailed description.

[0049] Figure 4A-5 This is a schematic block diagram illustrating keyless authentication of computing services in a distributed computing system 100 according to an embodiment of the present technology. (See also...) Figure 4A As shown, server 106 can utilize processor 132 ( Figure 2 The container manager 160 executes appropriate instructions to support and manage one or more containers 162. For illustrative purposes, in Figure 4AOnly one container 162 is shown. Container 162 can be configured to run application 147, which provides microservices 154. Although container manager 160 and container 162 are shown as being hosted on server 106, in other implementations, container manager 160 and container 162 can also be hosted on virtual machine 144 on server 106. Figure 2 In a further implementation, container manager 160 and / or container 162 can be hosted in other suitable computing environments.

[0050] As in Figure 4A As shown, container manager 160 can be configured to receive initialization command 170 from user 101 ( Figure 1 Or in Figure 3A and Figure 3B One of the computing services shown instantiates microservice 154. In response, container manager 160 can be configured to transmit an identity assertion token corresponding to application 147 to authentication service 156 (in... Figure 4A A token request 172 (shown as "identity token 159") is received, wherein application 147 executes the instantiation of microservice 154 within container 162. Upon receiving token request 172, authentication service 156 can be configured to determine the identity of application 147 and optionally the identity of container manager 160, and access network storage device to retrieve a record of authorization policy 111 corresponding to the determined identities of application 147 and optionally container manager 160. In one embodiment, authorization policy 111 can include data indicating whether application 147 with the determined identity is authorized by identity assertion token 159. The following is an exemplary authorization policy 111:

[0051]

[0052] As shown above, authorization policy 111 identifies a "name" with the value "container1.Identity1", such as the execution environment indicated by a "Ring" with the value "Dev" and the name "EXAMPLEV1". The identity assertion permission indicates that the container manager 160 with the identifier "ContainerManagerAppId" is allowed to receive an identity assertion token 159 for the application 147 with the identity value "Container1.Identity1". In other examples, authorization policy 111 may also include additional and / or different data fields.

[0053] After retrieving authorization policy 111, authentication service 156 can then be configured to determine, based on the access records of authorization policy 111, whether an application 147 with a defined identity is authorized to use the requested identity assertion token 159. For example, in the example above, when container manager 160 has the identifier "ContainerManagerAppId" and requests identity assertion token 159 for application 147 with the identity value "Container1.Identity1", authentication service 156 can indicate that identity assertion token 159 is permitted. Otherwise, authentication service 156 can deny the token request 172, for example, by issuing an error message to container manager 160. In response to determining that application 147 with a defined identity is authorized to use the requested identity assertion token 159, authentication service 156 can be configured to generate the requested identity assertion token 159 and transmit it to container manager 160 at server 106.

[0054] Identity assertion token 159 can be formatted according to many data patterns. Below is an example of an identity assertion token 159 formatted as a JSON network token:

[0055]

[0056] As shown above, the exemplary identity assertion token 159 can include an identifier type header, i.e., a "typ" indicating the value of a JSON network token ("JWT"), and a cryptographic algorithm, i.e., an "alg" with the example value "RS256". The exemplary identity assertion token 159 can also include a payload with additional data fields. For example, the payload can include an application identifier, i.e., an "appid" with the example value "4be2d893-6158-4904-9e3f-f0cadf88f526", and an identity name, i.e., an "actor" with the example value "user1", under which application 147 will be executed. The payload can also include an IP address, i.e., the "ip" of application 147, with the example value "10.10.134.208". In other examples, the header and payload of the identity assertion token 159 can also include a publication time, expiration time, key identifier, fingerprint, or other suitable data.

[0057] As in Figure 4BAs shown, container manager 160 can execute application 147 within container 162. Upon receiving identity assertion token 159, container manager 160 can also be configured to make the received identity assertion token 159 accessible to container 162 and the application 147 executing within container 162. For example, container manager 160 can store identity assertion token 159 along with the executing application 147 in container 162. Container manager 160 can also be configured to modify entries in a configuration file (not shown) within container 162. The modified entries allow instantiated microservice 154 to access the identity assertion token 159 stored in container 162. In a particular embodiment, the configuration file can include the registry of container 162. In other embodiments, the configuration file can include other suitable types of files defining access control lists for identity assertion token 159.

[0058] Using the stored identity assertion token 159, microservice 154 can authenticate itself to authentication service 156 without using a digital certificate. For example, as in Figure 4C As shown, microservice 154 can be configured to first determine whether application 147 is running in a guest operating system, such as container 162. In response to determining that application 147 is running in container 162, the microservice can access the identity assertion token 159 stored in container 162 according to an entry in the configuration file. Microservice 154 can then be configured to transmit an authentication request 155 to authentication service 156. The authentication request 155 includes the identity assertion token 159.

[0059] Upon receiving an authentication request 155 containing an identity assertion token 159, the authentication service 156 can be configured to determine the identity of the application 147 executing in container 162 on server 106 based on the identity assertion token 159 contained in the received authentication request 155. For example, in the example above, application 147 could have an application identifier “appid” with a value of “4be2d893-6158-4904-9e3f-f0cadf88f526” and an identity name “actor” with a value of “userl”.

[0060] Based on the application identifier and / or identity name, authentication service 156 can be configured to retrieve another authorization policy 111 corresponding to a determined identity of application 147, and determine whether the identity is authorized to issue a security token 158 based on the authorization policy 111. (As in...) Figure 4CAs shown, in response to determining that the identity of application 147 has been authorized by security token 158, authentication service 156 can be configured to generate the requested security token 158 and transmit the requested security token 158 to microservice 154. Microservice 154 can then use the security token 158 to authenticate with other computing services in the distributed computing system 100, such as in... Figure 3A and Figure 3B As shown, without using digital certificates.

[0061] Although bearer token authentication is Figures 4A-4C The example authentication scheme is shown here, but in other embodiments, the distributed computing system 100 may also implement other authentication schemes without using digital certificates. For example, as in Figure 5 As shown, server 106 can host the runtime of microservice 154 and authentication service 156 by utilizing processor 132 to execute application 147. Although microservice 154 and authentication service 156 are shown as being hosted on... Figure 5 In some implementations, the computing service is hosted on a single server 106, but in others, it can also be hosted on a single virtual machine 144. Figure 2 On a host machine of any other suitable type.

[0062] During the instantiation of microservice 154, application 147 can execute using a user account on server 106. User account 106 is visible only on a single host and has the permission level for network access in the distributed computing system 100. During operation, microservice 154 can be configured to determine whether microservice 154 and authentication service 156 reside on a single host, such as server 106. In response to determining that microservice 154 and authentication service 156 reside on a single host, microservice 154 can be configured to initialize a keyless caller (not shown), which is configured to perform client-server authentication (e.g., Windows authentication) against authentication service 156 using an assigned user account during the initialization of microservice 154. For example, the keyless caller can provide authentication service 156 with the username and password of the user account. Authentication service 156 can then authenticate microservice 154 using the provided username and password to identify application 147 and / or microservice 154.

[0063] After successful authentication of the provided username and password, authentication service 156 can be configured to determine, based on the records of authorization policy 111, whether to allow the issuance of security token 158 to microservice 154. In response to determining that the issuance of security token 158 to microservice 154 is permitted, authentication service 156 can be configured to issue security token 158 to microservice 154 for interaction with other suitable computing services, such as... Figure 3Aand Figure 3B Those shown in the image. In this way, microservice 154 can authenticate with other computing services without using digital certificates or managing certificate data.

[0064] Figure 6A and Figure 6B This is a flowchart illustrating various aspects of a keyless authentication process for implementing computing services in a distributed computing system, according to embodiments of the present technology. Although the following... Figure 1-5 The various aspects of the process are described in the context of the distributed computing system 100, but in other embodiments, the various aspects of the process can also be implemented in computing systems with additional and / or different components.

[0065] As in Figure 6A As shown, process 200 may include receiving an initialization request for initializing a computing service at stage 202. In response to receiving the initialization request, process 200 may include requesting an identity assertion token from an authentication service at stage 204. After receiving the identity assertion token, process 200 may include initializing the computing service using the identity assertion token at stage 206. For example, initializing the computing service may include storing the identity assertion token in a container or other suitable type of guest operating system that also hosts the application and modifies entries in the configuration files of the guest operating system, as referenced above. Figure 4A and Figure 4B As described.

[0066] As in Figure 6B As shown, the process 210 for authenticating a computing service to an authentication service may include a decision phase 211 to determine whether to provide the computing service by executing an application in the client operating system. In response to determining that the computing service is provided by executing an application in the client operating system, process 210 may include requesting a security token from the authentication service using an identity assertion token stored in the client operating system, as referenced above. Figure 4C In more detail, process 210 enables the continued use of security tokens to authenticate computing services with other computing services in the distributed computing system.

[0067] In response to determining that the computing service is not provided by executing an application in the client operating system, process 210 may include another decision phase 214 to determine whether the computing service is runtime-co-located with the authentication service. In response to determining that the computing service and the authentication service are runtime-co-located, process 210 may continue to authenticate the computing service with the authentication service using client-server authentication at phase 216 before continuing to authenticate the computing service with other computing services using a security token, as referenced above. Figure 5 As described. Otherwise, process 210 can continue to utilize the default authentication scheme in stage 218.

[0068] Figure 7 It is applicable Figure 1 The computing device 300 is a specific component of the distributed computing system 100, such as server 106, client device 102, or resource manager 110. In a very basic configuration 302, the computing device 300 may include one or more processors 304 and system memory 306. Memory bus 308 may be used for communication between processor 304 and system memory 306. Depending on the desired configuration, processor 304 may be of any type, including but not limited to microprocessor (μR), microcontroller (μC), digital signal processor (DSP), or any combination thereof. Processor 304 may include level 1 or more caches (e.g., level 1 cache 310 and level 2 cache 312), processor core 314, and registers 316. Exemplary processor core 314 may include an arithmetic logic unit (ALU), floating-point unit (FPU), digital signal processing core (DSP core), or any combination thereof. Exemplary memory controller 318 may also be used with processor 304, or in some implementations, memory controller 318 may be an internal part of processor 304.

[0069] Depending on the desired configuration, system memory 306 can be of any type, including but not limited to volatile memory (e.g., RAM), non-volatile memory (e.g., ROM, flash memory, etc.), or any combination thereof. System memory 306 may include operating system 320, one or more applications 322, and program data 324. Figure 7 As shown, the operating system 320 may include a hypervisor 140 for managing one or more virtual machines 144. The basic configuration 302 described herein is shown in Figure 6 by the components within the inner dashed lines.

[0070] Computing device 300 may have additional features or functions and additional interfaces to facilitate communication between basic configuration 302 and any other devices and interfaces. For example, bus / interface controller 330 may be used to facilitate communication between basic configuration 302 and one or more data storage devices 332 via storage interface bus 334. Data storage device 332 may be removable storage device 336, non-removable storage device 338, or a combination thereof. Examples of removable and non-removable storage devices include disk devices such as floppy disk drives and hard disk drives (HDDs), optical disk drives such as compact disc (CD) drives or digital versatile disk (DVD) drives, solid-state drives (SSDs), and magnetic tape drives, etc. Exemplary computer storage media may include 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. The terms "computer-readable storage medium" or "computer-readable storage device" do not include signal propagation and communication media.

[0071] System memory 306, removable storage device 336, and non-removable storage device 338 are examples of computer-readable storage media. Computer-readable storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital versatile disk (DVD) or other optical storage devices, magnetic 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 by computing device 300. Any such computer-readable storage medium may be part of computing device 300. The term "computer-readable storage medium" does not include signal propagation and communication media.

[0072] The computing device 300 may also include an interface bus 340 for facilitating communication from various interface devices (e.g., output devices 342, peripheral interfaces 344, and communication devices 346) to the basic configuration 302 via a bus / interface controller 330. An exemplary output device 342 includes a graphics processing unit 348 and an audio processing unit 350, which may be configured to communicate with various external devices (e.g., displays or speakers) via one or more A / V ports 352. An exemplary peripheral interface 344 includes a serial interface controller 354 or a parallel interface controller 356, which may be configured to communicate with external devices such as input devices (e.g., keyboards, mice, pens, voice input devices, touch input devices, etc.) or other peripheral devices (e.g., printers, scanners, etc.) via one or more I / O ports 358. An exemplary communication device 346 includes a network controller 360, which may be arranged to facilitate communication with one or more other computing devices 362 over a network communication link via one or more communication ports 364.

[0073] A network communication link can be an example of a communication medium. A communication medium can typically be embodied in computer-readable instructions, data structures, program modules, or other data (such as a carrier wave or other transmission mechanism) in a modulated data signal, and can include any information delivery medium. A “modulated data signal” can be 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, a communication medium can include wired media (such as wired networks or direct wired connections) and wireless media (such as acoustic, radio frequency (RF), microwave, infrared (IR), and other wireless media). The term “computer-readable medium” can include both storage media and communication media.

[0074] The computing device 300 can be implemented as part of a small-form-factor portable (or mobile) electronic device, such as a mobile phone, personal data assistant (PDA), personal media player device, wireless network watch device, personal headset device, dedicated device, or a hybrid device including any of the above functions. The computing device 300 can also be implemented as a personal computer, including laptop and non-laptop configurations.

[0075] Based on the foregoing, it should be understood that specific embodiments of this disclosure have been described herein for illustrative purposes, but various modifications may be made without departing from this disclosure. Furthermore, many elements of one embodiment may be combined with other embodiments to supplement or replace elements of other embodiments. Therefore, this technology is not limited except for the appended claims.

Claims

1. A method for a computing service to perform keyless authentication with an authentication service in a distributed computing system, the method comprising: The authentication service receives data from the computing service representing an authentication request for a security token configured to authenticate the computing service to other computing services in the distributed computing system. The authentication request includes an identity assertion token previously issued by the authentication service to an application running in a container on the server. The identity assertion token includes a digital data packet containing a security certificate for the identity of the application running thereunder to provide the computing service. In response to receiving the authentication request, the authentication service determines the identity of the application executing in the container on the server based on the identity assertion token included in the received authentication request. Access the database for records of authorization policies corresponding to the identified identity, and determine whether the identity is authorized to issue a security token based on the accessed authorization policy records; and In response to determining that the identity is authorized by a security token, a requested security token is generated and transmitted to the computing service, thereby allowing the computing service to authenticate with other computing services in the distributed computing system without using a digital certificate, wherein: The received identity assertion token includes the application identifier and the identity name; and Accessing the database includes querying the database using the application identifier against the records of the authorization policy; and Determining whether the identity is authorized includes determining whether the identity is authorized based on the identity name of the identity assertion token.

2. The method according to claim 1, further comprising: At the authentication service, data representing a request for the identity assertion token corresponding to the application is received from the server; as well as In response to receiving the request for the identity assertion token, Determine the identity of the application; Access the database using another record of the authorization policy corresponding to the determined identity of the application; The accessed authorization policy records are used to determine whether the application with the defined identity is authorized by the requested identity assertion token. as well as In response to determining that the application with the determined identity is authorized to request an identity assertion token, the requested identity assertion token is generated and transmitted to the server.

3. The method according to claim 1, further comprising: At the authentication service, data representing a request for the identity assertion token corresponding to the application is received from the container manager at the server; and In response to receiving the request for the identity assertion token, Determine the identity of the application and the identity of the container manager; Access the database using another record of the authorization policy corresponding to the determined identity of the application and the identity of the container manager; Based on the accessed authorization policy records, determine whether the application, which has the defined identity and is managed by the container manager, is authorized by the requested identity assertion token; as well as In response to determining that the application with the determined identity is authorized to request an identity assertion token, the requested identity assertion token is generated and transmitted to the container manager at the server.

4. The method according to claim 1, further comprising: At the authentication service, data representing a request for the identity assertion token corresponding to the application is received from the container manager at the server; as well as In response to receiving the request for the identity assertion token, Determine the identity of the application and the identity of the container manager; Access the database using another record of the authorization policy corresponding to the determined identity of the application and the identity of the container manager; Based on the accessed authorization policy records, determine whether the application, which has the defined identity and is managed by the container manager, is authorized by the requested identity assertion token; as well as In response to determining that the application with the determined identity is authorized to the requested identity assertion token, the requested identity assertion token is generated and transmitted to the container manager at the server, wherein the container manager is configured to store the received identity assertion token together with the executed application in the container.

5. A computing device in a distributed computing system, the distributed computing system having additional computing devices that individually execute instructions to provide a variety of computing services, including authentication services, the computing devices comprising: processor; as well as A memory operatively coupled to the processor, the memory containing instructions executable by the processor to cause the computing device to perform the following operations: The authentication service receives data from the computing service representing an authentication request for a security token configured to authenticate the computing service to other computing services in the distributed computing system. The authentication request includes an identity assertion token previously issued by the authentication service to an application running in a container on the server. The identity assertion token includes a digital data packet containing a security certificate for the identity of the application running thereunder to provide the computing service. In response to receiving the authentication request, the authentication service determines the identity of the application executing in the container on the server based on the identity assertion token included in the received authentication request. Access the database for records of authorization policies corresponding to the identified identity, and determine whether the identity is authorized to issue a security token based on the accessed authorization policy records; and In response to determining that the identity is authorized by a security token, a requested security token is generated and transmitted to the computing service, thereby allowing the computing service to authenticate with other computing services in the distributed computing system without using a digital certificate, wherein: The received identity assertion token includes the application identifier and the identity name; and Accessing the database includes querying the database using the application identifier against the records of the authorization policy; and Determining whether the identity is authorized includes determining whether the identity is authorized based on the identity name of the identity assertion token.

6. The computing device according to claim 5, further comprising: At the authentication service, data representing a request for the identity assertion token corresponding to the application is received from the server; as well as In response to receiving the request for the identity assertion token, Determine the identity of the application; Access the database using another record of the authorization policy corresponding to the determined identity of the application; The accessed authorization policy records are used to determine whether the application with the defined identity is authorized by the requested identity assertion token. as well as In response to determining that the application with the determined identity is authorized to request an identity assertion token, the requested identity assertion token is generated and transmitted to the server.

7. The computing device according to claim 5, further comprising: At the authentication service, data representing a request for the identity assertion token corresponding to the application is received from the container manager at the server; and In response to receiving the request for the identity assertion token, Determine the identity of the application and the identity of the container manager; Access the database using another record of the authorization policy corresponding to the determined identity of the application and the identity of the container manager; Based on the accessed authorization policy records, determine whether the application, which has the defined identity and is managed by the container manager, is authorized by the requested identity assertion token; as well as In response to determining that the application with the determined identity is authorized to request an identity assertion token, the requested identity assertion token is generated and transmitted to the container manager at the server.

8. The computing device according to claim 5, further comprising: At the authentication service, data representing a request for the identity assertion token corresponding to the application is received from the container manager at the server; as well as In response to receiving the request for the identity assertion token, Determine the identity of the application and the identity of the container manager; Access the database using another record of the authorization policy corresponding to the determined identity of the application and the identity of the container manager; Based on the accessed authorization policy records, determine whether the application, which has the defined identity and is managed by the container manager, is authorized by the requested identity assertion token; as well as In response to determining that the application with the determined identity is authorized to the requested identity assertion token, the requested identity assertion token is generated and transmitted to the container manager at the server, wherein the container manager is configured to store the received identity assertion token together with the executed application in the container.

Images