Dynamic authentication scheme selection in computing systems

Abstract

Disclosed herein are techniques for dynamic authentication scheme selection in a distributed computing system. One example technique includes analyzing a received authentication request for an indicator of an authentication scheme supported by a computing service that submitted the authentication request. The example technique can also include determining whether a verification scheme associated with the indicator is also supported by the authentication service, and in response to determining that the authentication scheme associated with the indicator is also supported by the verification service, initiating an authentication process with the computing service according to an authentication scheme supported by both the computing service and the authentication service. In this manner, an authentication scheme can be dynamically selected at the authentication service for a received authentication request.

Description

Background Art

[0001] Remote or "cloud" computing systems typically utilize a large number of remote servers housed in a data center to provide computing, storage, networking, and other computing services. The remote servers can be interconnected via a computer network 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 virtualized components for resource sharing. During operation, the virtual machines or containers can facilitate the operation of user applications, thereby providing corresponding computing services to the user. Summary of the Invention

[0002] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

[0003] In a particular computing facility, remote servers in a cloud computing facility can provide computing services to multiple subscribers or "tenants" via virtualization of computing, storage, network, or other suitable types of physical resources. For example, a server can run appropriate instructions on an operating system to provide a hypervisor for managing multiple virtual machines hosted at the server. Each virtual machine can run appropriate applications to provide corresponding computing services to the tenant's users. Thus, multiple tenants can share physical resources at individual servers in a cloud computing facility as computing services. On the other hand, a single tenant can also consume physical resources from multiple servers, storage devices, or other suitable components of a cloud computing facility as a single computing service.

[0004] In a particular cloud computing infrastructure, various computing services can be organized into platform services and microservices that support the platform services. For example, a platform service can be an email exchange service that is configured to handle email reception, forwarding, synchronization, and other suitable operations. An exemplary email exchange service is included in the Office 365 suite offered by Microsoft Corporation of Redmonton, Washington. After authenticating with the Email Exchange service, a user can access content such as emails and attachments in the corresponding mailbox. To provide such content, the Email Exchange service can rely on one or more microservices for support. For example, during operation, the Mailbox microservice can authenticate itself and then provide the email to the Email Exchange service, which can then forward the received email to the user's client device. In another example, the Calendar microservice can be configured to provide the content of calendar items, reminders, or other suitable information to the Email Exchange service.

[0005] Cloud computing facilities typically implement an authentication service that is configured to facilitate authentication of microservices to platform services and / or each other. For example, the authentication service can be configured to receive an authentication request from a microservice. In response, the authentication service can be configured to verify the credentials of the microservice according to an authentication scheme. After verifying the credentials, the authentication service can be configured to generate a security token (or other suitable security terms) based on the authentication profile of the microservice and transmit it to the microservice. The authentication profile can contain information such as configuration for token acquisition and / or other suitable information. The microservice can then use the received security token to authenticate itself to the platform service (or other suitable computing service) in order to provide content or perform other suitable actions for the platform service.

[0006] In a particular computing system, multiple authentication schemes can be deployed. Each authentication scheme can have different requirements for credentials, authentication procedures and / or protocols, or other different operational characteristics. For example, bearer authentication is an authentication scheme that utilizes a data packet called a bearer token. A bearer token is a hidden string of characters that is typically generated by a server in response to a token request. A bearer token allows the entity that presents the bearer token (e.g., a user, a device, or a computing service) to access specific computing resources or perform computing operations. Other examples of authentication schemes include Windows authentication, certificate authentication, and container authentication.

[0007] Before initiating the authentication process, a microservice that is a client of an authentication service typically performs authentication scheme discovery in order to decide which authentication scheme to use. For example, a microservice can transmit a discovery request to a discovery interface of the authentication service (e.g., identified by an IP address, a universal resource locator or "URL," or other suitable type of network address). In response, the authentication service provides a discovery response that includes a list of one or more authentication schemes supported by the authentication service and a corresponding authentication interface (referred to as an "authentication endpoint") at the corresponding IP address, URL, and / or other suitable network address. Upon receiving the discovery response, the microservice can then select one of the authentication schemes and initiate the authentication process by transmitting an authentication request to the authentication endpoint of the authentication service corresponding to the selected authentication scheme.

[0008] The aforementioned client-side authentication scheme selection by the microservice can have several drawbacks. First, the authentication scheme discovery can introduce delays in delivering content from the microservice to the platform service. Second, as the number of microservices increases, the authentication service can become overloaded and require switching to a new authentication scheme. However, updating each microservice to have an authentication library that complies with the new authentication scheme can be labor-intensive, tedious, and error-prone. Additionally, when the authentication service exposes multiple authentication endpoints, the microservice can become overloaded with authentication logic that keeps track of which authentication endpoint a microservice can call to initiate the authentication process.

[0009] Several embodiments of the disclosed technology can address at least some aspects of the aforementioned shortcomings of client-side authentication scheme selection by implementing service-side authentication scheme selection at the authentication service. In a specific implementation, the authentication service can be configured to deploy a request monitor that detects authentication requests from microservices before processing the authentication requests. An exemplary request monitor can include a Hypertext Transfer Protocol ("HTTP") listener configured as a listening socket with an IP address, port number, server name, default server, or other suitable parameters.

[0010] Upon detecting an incoming authentication request from a microservice, the request monitor can be configured to analyze at least a portion of a header and / or payload of the authentication request to obtain an indicator or "hint" as to which authentication scheme(s) are supported or applicable to the microservice. For example, the authentication request may include an encrypted header containing the value "WinAuthEnabled: true." In response, the authentication service can indicate that Window authentication can be a candidate authentication scheme for processing the received authentication request. In another example, the authentication request can include a JavaScript Object Notation ("JSON") web token. In response, the authentication service can indicate that token authentication can be a candidate authentication scheme for processing the received authentication request. In yet another example, the request monitor can determine that the authentication request does not include a header, but is instead signed using a digital certificate, and the digital signature is included in the payload of the authentication request. In response, the authentication service can indicate that certificate authentication is a candidate authentication scheme for processing the received authentication request.

[0011] In other implementations, the microservice can be configured to access an authentication repository containing configuration information for authentication schemes supported by the microservice. The microservice can then be configured to add a header value to the authentication request, indicating the supported authentication schemes, such as "AuthScheme: Windows." Upon receiving the authentication request, the request monitor can extract the authentication schemes supported by the microservice from the header and determine whether the supported authentication schemes are also supported by the authentication service. In response to determining that the authentication service also supports the authentication scheme, the request monitor can be configured to launch an appropriate authentication handler based on the authentication scheme extracted from the header of the authentication request to facilitate the authentication process. Otherwise, the request monitor can ignore the extracted authentication scheme and, instead, launch a default authentication handler to facilitate the authentication process with the microservice or transmit a list of authentication schemes supported by the authentication service for the microservice to select based on a client-side authentication selection scheme.

[0012] Several embodiments of the disclosed technology can thus facilitate efficient authentication of computing services (such as microservices) to platform services by enabling dynamic authentication scheme selection at the authentication service. Through the request monitor, different authentication schemes can be implemented at the authentication service with a single authentication endpoint. This allows multiple microservices to call the same authentication endpoint even when the microservices support different authentication schemes. Consequently, the authentication logic implemented at the microservice can be reduced compared to client-side authentication scheme selection.

[0013] The aforementioned service-side authentication scheme selection can also allow for the efficient deployment of new authentication schemes in a cloud computing facility. For example, a new authentication scheme can be deployed to the authentication service. The new authentication scheme can be accessed via the same authentication endpoint as (one or more) other existing authentication schemes. In this way, the new authentication scheme can be tested by providing a "hint" corresponding to the new authentication scheme to the authentication request, while the same authentication endpoint continues to facilitate the authentication process according to the existing authentication scheme. After determining that the new authentication scheme is working properly, the authentication process at the authentication service can be switched to using the new authentication scheme by simply modifying the "hint" contained in the authentication request from the microservice. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] Figure 1 is a schematic diagram illustrating a distributed computing system implementing dynamic authentication scheme selection according to an embodiment of the disclosed technology.

[0015] Figure 2 is a diagram illustrating an embodiment according to the disclosed technology Figure 1 A schematic diagram of the specific hardware and software components of a distributed computing system.

[0016] Figure 3A and Figure 3B is a schematic block diagram illustrating an example organization of computing services provided in a distributed computing system during operation according to embodiments of the present technology.

[0017] Figure 4A and Figure 4B is a schematic block diagram illustrating dynamic authentication scheme selection in a distributed computing system according to an embodiment of the present technology.

[0018] Figure 5A and Figure 5B is a flow diagram illustrating aspects of a process for implementing dynamic authentication scheme selection in accordance with an embodiment of the present technology.

[0019] Figure 6 is applicable to Figure 1 A computing device that is a specific component in a distributed computing system. DETAILED DESCRIPTION

[0020] The following describes specific embodiments of systems, devices, components, modules, routines, data structures, and processes for implementing dynamic authentication scheme selection in a distributed computing system. In the following description, specific details of the components are included to provide a thorough understanding of the specific embodiments of the disclosed technology. It will also be understood by those skilled in the relevant art that the technology is capable of additional embodiments. It is also capable of being described without reference to the following. Figure 1-6 The techniques are practiced without reference to several of the details of the described embodiments.

[0021] As used herein, the term "distributed computing system" generally refers to a computing facility having a computer network that interconnects multiple hosts to each other or to an external network (e.g., the Internet). Examples of such computing facilities can include data centers for providing cloud computing services. A computing network can include multiple network devices. The term "network device" generally refers to a physical network device, examples of which include routers, switches, hubs, bridges, load balancers, security gateways, or firewalls. A "host" can be a server or other suitable type of hardware / software computing device that is configured to provide a hypervisor that supports one or more virtual machines, virtual switches, or other suitable types of virtual components.

[0022] As used herein, "hypervisor" generally refers to the computer software, firmware, and / or hardware that creates, manages, and runs one or more virtual machines on a host. A "virtual machine" or "VM" is a simulation of a physical computing system using computer software. Different virtual machines can be configured to provide a suitable computing environment so that different processes can be run for the same or different users on a single host. During operation, the hypervisor on the host can present different virtual machines with virtual operating platforms to the hardware resources on the host and manage the operation of various processes for the virtual machines.

[0023] Also as used herein, the term "computing service" or "cloud service" generally refers to one or more computing resources provided over 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 software applications are hosted by a cloud service provider, such as in a data center, and accessed by users over a computer network. PaaS generally refers to the delivery of an operating system and associated services over a computer network without the need for downloading or installing. IaaS generally refers to outsourced equipment used to support storage, hardware, servers, network equipment, or other components, all of which can be accessed over a computer network.

[0024] As used herein, an "authentication scheme" generally refers to a set of different requirements for credentials, processes and / or protocols or other different operational characteristics associated with the authentication process. For example, bearer authentication is an authentication scheme that utilizes a data packet called a bearer token. A bearer token is a hidden string of characters typically generated by a server in response to a token request. A bearer token allows the 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, Windows authentication (formerly known as NTLM, also known as Windows NT challenge / response authentication) is an authentication scheme that hashes the entered username and password before sending it across the network. In yet another example, certificate authentication uses a digital certificate issued by a trusted certificate authority to identify a user, machine, device, or computing service before granting access to resources, networks, applications, etc. Other examples can include container authentication, challenge-handshake authentication, extensible authentication, and other suitable authentication schemes.

[0025] Also as used herein, an "authentication service" generally refers to a computing service that is configured to facilitate the authentication process upon receiving an authentication request from a requestor, such as another computing service. An exemplary authentication service is a security token service ("STS"), which is a cross-platform, open standard component of a single sign-on infrastructure framework. Within this claims-based identity framework, an STS can be responsible for issuing, validating, renewing, and revoking security tokens. The security tokens issued by the STS can then be used to identify the holder of the security token to other computing services (e.g., a computing service) for accessing resources and / or performing appropriate actions.

[0026] A "security token," "access token," or "token" generally refers to a digital data package that contains security credentials for a login session and identifies an entity, a group of entities, an entity's privilege(s), and, in some cases, a specific application. An exemplary security token can include a random string consisting of various fields and their values, such as an identifier, an identification of the login session, a user identifier, a default owner, and / or other suitable fields.

[0027] As further used herein, "authentication interface" or "authentication endpoint" generally refers to an access point for invoking an authentication service. The access point can be identified by an IP address, port number, server name, default server, or other suitable parameter that identifies the network location of the access point. For example, the authentication endpoint can be identified by the following URL: http: / / 131.107.72.15 / Security_Federation_SecurityTokenService_Symmetric.svc

[0028] In a cloud computing facility, authenticating a computing service to another computing service can 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. Thus, before initiating the authentication process, the computing service typically performs an authentication scheme discovery in order to decide which authentication scheme to use. For example, the computing service can transmit a discovery request to the authentication service. In response, the authentication service provides a discovery response that includes a list of one or more authentication schemes supported by the authentication service and a corresponding authentication interface. Upon receiving the discovery response, the computing service can then select one of the authentication schemes and initiate the authentication process by transmitting an authentication request to the authentication interface of the authentication service corresponding to the selected authentication scheme.

[0029] Having the requesting computing service choose the authentication scheme has several disadvantages. First, the authentication scheme discovery introduces delays as computing devices interact with each other. Second, as the number of computing services increases, the authentication service may become overloaded and need to switch to a new authentication scheme. However, updating each computing service to have an authentication library that complies with the new authentication scheme can be labor-intensive, tedious, and error-prone. Additionally, when the authentication service exposes multiple authentication interfaces, the computing service may be overloaded with authentication logic that keeps track of which authentication interface the computing service can call to initiate the authentication process.

[0030] Several embodiments of the disclosed technology can address at least some aspects of the aforementioned deficiencies by implementing service-side authentication scheme selection at an authentication service. In a specific implementation, the authentication service can be configured as a deployment request monitor that is used to detect authentication requests from a microservice before processing the authentication request. Upon detecting an incoming authentication request from a microservice, the request monitor can be configured to analyze at least a portion of the header and / or payload of the authentication request to obtain an indicator or "hint" as to which authentication scheme(s) are supported by or applicable to the microservice. Based on the "hint", the authentication service can indicate that a particular authentication scheme can be used to process the received authentication request. Therefore, several embodiments of the disclosed technology can facilitate efficient authentication of computing services by enabling dynamic authentication scheme selection at the authentication service, as described below with reference to Figure 1-6 Described in more detail.

[0031] Figure 1 is a schematic diagram illustrating a distributed computing system 100 with hosts implementing a shareable link for remote computing resource access according to an embodiment of the disclosed technology. Figure 1As shown in , the distributed computing system 100 can include a computer network (shown as "underlying network 108") that interconnects multiple hosts, shown as servers 106, multiple client devices 102 of users 101, and resource managers 110. Resource managers 110 can be cluster controllers, fabric controllers, database controllers, and / or other suitable types of controllers configured to monitor and manage resources and operations of servers 106 and / or other components in the distributed computing system 100. Although Figure 1 Specific components of the computing system 100 are shown in FIG. 1 , but in other embodiments, the computing system 100 can also include a network storage device, a maintenance manager, and / or other components in addition to or in place of the components in FIG. Figure 1 Other suitable components (not shown) other than those shown in FIG.

[0032] As in Figure 1 As shown in FIG, the underlying network 108 can include multiple network devices 112 interconnecting multiple servers 106 with client devices 102. In certain embodiments, the servers 106 can be organized into racks, zones, groups, sets, or other suitable divisions. For example, in the illustrated embodiment, the servers 106 are grouped into three clusters, which are individually identified as first, second, and third clusters 107a-107c. In the illustrated embodiment, each of the clusters 107a-107c is operably coupled to a corresponding network device 112a-112c, which is commonly referred to as a "top-of-rack" or "TOR" network device. The TOR network devices 112a-112c can then be operably coupled to additional network devices 112 to form a network with a hierarchical, flat, mesh, or other suitable type of topology. The computer network can enable communication between the servers 106 and the client devices 102. In other embodiments, multiple sets of host machines 107a-107c can share a single network device 112 or can have other suitable arrangements.

[0033] The servers 106 can be individually configured to provide computing, storage, and / or other suitable cloud computing services to the individual users 101. For example, as described below with reference to Figure 2 As described in more detail, each of the servers 106 can initiate and maintain one or more virtual machines 144 (e.g., Figure 2 ). User 101 can then utilize the instantiated virtual machine 144 to run appropriate processes for performing computing, communication, and / or other appropriate tasks. In certain embodiments, one of servers 106 can provide virtual machines 144 to multiple users 101. In other embodiments, multiple servers 106 can host virtual machines 144 for one or more users 101a-101c.

[0034] The client devices 102 can each comprise a computing device that facilitates the corresponding user 101 or administrator 104 to access computing services provided by the server 106 via the underlying network 108. For example, in the illustrated embodiment, the client devices 102 individually comprise desktop computers. In other embodiments, the client devices 102 can also comprise laptop computers, tablet computers, smartphones, or other suitable computing devices. Although for illustrative purposes, the client devices 102 are not shown in FIG. Figure 1 Three users 101 are shown in FIG, but in other embodiments, the distributed computing system 100 can facilitate any suitable number of users 101 or administrators to access cloud and / or other suitable types of computing services provided by the server 106 and / or other components in the distributed computing system 100.

[0035] Figure 2 is a diagram illustrating an embodiment of the disclosed technology that can be Figure 1 Schematic diagram of an overlay network 108' implemented on the underlying network 108 in FIG. Figure 2 For the sake of clarity, only Figure 1 Specific components of the underlying network 108. Figure 2 As shown in FIG, the first server 106a and the second server 106b can each include a CPU 132, a memory 134, and a network interface 136 that are operatively coupled to each other. The CPU 132 can include one or more processors, microprocessors, field programmable gate arrays, and / or other suitable logic devices. The memory 134 can include volatile and / or non-volatile media (e.g., ROM; RAM, magnetic disk storage media; optical storage media; flash memory devices, and / or other suitable storage media) and / or be configured to store data received from the CPU 132 and instructions for the CPU 132 (e.g., for executing the instructions described below). Figure 5A and 5B The network interface 136 can include a network interface card, a connection switch, and / or other suitable types of input / output devices configured to accept input from and provide output to other components on the overlay network 108'.

[0036] The first server 106a and the second server 106b can individually contain instructions in memory 134 that are executable by the CPU 132 to cause the individual servers 106a and 106b to provide a hypervisor 140 (individually identified as first and second hypervisors 140a and 140b). The hypervisor 140 can be individually configured to generate, monitor, terminate, and / or otherwise manage one or more virtual machines 144 organized into tenant sites 142. For example, as in Figure 2 As shown in FIG, the first server 106a can provide a first management program 140a that manages first and second tenant sites 142a and 142b, respectively. The second server 106b can provide a second management program 140b that manages first and second tenant sites 142a' and 142b', respectively. Figure 2 140 are individually shown as software components. However, in other embodiments, hypervisor 140 can also include firmware and / or hardware components.

[0037] The tenant sites 142 can each include multiple virtual machines 144 for a specific tenant. For example, the first server 106a and the second server 106b can both host tenant sites 142a and 142a' for the first user 101a. The first server 106a and the second server 106b can both host tenant sites 142b and 142b' for the second user 101b. Each virtual machine 144 can be running an application or process 147 corresponding to an operating system, middleware, and / or suitable applications. The running applications or processes 147 can each correspond to one or more computing services or other suitable types of computing services. Examples of such computing services can include platform services, microservices, authentication services, as described below with reference to Figure 3A and Figure 3B discussed in more detail.

[0038] Also in Figure 2 As shown in FIG, the computing system 100 can include an overlay network 108' having one or more virtual networks 146 that interconnect 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 first server 106a and second server 106b. A second virtual network 146b interconnects second tenant sites 142b and 142b' at first server 106a and second server 106b. Even though a single virtual network 146 is shown as corresponding to a single tenant site 142, in other embodiments, multiple virtual networks (not shown) can be configured to correspond to a single tenant site 146.

[0039] Virtual machines 144 on virtual network 146 can communicate with each other via underlying network 108 ( Figure 1 ) can communicate with each other, even if the virtual machines 144 are located or hosted on different servers 106. Communications within each of the virtual networks 146 can be isolated from communications with other virtual networks 146. In certain embodiments, communications can be allowed to cross from one virtual network 146 to another virtual network 146 in a controlled manner through a secure gateway or otherwise. A virtual network address can correspond to one of the virtual machines 144 in a particular virtual network 146. Thus, 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.

[0040] In operation, the server 106 can facilitate communications between virtual machines and / or applications running in the virtual machines 144. For example, the CPU 132 of the first server 106a can execute appropriate network communication operations to facilitate communication between the first virtual machine 144a by traversing the network interface 136 on the first server 106a, the underlying network 108 ( Figure 1 ) and the network interface 136 on the second server 106b, transmitting the packet 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 the other virtual machine 144b on the other server 106b to execute the appropriate application or process 147, thereby providing appropriate computing services for the user 101.

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

[0042] Components within a system can take different forms within the system. As an example, a system includes a first component, a second component, and a third component. These components can include, but are not limited to, a system in which the first component is a property in source code, the second component is a binary compiled library, and the third component is a thread created at runtime. A computer program, procedure, or process can be compiled into object, intermediate, or machine code and presented for execution by one or more processors of a personal computer, tablet computer, network server, laptop computer, smartphone, and / or other suitable computing device.

[0043] Likewise, a component may comprise a hardware circuit. In a specific example, hardware may be considered as rigid software, while software may be considered as liquefied hardware. As just one example, the software instructions in a component may be burned into a programmable logic array circuit, or may be designed as a hardware component with an appropriate integrated circuit. Likewise, hardware may be emulated by software. Various implementations of source code, intermediate code, and / or object code and associated data may be stored in a computer memory, including read-only memory, random access memory, magnetic 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 medium" does not include propagated signals.

[0044] As in Figure 3A As shown in FIG, the distributed computing system 100 can be configured to provide computing services organized as a collection of platform services 152 in a service platform 150 and microservices 154 configured to support the platform services 152. For example, the platform service 152′ can be an email exchange service configured to handle email reception, forwarding, synchronization, and other suitable operations. The exemplary email exchange service is included in the Office 365 suite offered by Microsoft Corporation of Redmonton, Washington. After authenticating to the email exchange service, the user 101 ( Figure 1 ) to access the content in the corresponding mailbox, such as emails and attachments. 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 154') to process email or other suitable types of content.

[0045] To facilitate operations between paired platform services 152 and microservices 154, the distributed computing system 100 can also provide an authentication service 156 that is operatively coupled to a network storage 118 containing configuration files 111. Configuration files 111 can individually contain information such as configuration for token acquisition and / or other suitable information. During operation, the authentication service 156 can be configured to receive a request 155 for a security token 157 from a microservice 154 (e.g., Figure 3B In response, the authentication service 156 can be configured to analyze the received request 155 for indicators or "hints" of one or more authentication schemes supported by the microservice 154'. The authentication service 156 can then be configured to select an authentication scheme supported by both the microservice 154 and the authentication service 156 based on the "hints" and the authentication profiles of the authentication service 156 and / or the microservice 154. Figure 4A and Figure 4B Example operations for analyzing received "hint" requests 155 are discussed in greater detail.

[0046] As in Figure 3B As shown in , the authentication service 156 can then be configured to initiate an authentication process with the microservice 152 to verify the credentials of the microservice 154 according to the selected authentication scheme. After verification of the credentials, the authentication service 156 can be configured to generate a token 156 (or other suitable security terms) and transmit it to the microservice 154. The microservice 154 can then use the received token 155 to authenticate itself to the platform service 152 (or other suitable computing service) in order to provide content 158 ​​to the platform service 152 or perform other suitable actions for the platform service 152. The platform service 152 can then forward the received content to the client device 102 ( Figure 1 ).

[0047] Figure 4A and Figure 4B is a schematic block diagram illustrating dynamic authentication scheme selection in a distributed computing system 100 according to an embodiment of the present technology. Figure 4A As shown in FIG, the authentication service 156 can include an authentication interface 160, a request monitor 161, and one or more authentication handlers 166 operatively coupled to each other. Figure 4A The foregoing components of the authentication service 156 are shown in FIG, but in other embodiments, the authentication service 156 can include additional and / or different components.

[0048] Authentication interface 160 can be configured to receive a request 155 for a security token 157 from microservice 154. In one implementation, request 155 can be configured as an HTTP request having a header 151 and a payload 153. In other implementations, request 155 can be configured as other suitable types of digital data packets. After receiving request 155, authentication interface 160 can be configured to perform error checking / correction and / or other suitable message processing operations before forwarding request 155 to request monitor 161 for further processing.

[0049] As in Figure 4A As shown in , request monitor 161 can include a request analyzer 162 and a scheme selector 164 that are operably coupled to each other. Request analyzer 162 can be configured to analyze received request 155 for one or more indicators or "hints" that microservice 154 supports authentication schemes. Request analyzer 162 can utilize various analysis techniques. For example, request analyzer 162 can be configured to parse at least a portion of header 151 or payload 153 of request 155 and determine whether particular header fields and / or corresponding values ​​are present. Based on such determination, request analyzer 161 can be configured to indicate to scheme selector 164 candidate authorization schemes supported by microservice 154.

[0050] exist Figure 4A Several examples of such header fields and / or values ​​are illustrated in . For example, request 155 may include an encrypted header including the value "WinAuthEnabled: true". In response, request analyzer 161 can indicate that Window authentication can be a candidate authentication scheme for processing the received request 155. In another example, request 155 can include a JavaScript Object Notation ("JSON") web token (shown in dashed lines for clarity). In response, request analyzer 161 can indicate that token authentication can be a candidate authentication scheme for processing the received request 155. In yet another example, request analyzer 161 can determine that request 155 does not include a header but is signed using a digital certificate, and that digital signature 159 is included in payload 153 of request 155. In response, request analyzer 161 can indicate that certificate authentication is a candidate authentication scheme for processing the received request 155.

[0051] In other implementations, the microservice 154 can also be configured to access an authentication repository (not shown) that contains configuration information for authentication schemes supported by the microservice 154. The microservice 154 can then be configured to add a header value to the request 155 that indicates the supported authentication schemes, such as "AuthScheme: Windows," as in Figure 4AUpon receiving request 155 , request analyzer 161 is able to extract the authentication schemes supported by microservice 154 from header 151 and indicate that the extracted authentication scheme is a candidate for processing request 155 .

[0052] Based on the indication from the request analyzer 162, the scheme selector 164 can be configured to determine whether the candidate authentication scheme is also supported by the authentication service 156. For example, the scheme selector 164 can be configured to access the network storage 118 containing the configuration files 111 to identify one or more authentication schemes supported by the authentication service 156. The scheme selector 164 can then be configured to determine whether the authentication scheme of the indicator matches one of the one or more authentication schemes supported by the authentication service 156. In response to determining that the candidate authentication scheme is also supported by the authentication service 156, the scheme selector 164 can be configured to initiate the appropriate authentication handler 166 by issuing an instruction 168 to the authentication handler 166 to facilitate an authentication process according to the identified authentication scheme, as in Figure 4B Upon successful authentication, the authentication handler 166 can be configured to provide the requested token 157 to the microservice 154 .

[0053] In response to determining that the authentication service 156 does not support the candidate authentication scheme, in one embodiment, the scheme selector 164 can ignore the extracted authentication scheme and instead initiate a default authentication handler 166 for facilitating the authentication process with the microservice 154. In another embodiment, the scheme selector 164 or other suitable component of the authentication service 156 can be configured to transmit a list of authentication schemes supported by the authentication service 156 for selection by the microservice 154 based on the client-side authentication scheme selection.

[0054] Several embodiments of the disclosed technology can therefore facilitate efficient authentication of computing services (such as microservices 154) to platform services 152 by enabling dynamic authentication scheme selection at authentication service 156. Different authentication schemes can be implemented in authentication service 156 with a single authentication interface 160 via request monitor 161. In this way, multiple microservices 154 can call the same authentication interface 160 even when the microservices 154 support different authentication schemes. Consequently, the authentication logic implemented at the microservice 154 can be reduced compared to client-side authentication scheme selection.

[0055] The aforementioned service-side authentication scheme selection also enables efficient deployment of new authentication schemes. For example, a new authentication scheme can be deployed to the authentication service 156. The new authentication scheme can be accessed via the same authentication interface 160 as other existing (one or more) authentication schemes. In this way, the new authentication scheme can be tested by providing a "hint" corresponding to the new authentication scheme to the authentication request, while the same authentication interface 160 continues to facilitate the authentication process according to the existing authentication scheme. When it is determined that the new authentication scheme is working properly, the authentication process at the authentication service 156 can be switched to use the new authentication scheme by simply modifying the "hint" included in the authentication request from the microservice 154.

[0056] Figure 5A and Figure 5B is a flow chart illustrating aspects of a process for implementing dynamic authentication scheme selection according to an embodiment of the present technology. Figures 1-4B Various aspects of the process are described in the context of the distributed computing system 100 in FIG. 1 , but in other embodiments, various aspects of the process can also be implemented in computing systems having additional and / or different components.

[0057] As in Figure 5A As shown in , process 200 can include receiving an authentication request at an authentication service at stage 202. Process 200 can then include analyzing the received authentication request for one or more scheme indicators or "hints" at stage 204. Figure 5B The example operations of analyzing the received authentication request for the candidate authentication scheme are discussed in more detail. The process 200 can then include a decision stage 206 to determine whether the indicated candidate scheme is also supported by the authentication service. In response to determining that the indicated candidate scheme is also supported by the authentication service, the process 200 can proceed to instruct the authentication handler to initiate the authentication process in response to the received authentication request in stage 208. In response to determining that the indicated candidate scheme is not supported by the authentication service, the process 200 can proceed to providing the available authentication schemes for selection in response to the received authentication request in stage 210, or performing the above-referenced steps. Figure 4A and Figure 4B Other suitable operations discussed.

[0058] Figure 5B Illustrated is an example operation of analyzing a received authentication request for a scheme indicator. Figure 5B As shown in , the operation can include an optional decision stage 212 to determine whether the received authentication request includes a scheme identified by the sender (e.g., Figure 3AIn response to determining that the received authentication request includes a scheme identified by the sender, the operation can include indicating at stage 214 that the identified scheme is a candidate scheme. The operation proceeds to another decision stage 216 to determine whether Window authentication is included in the header of the received authentication request. In response to determining that Window authentication is included in the header of the received authentication request, the operation can proceed to indicate at stage 218 that Window authentication is a candidate scheme. The operation can then proceed to another decision stage 220 to determine whether a token is included in the header of the received authentication request. In response to determining that a token is included in the received authentication request, the operation can proceed to indicate at stage 222 that bearer authentication is a candidate scheme. The operation can then proceed to yet another decision stage 224 to determine whether the received authentication request includes a digital signature. In response to determining that the received authentication request includes a digital signature, the operation can proceed to indicate at stage 226 that certificate authentication is a candidate scheme. In response to a negative determination at all of decision stages 216, 220, and 224, operations can proceed to indicate at stage 228 that no scheme was identified as a candidate scheme for processing the authentication request.

[0059] Figure 6 Is suitable for Figure 1 1. A computing device 300 is a component of a distributed computing system 100, such as a server 106, a client device 102, or a resource manager 110. In a very basic configuration 302, the computing device 300 can include one or more processors 304 and a system memory 306. A memory bus 308 can be used to communicate between the processor 304 and the system memory 306. Depending on the desired configuration, the processor 304 can be of any type, including but not limited to a microprocessor (μp), a microcontroller (μC), a digital signal processor (DSP), or any combination thereof. The processor 304 can include multiple levels of cache, such as a level 1 cache 310 and a level 2 cache 312, a processor core 314, and registers 316. An example processor core 314 can include an arithmetic logic unit (ALU), a floating point unit (FPU), a digital signal processing core (DSP core), or any combination thereof. An example memory controller 318 can also be used with the processor 304, or in some implementations, the memory controller 318 can be an internal part of the processor 304.

[0060] Depending on the desired configuration, system memory 306 can be of any type, including but not limited to: volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.), or any combination thereof. System memory 306 can include an operating system 320, one or more application programs 322, and program data 324. As shown in FIG7 , operating system 320 can include a hypervisor 140140 for managing one or more virtual machines 144. The basic configuration 302 described in Figure 6 denoted by those components within the inner dashed line.

[0061] Computing device 300 can have additional features or functionality and additional interfaces to facilitate communication between basic configuration 302 and any other devices and interfaces. For example, bus / interface controller 330 can 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 can be a removable storage device 336, a non-removable storage device 338, or a combination thereof. Examples of removable and non-removable storage devices include magnetic disk devices such as floppy disk drives and hard disk drives (HDDs), optical disk drives such as compact disk (CD) drives or digital versatile disk (DVD) drives, solid-state drives (SSDs), and tape drives, among others. Example computer storage media can 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 media" or "computer-readable storage device" do not include propagating signals and communication media.

[0062] 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 memory technology, CD-ROM, digital versatile disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and can be accessed by computing device 300. Any such computer-readable storage media can be part of computing device 300. The term "computer-readable storage media" does not include propagated signals and communication media.

[0063] The computing device 300 can 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 the bus / interface controller 330. Example output devices 342 include a graphics processing unit 348 and an audio processing unit 350, which can be configured to communicate with various external devices (such as a display or speakers) via one or more A / V ports 352. Example peripheral interfaces 344 include a serial interface controller 354 or a parallel interface controller 356, which can be configured to communicate with external devices such as input devices (e.g., a keyboard, mouse, pen, voice input device, touch input device, etc.) or other peripheral devices (e.g., a printer, scanner, etc.) via one or more I / O ports 358. Example communication devices 346 include a network controller 360, which can 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.

[0064] A network communication link can be an example of a communication medium. Communication media can typically be embodied by computer-readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transmission mechanism, and can include any information transfer medium. A "modulated data signal" can be a signal having one or more characteristics, and the characteristics are set or changed in a manner that encodes information in the signal. As an example and not limitation, communication media can include wired media, such as a wired network or a direct wired connection, and wireless media, such as acoustic, radio frequency (RF), microwave, infrared (IR) and other wireless media. The term computer-readable medium used in this article can include storage media and communication media.

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

[0066] From the foregoing, it will be appreciated that while specific embodiments of the present disclosure have been described herein for illustrative purposes, various modifications may be made without departing from the present disclosure. Additionally, many elements of one embodiment may be combined with other embodiments to supplement or replace elements of other embodiments. Accordingly, the technology is not intended to be limited except as set forth in the appended claims.

Claims

1. A method for executing instructions in a distributed computing system to provide dynamic authentication scheme selection for a plurality of computing services including an authentication service, the method comprising: receiving, at the authentication service, data representing an authentication request from a computing service; as well as In response to receiving the authentication request, analyzing, at the authentication service, the received data representing the authentication request for an indicator of an authentication scheme supported by the computing service that submitted the authentication request; determining whether the authentication scheme of the indicator matches one of one or more authentication schemes supported by the authentication service; as well as In response to determining that the authentication scheme supported by the computing service matches one of the one or more authentication schemes supported by the authentication service, initiating, using the authentication service, an authentication process using the computing service according to the authentication scheme supported by both the computing service and the authentication service; authenticating the authentication request from the computing service using the initiated authentication process; as well as Upon successful authentication of the authentication request, a security token is transmitted from the authentication service to the computing service, the security token being useful for authenticating the computing service to other computing services in the distributed computing system, whereby the authentication scheme is dynamically selected at the authentication service for providing the security token in response to the received authentication request.

2. The method according to claim 1, further comprising: accessing a database containing records of authentication configurations, the authentication configurations indicating the one or more authentication schemes supported by the authentication service; and Wherein, determining whether the authentication scheme of the indicator matches one of the one or more authentication schemes supported by the authentication service includes: determining whether the authentication scheme of the indicator matches one of the one or more authentication schemes supported by the authentication service based on the record of the authentication configuration of the authentication service.

3. The method according to claim 1, wherein Receiving the data representing the authentication request from the computing service includes: receiving the data representing the authentication request from the computing service at an authentication interface, the authentication interface being configured to facilitate the initiated authentication process with the computing service regardless of the authentication scheme under which the authentication process is initiated.

4. The method according to claim 1, wherein Analyzing the received data representing the authentication request includes: Parsing the header of the authentication request; determining whether the parsed header contains a value indicating an indication that Windows authentication is enabled; and In response to determining that the parsed header includes a value representing an indication that Windows authentication is enabled, indicating that the computing service supports Windows authentication.

5. The method according to claim 1, wherein Analyzing the received data representing the authentication request includes: Parsing the header of the authentication request; determining whether the parsed header includes a value indicating an indication that an authentication token is included in the authentication request; and In response to determining that the parsed header includes a value indicating an indication to include an authentication token in the authentication request, indicating that the computing service supports bearer authentication.

6. The method according to claim 1, wherein Analyzing the received data representing the authentication request includes: Parsing the payload of the authentication request; determining, based on the parsed payload, whether the authentication request is digitally signed with a digital signature; and In response to determining that the authentication request is digitally signed with a digital signature, the computing service is instructed to support certificate authentication.

7. The method according to claim 1, wherein Analyzing the received data representing the authentication request includes: Parsing the header of the authentication request; determining whether the header of the authentication request contains an authentication scheme selected by the computing service; and In response to determining that the authentication request includes an authentication scheme selected by the computing service, instructing the computing service to support the authentication scheme selected by the computing service.

8. The method according to claim 1, wherein: The authentication request is formatted as a Hypertext Transfer Protocol (HTTP) packet; analyzing the received data representing the authentication request includes analyzing received HTTP packets of the authentication request using an HTTP listener of the authentication service; as well as Initiating the authentication process includes: selecting an authentication handler corresponding to the authentication scheme supported by both the computing service and the authentication service; as well as The selected authentication handler is instructed to initiate the authentication process with the computing service.

9. The method according to claim 1, wherein: The authentication request is a first authentication request; The authentication scheme is a first authentication scheme; The computing service is a first computing service; The method further includes, upon receiving a second authentication request from a second computing service, at the authentication service, analyzing the received second authentication request for an indicator of a second authentication scheme supported by the second computing service, the second authentication scheme being different from the first authentication scheme; determining whether the second authentication scheme is supported by the authentication service; as well as In response to determining that the second authentication scheme is supported by the authentication service, initiating another authentication process using the second computing service according to the second authentication scheme; as well as Upon successful authentication, another security token is transmitted to the second computing service, the other security token being useful for authenticating the second computing service to other computing services in the distributed computing system.

10. A computing device in a distributed computing system having a plurality of additional computing devices individually executing instructions to provide a plurality of computing services, the computing device comprising: processor; as well as A memory operatively coupled to the processor, the memory containing instructions executable by the processor to provide authentication services in the distributed computing system and additional instructions executable by the processor to cause the computing device to perform the method according to any one of claims 1-9.

Images