Patent Application
20180324172
Services are often provided that offer remote access to an end-user's desktop hosted in a virtual machine either on-premises or in the cloud. These services can be secured by an authorization service in order to benefit from conditional access control. Conditional access control provides administrators the ability to require compliance with access control policies such as the need to perform multiple-factor authentication, use compliant devices etc. in order to access secured resources.
For these remote desktop/application services the authorization service provides the client with an access token containing claims, if the user is authorized to access the remote desktop/application. However, such access tokens cannot be used to log the user interactively to the domain in order for users to access other domain resources such as file shares etc. Currently, remote desktop/application services need to present an additional credential collection experience in order to obtain user credentials to log the user to the domain interactively. This requires the user to enter their credentials multiple times in order to access their remote desktop or remote applications. Additionally, this requirement also causes raw user credentials (like passwords) to be exposed and stored in various parts of the system, without the ability to control the lifetime of that exposure/storage.
The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.
The present example provides a method and system for obtaining or allowing single sign-on capability for remote applications that do not share information with one another or otherwise would not be able to use single sign on systems. The system receives a request from an application on a user device to register with a remote application or desktop service. The system then authenticates the user with the service, by receiving the user's credentials. This is provided to an authentication service that authenticates the user to access the service. It also provides a single sign-on token back to the application on the user's device such that the service and the application know that the capability has been activated. The user is presented with a list of remote applications that can be accessed through the service. The user selects one of these applications. The system receives the indication of the selection by the user and then proceeds to authenticate the user with the remote application. The remote application connects with the authentication service and presents the tokens that were generated in a certificate request to the authentication service. The authentication service uses this request and obtains either from its self or certificate authority a logon certificate that is used to log the user into the remote application. Each time the user changes the application the original credentials are presented by the service to the authentication service to obtain a new logon certificate for the user without further input from the user
Many of the attendant features will be more readily appreciated as the same becomes better understood by reference to the following detailed description considered in connection with the accompanying drawings.
The present description will be better understood from the following detailed description read in light of the accompanying drawings, wherein:
Like reference numerals are used to designate like parts in the accompanying drawings.
The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present example may be constructed or utilized. The description sets forth the functions of the example and the sequence of steps for constructing and operating the example. However, the same or equivalent functions and sequences may be accomplished by different examples.
When elements are referred to as being “connected” or “coupled,” the elements can be directly connected or coupled together or one or more intervening elements may also be present. In contrast, when elements are referred to as being “directly connected” or “directly coupled,” there are no intervening elements present.
The subject matter may be embodied as devices, systems, methods, and/or computer program products. Accordingly, some or all of the subject matter may be embodied in hardware and/or in software (including firmware, resident software, micro-code, state machines, gate arrays, etc.) Furthermore, the subject matter may take the form of a computer program product on a computer-usable or computer-readable storage medium having computer-usable or computer-readable program code embodied in the medium for use by or in connection with an instruction execution system. In the context of this document, a computer-usable or computer-readable medium may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The computer-usable or computer-readable medium may be for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media.
Computer storage media or computer readable storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and may be accessed by an instruction execution system. Note that the computer-usable or computer-readable medium can be paper or other suitable medium upon which the program is printed, as the program can be electronically captured via, for instance, optical scanning of the paper or other suitable medium, then compiled, interpreted, of otherwise processed in a suitable manner, if necessary, and then stored in a computer memory.
Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. This is distinct from computer storage media. The term “modulated data signal” can be defined as a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above-mentioned should also be included within the scope of computer-readable media, but not computer storage media.
When the subject matter is embodied in the general context of computer-executable instructions, the embodiment may comprise program modules, executed by one or more systems, computers, or other devices. Generally, program modules include routines, programs, objects, components, data structures, and the like, that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed as desired in various embodiments.
User device 110 is any device that a user uses to connect to the service 130. User device 110 can be for example, a personal computer, a tablet computer, a mobile phone, a desktop computer, a laptop computer, etc. Further, the user device 110 can be a virtualized version of these devices. The user device 110 may also include a number of local applications 111. Local applications 111 are applications that reside on the user device 110 from which the user can directly access the applications without the need to go through a network, such as network 115. The user device 110 also has the ability to access remote applications such as remote applications 150 through the network 115. Network 115 can be any type of network through which two machines can connect with each other and communication, such as an internet, an intranet, virtual private networks, telecommunications networks, cellular networks, wireless networks, etc.
User device 110 also includes an application 120 that permits the user to connect to the service via the network 115. The application 120 is in one embodiment a rich client application that capable of operating on multiple different platforms such as Windows, iOS, Android, Mac OS X, etc. This allows the user to have access to the service 130 regardless of the specific type of device the user has. The application 120 is configured to display to the user the remote applications 150 that have been published by the organization through the service for consumption by the user 101. The application 120 is configured to prompt the user when they first connect to the service 130 for their credentials and allows the user to be validated throughout the system. After entering their credentials here the user does not enter their credentials again to access any of the remote applications 150. Further, the application 120 does not transmit over the network any further credentials or validation of the user when the user moves between different remote applications 150. The application 120 once authorized to access the service 130 is configured to retrieve or fetch a list of the remote applications that have been published for the user.
The user selects an application from the list of applications in area 210. For example the user may click on the application 211. However other approaches of selecting the application may be used. As a result of the selection of the application 211, the application 211 attempts to connect to the virtual machine hosting the remote application 150. In contrast to previous systems the user is not prompted to provide the credentials a second time.
Returning back to
When the user launches an application, such as application 211, that has been published for their use the service 130 uses either an existing virtual machine 140 to run the selected application or spins up a new instance of the virtual machine 140, if required. The service 130 is also configured to join, if necessary, these virtual machines 140 to a domain associated with the organization. The user is then logged in to that virtual machine 140 and connected to the corresponding remote application 150 they desire to use.
Virtual machines 140 are virtualized versions of physical computing devices that contain the remote applications 150. Virtual machines 140 may include a remote desktop shell 141 (RDSH) such as the Remote Desktop Shell from Microsoft Corporation or similar component found on other types of virtual machines. Remote applications 150 are the applications that the organization has decided to publish to the user for consumption by the user. Any application can be presented as a remote application to the user so long as the organization has decided to publish the application.
Authentication service 160 is a component of the system 100 that authenticates the user to both access the service 130 and the applications 150. In one embodiment the authentication service 160 interacts with a security token service 161 that issues access tokens and refresh tokens to the application 120 and the service 130. The security token service 161 and the authentication service 160 can be in federation with each other. In some embodiments the authentication service 160 is able to authenticate the user on its own. However, in other embodiments the authentication service 160 interacts with a second authentication service 165. This second authentication service 165 may be an authentication service that is located on the premises 168 of the organization that is publishing the remote applications 150. When the user first signs in to the service 130 from their device 110 using the application 120, an authentication library 121 within the application 120 navigates to the authentication service 160. The authentication service 160 authenticates the user and provides the user an access token to access the service 130. If the authentication service uses a second authentication service 165, the authentication service 160 will redirect the user to the second authentication service 165 to authenticate the user. Once authenticated by the authentication service 165 the authentication service 160 provides the application with the corresponding access and refresh tokens 166.
Certificate authority 170 is a component of the system that issues the certificates 172 needed for the interactive logon of the user in the single sign on environment in response to a request for a certificate 171 from the service 130 through the authentication service 160 or 165. In some embodiments the certificate authority 170 is a component of the authentication service 160. In this embodiment when the authentication service 160 receives a request for a logon certificate 171 the authentication service 160 performs any required validation checks to ensure that certificates can be issued for the specific user. If this is possible the authentication service 160 issues the certificate 172 by signing certificate signing request and returning the logon certificate to the service 130. However, in other embodiments the certificate authority 170 is a separate from the authentication service 160. In this embodiment the authentication service 160 or 165 acts as an enrollment agent or registration authority. In this approach the authentication service 160 has been granted the necessary privileges to request user logon certificates on behalf of the end users. The certificate authority 170 in this embodiment is configured to recognize the authentication service 160 or 165 as an agent capable of issuing the logon certificates. The certificate authority 170 is configured to receive a request that is based on the certificate signing request from the authentication service 160 or 165 that has been signed using the appropriate certificate from the authentication service 160 or 165. The certificate authority 170 then processes the requests by validating this requests and returns a certificate 172 to the authentication service.
The process of
The security token service 161 redirects the request from the application to the corresponding authentication service 165 associated with the organization. This is illustrated at step 415. The request is received by the authentication service 165 for the organization. The authentication service 165 authenticates the user. This is illustrated at step 420. Next or at the same time a persistent single sign-on token is generated for the user. In some embodiments this may be represented as a single sign-on cookie. This persistent single sign-on token 122 is cached in an authentication library 121 for the application 120. This is illustrated at step 430. Also at this time the authentication service 165 provides a federated access token to the application 120.
Following the authentication of the user by the authentication service 160 or 165, the authentication service 165 redirects the application back to the security token service 161. This is illustrated at step 440. At this step the security token service validates the federated access token. Upon successful validation of the federated access token the security token service 161 issues an access token and refresh token pair to the application 120. This is illustrated at step 445. The authentication library for the application 120 then caches this access token and refresh token pair. This is illustrated at step 450. This pair is then later used by the application in subsequent interactions with the service 130 to provide authorization of the application 120 to access the service 130. However, at this point all that has been authorized is the ability of the application 120 to access the service 130.
In order for the application 120 to connect to the remote desktop shell component 141 on the target virtual machine 140 and request an interactive logon for the user, the application 120 must first obtain an access token for the remote desktop shell 141 that was issued by authentication service 160 or 165. This is illustrated at step 550. Again it should be noted that the remote desktop shell 141 component is on a domain joined machine and will trust access tokens issued by the on-premises authentication service 165 instance of which it is a relying party.
The application 120 uses authentication library 121 to obtain an access token and refresh token 166 from the authentication service instance using an authorization code grant type such as OpenID Connect or other type. The application 120 will request a new certificate that is required in order to exchange a token issued by the authentication service 160 or 165 for an interactive logon certificate. It should be noted that this access token and refresh token is different than the tokens received earlier in that the first access and refresh tokens were for the user and not for the application. The authentication service consumes the persistent single sign on token that was previously issued by the authentication service 160/165 during the process of authenticating the application 120 with the service 130. As the user 101 has already authenticated themselves the application 120 acquires the access and refresh tokens without further prompting the user to provide their credentials. In some embodiments the authentication service 160/165 verifies that the corresponding application permission entry exists for the application on the client device 110 to request a token for the remote desktop shell 141 on behalf of the authenticated user. If the correct permissions exist the authentication service 160/165 will issue the access token and the refresh token to the application. The access token will include information in it, such as a claim, that indicates that the access token can be used to obtain a logon certificate for the authenticated user.
Once the application has obtained the access token from the authentication service such that it can access the remote desktop shell 141, the process proceeds to log the user on to the virtual machine 140. To log the user on to the virtual machine 140 a logon certificate is need by the system. The process of obtaining the logon certificate is illustrated in
The application 120 connects with the appropriate remote desktop shell 141 instance. This is illustrated at step 610. At this step the application 120 presents the access token that was issued to the application 120 by the authentication service 160/165. The remote desktop shell 141 instance validates the access token. This is illustrated at step 620. At this step the remote desktop shell 141 performs regular token validation checks for the access token. This validation process can include validating the validity of the token, verifying the signature of the token, etc. It should be noted that any validation process on the access token may be performed. The remote desktop shell 141 also checks that the token has the claim that indicates that the access token can be used to obtain the logon certificate.
Once the token has been validated by the remote desktop shell 141, the remote desktop shell 141 constructs a public/private key pair that will be used in a certificate signing request that requests the logon certificate from the authentication service. The remote desktop shell 141 then constructs the certificate signing request. This is illustrated at step 630. This certificate signing request can in one embodiment be in accordance with a protocol such as RFC 2986. However, as long as the certificate signing request is in the format that is expected by the authentication service 160/165 the remote desktop shell 141 can use any format for the request.
Next the remote desktop shell 141 presents to the authentication service 160/165 the logon certificate request 171. This is illustrated at step 640. The logon certificate request includes several attributes. The logon certificate request includes the access token that was presented to it by the application 120. This is the access token that was issued to the application to access the service 130. The logon certificate request also includes a means for authenticating the remote desktop shell 141 with the authentication service 160/165. In one embodiment this means is through an authentication service such as Windows Integrated Authentication. However, other authentication services can be used. Finally the logon certificate request includes the certificate signing request that was generated at step 630.
The authentication service 160/165 then validates the logon certificate request. This is illustrated at step 650. The authentication service check to see if the presented access token is valid, unexpired, signed by the authentication service and contains the claim that the access token can used to obtain the logon certificate. As part of the validation of the request the authentication service 160/165 performs its own authentication of the remote desktop shell 141 using the same authentication service as the remote desktop shell 141 used to authenticate itself to the authentication service.
Once the authentication of the remote desktop shell 141 has been completed and the logon certificate request has been validated a logon certificate for the user is returned to the remote desktop shell 141. This is illustrated at step 660. This logon certificate is then used by the remote desktop shell 141 to log the user onto the applications that are hosted by the virtual machine 140. In this way the user is able to move between applications without having to constantly reenter their credentials. In embodiments where the authentication service does not issue the logon certificate the authentication service constructs and sends a certificate request to the certificate authority 170. Once the authentication service receives the logon certificate back from the certificate authority 170 it forwards this certificate to the remote desktop shell 141. Otherwise the authentication service generates the logon certificate itself and returns this to the remote desktop shell 141. When the user moves to a different remote application 150 at a later time the system 100 repeats the above processes to obtain a new logon certificate for the user based on the original access token to the service 130.
The computing device 700 can be any general or special purpose computer now known or to become known capable of performing the steps and/or performing the functions described herein, either in software, hardware, firmware, or a combination thereof.
In its most basic configuration, computing device 700 typically includes at least one central processing unit (CPU) 702 and memory 704. Depending on the exact configuration and type of computing device, memory 704 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. Additionally, computing device 700 may also have additional features/functionality. For example, computing device 700 may include multiple CPU's. The described methods may be executed in any manner by any processing unit in computing device 700. For example, the described process may be executed by both multiple CPU's in parallel.
Computing device 700 may also include additional storage (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape. Such additional storage is illustrated in
Computing device 700 may also contain communications device(s) 712 that allow the device to communicate with other devices. Communications device(s) 712 is an example of communication media. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term computer-readable media as used herein includes both computer storage media and communication media. The described methods may be encoded in any computer-readable media in any form, such as data, computer-executable instructions, and the like.
Computing device 700 may also have input device(s) 710 such as keyboard, mouse, pen, voice input device, touch input device, etc. Output device(s) 708 such as a display, speakers, printer, etc. may also be included. All these devices are well known in the art and need not be discussed at length. Those skilled in the art will realize that storage devices utilized to store program instructions can be distributed across a network. For example a remote computer may store an example of the process described as software. A local or terminal computer may access the remote computer and download a part or all of the software to run the program. Alternatively the local computer may download pieces of the software as needed, or distributively process by executing some software instructions at the local terminal and some at the remote computer (or computer network). Those skilled in the art will also realize that by utilizing conventional techniques known to those skilled in the art that all, or a portion of the software instructions may be carried out by a dedicated circuit, such as a DSP, programmable logic array, or the like.
In summary the present disclosure is provides a method and system for obtaining or allowing single sign-on capability for remote applications that do not share information with one another. The system receives a request from an application on a user device to register with a remote application or desktop service. The system then authenticates the user with the service, by receiving the user's credentials. This is provided to an authentication service that authenticates the user to access the service. It also provides a single sign-on token back to the application on the user's device such that the service and the application know that the capability has been activated. The user is presented with a list of remote applications that can be accessed through the service. The user selects one of these applications. The system receives the indication of the selection by the user and then proceeds to authenticate the user with the remote application. The remote application connects with the authentication service and presents the tokens that were generated in a certificate request to the authentication service. The authentication service uses this request and obtains either from its self or certificate authority a logon certificate that is used to log the user into the remote application. Each time the user changes the application the original credentials are presented by the service to the authentication service to obtain a new logon certificate for the user without further input from the user.
