Isolating a redirected biometric device to a remote session

A redirected biometric device can be isolated to a remote session. Such session level restrictions can be implemented using a filter driver that is layered on top of the device driver stack for the redirected biometric device. When a biometric device is redirected by a user to a remote session, the filter driver can obtain an identifier of the biometric device and maintain a mapping between the identifier and the session ID of the redirecting user's remote session. Then, when an application executing on the server attempts to enumerate biometric devices, a hooking component can inspect and modify the corresponding response to remove any biometric devices that are not redirected to the same user session in which the application is executing. In this way, the application will not be able to discover any biometric devices that are redirected to other user sessions.

CROSS-REFERENCE TO RELATED APPLICATIONS

BACKGROUND

The present invention is generally directed to USB device redirection in a virtual desktop infrastructure (VDI) environment. USB device redirection generally refers to making a USB device that is connected to a client accessible within a virtual desktop as if the USB device had been physically connected to the virtual desktop. In other words, when USB device redirection is implemented, a user can connect a USB device to his or her client terminal and the USB device will function as if it had been connected to the server.

FIGS. 1 and 2and the following description will provide a general overview of how USB device redirection can be implemented in accordance with some embodiments of the present invention. InFIG. 1, a computing system100is depicted as including a number of client terminals102a-102n(referenced generally herein as client(s)102) in communication with a server104via a network106. Server104can be configured to support a remote session (e.g., a remote desktop session) wherein a user at a client102can remotely access applications and data at the server104from the client102. Such a connection may be established using any of several well-known techniques such as the Remote Desktop Protocol (RDP) and the Citrix® Independent Computing Architecture (ICA).

Client terminal102may represent a computer, a mobile phone (e.g., smart phone), a laptop computer, a thin client terminal, a personal digital assistant (PDA), a portable computing terminal, or a suitable terminal or device with a processor. Server104may represent a computer, a laptop computer, a computing terminal, a virtual machine (e.g., VMware® Virtual Machine), a desktop session (e.g., Microsoft Terminal Server), a published application (e.g., Microsoft Terminal Server) or a suitable terminal with a processor.

Client102may initiate a remote session with server104by sending a request for remote access and credentials (e.g., login name and password) to server104. If server104accepts the credentials from client102, then server104may establish a remote session, which allows a user at client102to access applications and data at server104. During the remote session, server104sends display data to client102over network106, which may include display data of a desktop and/or one or more applications running on server104. The desktop may include, for example, icons corresponding to different applications that can be launched on server104. The display data allows client102to locally display the desktop and/or applications running on server104.

During the remote session, client102may send user commands (e.g., inputted via a mouse or keyboard at client102) to server104over network106. Server104may process the user commands from client102similar to user commands received from an input device that is local to server104. For example, if the user commands include mouse movements, then server104may move a pointer on the desktop running on server104accordingly. When the display data of the desktop and/or application changes in response to the user commands, server104sends the updated display data to client102. Client102locally displays the updated display data so that the user at client102can view changes at server104in response to the user commands. Together, these aspects allow the user at client102to locally view and input commands to the desktop and/or application that is running remotely on server104. From the perspective of the client, the desktop running on server104may represent a virtual desktop environment. For purposes of this application, device240can represent a biometric device such as a fingerprint scanner.

FIG. 2is a block diagram of a local device virtualization system200in accordance with embodiments of the present invention. System200may include client102in communication with server104over network106as illustrated inFIG. 1. Client102may include a proxy210, a stub driver220, and a bus driver230. Client102can be connected to a device240, as shown inFIG. 2. Server104may include an agent250and a virtual bus driver260.

In accordance with USB device redirection techniques, while device240is not locally or physically connected to server104and is remote to server104, device240appears to server104as if it is locally connected to server104, as discussed further below. Thus, device240appears to server104as a virtual device290.

By way of illustration and not limitation, device240may be any type of USB device including a machine-readable storage medium (e.g., flash storage device), a printer, a scanner, a camera, a facsimile machine, a phone, an audio device (e.g., a headset), a video device (e.g., a camera), a peripheral device, or other suitable device that can be connected to client102. Device240may be an external device (i.e., external to client102) or an internal device (i.e., internal to client102).

Bus driver230can be configured to allow the operating system and programs of client102to interact with device240. In one aspect, when device240is connected to client102(e.g., plugged into a port of client102), bus driver230may detect the presence of device240and read information regarding device240(“device information”) from device240. The device information may include features, characteristics and other information specific to device240such as a device descriptor (e.g., product ID, vendor ID and/or other information), a configuration descriptor, an interface descriptor, an endpoint descriptor and/or a string descriptor. Bus driver230may communicate with device240through a computer bus or other wired or wireless communications interface.

In accordance with USB device redirection techniques, device240may be accessed from server104as if the device were connected locally to server240. Device240may be accessed from server104when client102is connected to server104through a remote session running on server104. For example, device240may be accessible from the desktop running on server104(i.e., virtual desktop environment). To enable this, bus driver230may be configured to load stub driver220as the default driver for device240. Stub driver220may be configured to report the presence of device240to proxy210and to provide the device information (e.g., device descriptor) to proxy210. Proxy210may be configured to report the presence of device240, along with the device information, to agent250of server104over network106(e.g., via a TCP or UDP socket). Thus, stub driver220redirects device240to server104via proxy210.

Agent250may be configured to receive the report from proxy210that device240is connected to client102and the device information. Agent250may further be configured to associate with the report from proxy210one or more identifiers for client102and/or for a remote session through which client102is connected to server104, such as a session number or a session locally unique identifier (LUID). Agent250can provide notification of device240, along with the device information, to virtual bus driver260. Virtual bus driver260(which may be a Dell Wyse TCX USB bus driver, or any other bus driver) may be configured to create and store in memory a record corresponding to device240. This record may include at least part of the device information and session identifiers received from agent250. Virtual bus driver260may be configured to report to operating system170of server104that device240is connected and to provide the device information to the operating system. This allows the operating system of server104to recognize the presence of device240even though device240is connected to client102.

The operating system of server104may use the device information to find and load one or more appropriate device drivers for device240at server104. Each driver may have an associated device object (object(s)281a,281b, . . . ,281n, referred to generally as device object(s)281), as illustratively shown inFIG. 2. A device object281is a software implementation of a real device240or a virtualized (or conceptual) device290. Different device objects281layer over each other to provide the complete functionality. The different device objects281are associated with different device drivers (driver(s)282a,282b, . . .282n, referred to generally as device driver(s)282). In an example, a device240such as a USB flash drive may have associated device objects including objects corresponding to a USB driver, a storage driver, a volume manager driver, and a file system driver for the device. The device objects281corresponding to a same device240form a layered device stack280for device240. For example, for a USB device, a USB bus driver will create a device object281astating that a new device has been plugged in. Next, a plug-and-play (PNP) component of the operating system will search for and load the best driver for device240, which will create another device object281bthat is layered over the previous device object281a. The layering of device objects281will create device stack280.

Device objects281may be stored in a memory of the server104associated with virtual bus driver260. In particular, device objects281and resulting device stack280may be stored in random-access memory of server104. Different devices240/290can have device stacks having different device objects and different numbers of device objects. The device stack may be ordered, such that lower level device objects (corresponding to lower level device drivers) have lower numbers than higher level device objects (corresponding to higher level device drivers). The device stack may be traversed downwards by traversing the stack from higher level objects to lower level objects. For example, in the case of an illustrative device stack280corresponding to a USB flash drive, the ordered device stack may be traversed downwards from a high-level file system driver device object, to a volume manager driver device object, to a storage driver device object, to a USB driver device object, and finally to a low-level virtual bus driver device object. Different device stacks280can be layered over each other to provide the functionality of the devices240/290inside devices, like USB Headsets, or USB pen drives. A USB pen drive, for example, can create a USB device stack first, over which it can create a storage device stack, where each of the device stacks have two or more device objects.

Once one or more device object(s)281are loaded by operating system170of server104, each device object281can create a symbolic link (also referred to as a “device interface”) to device object281and associated device driver282. The symbolic link is used by applications running on server104to access device object281and device240/290. The symbolic link can be created by a call to a function such as IoCreateSymbolicLink( ) including such arguments as a name for the symbolic link, and a name of device object281or associated device240. In one example, for example, a symbolic link to a USB flash drive device240is created by a call from a device object281for device240to the function IoCreateSymbolicLink( ) including arguments “\\GLOBAL??\C:” (i.e., the name for the symbolic link) and “\Device\HarddiskVolume1” (i.e., a name of the device object).

The creation of a symbolic link results in an entry being created in an object manager namespace (OMN) of operating system170. The OMN stores information on symbolic links created for and used by operating system170, including symbolic links for devices240, virtualized devices290, and applications270running on server104.

As a result of the symbolic link creation process, a symbolic link to device240is enumerated in the OMN of server104. Once the presence of device240is reported to operating system170of server104, device240may be accessible from a remote session (and associated desktop) running on server104(i.e., virtual desktop environment). For example, device240may appear as an icon on the virtual desktop environment and/or may be accessed by applications running on server104.

An application270running on server104may access device240by sending a transaction request including the symbolic link for device240to operating system170. Operating system170may consult the Object Manager Namespace to retrieve an address or other identifier for the device itself240or for a device object281associated with device240. Using the retrieved address or identifier, operating system170forwards the transaction request for device240either directly, through a device object281of device stack280, and/or through virtual bus driver260. Virtual bus driver260may direct the transaction request to agent250, which sends the transaction request to proxy210over network106. Proxy210receives the transaction request from agent250, and directs the received transaction request to stub driver220. Stub driver220then directs the transaction request to device240through bus driver230.

Bus driver230receives the result of the transaction request from device240and sends the result of the transaction request to stub driver220. Stub driver220directs the result of the transaction request to proxy210, which sends the result of the transaction request to agent250over network106. Agent250directs the result of the transaction request to virtual bus driver260. Virtual bus driver260then directs the result of the transaction request to application270either directly or through a device object281of device stack280.

Thus, virtual bus driver260may receive transaction requests for device240from application270and send results of the transaction requests back to application270(either directly or through a device object281of device stack280). As such, application270may interact with virtual bus driver260in the same way as with a bus driver for a device that is connected locally to server104. Virtual bus driver260may hide the fact that it sends transaction requests to agent250and receives the results of the transaction requests from agent250instead of a device that is connected locally to server104. As a result, device240connected to client102may appear to application270as if the physical device240is connected locally to server104.

In certain operating systems, such as the Windows operating system, the creation of the symbolic link for a device240results in an entry being created in a Global namespace of the Object Manager Namespace. Because the symbolic link is created in the Global namespace, the symbolic link can be accessed from any session running on server104. As a result, the device240associated with the symbolic link can be accessed from any user session on server104, and/or from any client terminal having an active user session on server104.

Oftentimes, it is undesirable to allow a redirected device to be accessed from any user session. For this reason, various techniques have been developed to implement “session level restrictions” which allow a redirected device to only be accessed by applications executing within the redirecting user's remote session (i.e., the remote session of the user of the client terminal to which the redirected device is connected).

One technique, which is described in U.S. Pat. No. 8,990,394, involves loading a driver as an upper level filter driver for the class of device to be restricted so that the driver can prevent and block attempts to access the redirected device that originate from another user session. Although this technique is suitable for many classes of devices, it will not work for biometric devices. In particular, in this technique, the upper level filter driver identifies the user session that is associated with each I/O request that targets the redirected device and then restricts access based on the identified user session. In the case of a biometric device, however, the operating system may cause all I/O requests targeting a biometric device to be handled by a service running in a non-user, privileged session (e.g., by the Windows Biometric Service which runs in session 0).

FIG. 3illustrates an example of how a redirected biometric device340/390would be accessed by an application270running in a remote session. As shown, the general redirection architecture is the same inFIGS. 2 and 3. The distinction inFIG. 3is in how application270accesses the redirected device. Because the redirected device is a biometric device, application270, which is executing in a user/remote session, will be required to employ biometric library170b(e.g., the Winbio DLL) to access biometric device340. More specifically, when application270calls a function of biometric library170bto access biometric device340, the function will invoke biometric service170awhich is running in session 0. Biometric service170awill then interface with biometric device driver stack380(e.g., by causing appropriate IRPs to be passed down the stack). If an upper level filter driver were added to biometric device driver stack in accordance with the techniques of U.S. Pat. No. 8,990,394, this filter driver would not be able to determine from the I/O requests (e.g., IRPs) that application270was the origin of the I/O requests. Instead, the I/O requests would appear to have been originated by biometric service170afrom within session 0. Notably, this would also be the case if an application running in another user's remote session attempted to access biometric device340.

BRIEF SUMMARY

The present invention extends to methods, systems, and computer program products for isolating a redirected biometric device to a user session. Such session level restrictions can be implemented using a filter driver that is layered on top of the device driver stack for the redirected biometric device. When a biometric device is redirected by a user to a remote session, the filter driver can obtain an identifier of the biometric device and maintain a mapping between the identifier and the session ID of the redirecting user's remote session. Then, when an application executing on the server attempts to enumerate biometric devices, a hooking component can inspect and modify the corresponding response to remove any biometric devices that are not redirected to the same user session in which the application is executing. In this way, the application will not be able to discover any biometric devices that are redirected to other user sessions.

In one embodiment, the present invention is implemented as a method for isolating a biometric device to a user session. In response to an application that is executing in a user session requesting enumeration of biometric devices that are connected to the server, a hooking component intercepts an enumeration response that includes an identifier of a biometric device. The hooking component extracts the identifier of the biometric device from the enumeration response and sends the identifier to a filter driver. The filter driver employs the identifier of the biometric device to obtain a session ID of a user session to which the biometric device is redirected and returns the session ID to the hooking component. The hooking component compares the session ID received from the filter driver to a session ID of the user session in which the application is executing. When the hooking component determines that the session ID received from the filter driver does not match the session ID of the user session in which the application is executing, the hooking component removes the identifier of the biometric device from the enumeration response prior to allowing the enumeration response to be provided to the application. Whereas, when the hooking component determines that the session ID received from the filter driver matches the session ID of the user session in which the application is executing, the hooking component allows the enumeration response to be provided to the application without removing the identifier of the biometric device.

In another embodiment, the present invention is implemented as a method for isolating a biometric device that is redirected to a user session so that the biometric device is not accessible to applications that are executing in other user sessions. In response to a biometric device being connected to a client terminal that has remotely established a user session on a server, a mapping is created between an identifier of the biometric device and a session ID of the user session. In response to a request to enumerate biometric devices that is made by a first application executing in a different user session, an enumeration response that includes the identifier of the biometric device is intercepted. Prior to allowing the enumeration response to proceed to the first application, the identifier of the biometric device is extracted from the enumeration response and used to retrieve the session ID to which the identifier was mapped. The retrieved session ID is compared to a session ID of the first application that requested enumeration of the biometric devices. Upon determining that the retrieved session ID does not match the session ID of the first application, the identifier is removed from the enumeration response prior to allowing the enumeration response to proceed to the first application.

In another embodiment, the present invention is implemented as a method for isolating a biometric device to a user session. A hooking component intercepts an enumeration response that includes at least one identifier of a biometric device and that is intended for an application executing in a first user session. For each identifier in the enumeration response, the method includes: extracting the identifier of the biometric device from the enumeration response and sending the identifier to a filter driver; employing, by the filter driver, the identifier of the biometric device to obtain a session ID with which the identifier is associated and returning the session ID to the hooking component; and when the hooking component determines that the session ID received from the filter driver does not match the session ID of the first user session, removing, by the hooking component, the identifier of the biometric device from the enumeration response. Finally, after removing each identifier that is associated with a session ID that does not match the session ID of the first user session, the enumeration response is provided to the application.

DETAILED DESCRIPTION

In this specification, a remote session should be construed as a user session on a server that a remote user has established. Therefore, the terms user session and remote session may be used interchangeably. In the context of the present invention, a biometric device should be construed as a device that provides biometric-based authentication. Such biometric devices will typically be connected to a user's client terminal and redirected to a user session that the user established on a server, but the present invention would also extend to biometric devices that are connected directly to the server.

A WinBio device should be construed as a biometric device that is accessed via the Windows Biometric Framework. A Morpho device should be construed as a biometric device that is accessed via the MorphoSmart SDK (or Morpho Framework). The term session level restrictions refers to the ability to isolate a redirected device to a particular user session or sessions. Although the present invention will be described with reference to how session level restrictions are implemented within the Windows Biometric Framework and the Morpho Framework, the present invention may also be implemented to provide session level restrictions in other frameworks. Terms such as “hooking component,” “hooking,” “intercepted calls,” “hooked function,” etc. are intended to generally encompass any of the many different techniques for performing API hooking, and the present invention should not be limited to any particular hooking technique.

FIG. 4illustrates an example architecture that can be employed by the present invention to implement session level restrictions. This architecture generally matches the redirection architecture shown inFIG. 3with the addition of various components and data structures. As shown, to provide session level restrictions for a redirected biometric device, a filter driver401can be added as an upper level filter driver on biometric device driver stack380. Additionally, a hooking component450can be added as a user session component that is configured to hook one or more functions of biometric library170b. Hooking component450can be configured to communicate with filter driver401(e.g., via IOCTLs) when it intercepts a call to a hooked function as will be described below.

Filter driver401can be configured to create and maintain device instance ID mappings401aand/or device serial number mappings401bthat can be employed when processing an intercepted call to a hooked function. Each entry in mappings401amaps the device instance ID of a biometric device to the session ID of the user session to which the biometric device is redirected. As will become apparent below, filter driver401can map the device instance ID of a WinBio device to the session ID.

In the case of Morpho devices, filter driver401may instead map the biometric device's serial number to the session ID. Accordingly, each entry in mappings401bmaps the device serial number of a biometric device to the session ID of the user session to which the biometric device is redirected.

Filter driver401can create these mappings as part of the device initialization process. Therefore, when a WinBio device is redirected, filter driver401can obtain the device instance ID (e.g., by sending IRP_MJ_PNP and IRP_MN_QUERY_ID IRPs to virtual USB bus driver260) and the session ID (e.g., from virtual USB bus driver260which may have received it from agent250as part of an IOCTL for adding the redirected WinBio device) and add an entry to mappings401a. In contrast, when a Morpho device is redirected, filter driver401can obtain the device serial number (e.g., by using the ILV_SECU_GET_CONFIG command of the MorphoSmart SDK) and the session ID (e.g., in the same manner as with a WinBio device) and add an entry to mappings401b. This will allow the present invention to provide session level restrictions for WinBio and Morpho devices simultaneously. In other frameworks, filter driver401could similarly employ the available functionality to obtain a unique identifier of the biometric device and the session ID to add an entry to a corresponding mapping data structure. A flowchart of the process performed by filter driver401during the device initialization process is provided inFIG. 7.

In the subsequent examples, it will be assumed that there are four biometric devices that are currently redirected (or possibly connected) to the server, and therefore, filter driver401has added four entries to mappings401a/401b. As shown, two of the redirected biometric devices having device instance IDs of ID1 and ID2 are assumed to be WinBio devices that are redirected to sessions having session IDs of SessionID17 and SessionID21 respectively. The other two redirected biometric devices are assumed to be Morpho devices having device serial numbers of SN1 and SN2 which are redirected to sessions having session IDs of SessionID25 and SessionID13 respectively.

FIGS. 5A-5Eprovide an example of how hooking component450and filter401can interoperate to enforce session level restrictions for WinBio devices. In this example, it will be assumed that an application270is executing within a user session having a session ID of SessionID21. In step1, application270requests that each of the WinBio devices connected to the server be enumerated. In the Windows Biometric Framework, this can be accomplished using the WinBioEnumBiometricUnits function provided by biometric library170b. Prior to describing the next steps, it is noted that, absent the present invention, this function call would result in both WinBio devices that are currently connected to the server being enumerated to application270(i.e., application270would gain access to both WinBio devices).

As mentioned above, hooking component450can be configured to hook the WinBioEnumBiometricUnits function so that it can modify its behavior. As represented inFIG. 5A, however, hooking component450can initially allow this function call to proceed to biometric service170afor typical handling. In step2shown inFIG. 5B, this typical handling will result in biometric service170acreating a list of the WinBio devices that are currently connected to the server. In particular, the WinBioEnumBiometricUnits function returns an array of _WINBIO_UNIT_SCHEMA structures and a UnitCount parameter that identifies the number of structures in the array. Each _WINBIO_UNIT_SCHEMA structure represents a particular biometric device and includes the device instance ID, among many other parameters, for that device. Therefore, the value of the UnitCount parameter identifies the number of WinBio devices that are connected to the server. In step3, hooking component450intercepts the WinBioEnumBiometricUnits response thereby preventing the unaltered response from reaching application270.

In step4shown inFIG. 5C, hooking component450can extract the device instance ID from one of the _WINBIO_UNIT_SCHEMA structures and submit it to filter driver401(e.g., as an IOCTL). In response, as shown in step5, filter driver401can use the submitted device instance ID to retrieve the corresponding session ID from mappings501a. In this case, the retrieved session ID will be SessionID17.

In step6shown inFIG. 5D, filter driver401returns SessionID17 to hooking component450thereby informing hooking component450that the WinBio device having a device instance ID of ID1 is redirected to the user session having a session ID of SessionID17. In step7, hooking component450can compare the received session ID to the session ID of the user session in which it is executing (and therefore to the session ID in which application270is executing). In this case, hooking component450will determine that the WinBio device with a device instance ID is redirected to a different user session (SessionID17) from the one in which hooking component450is executing (SessionID21). As a result, in step8, hooking component450can remove the corresponding _WINBIO_UNIT_SCHEMA structure from the array identified in the WinBioEnumBiometricUnits response. In conjunction with removing the structure, hooking component450can also decrement the value of the UnitCount parameter within the response.

Hooking component450will perform steps4-7for each _WINBIO_UNIT_SCHEMA structure (i.e., for each connected WinBio device) and will remove (step8) the structure unless the session ID returned by filter driver401matches the session ID of the session in which hooking component450is executing. Therefore, after this processing, the array should only include a _WINBIO_UNIT_SCHEMA structure pertaining to a WinBio device that is redirected to the same session in which hooking component450is executing. In this case, because the WinBio device with a device instance ID of ID2 is redirected to the session with the session ID of sessionID21, only the structure with a device instance ID of ID2 will remain. Accordingly, in step9shown inFIG. 5E, hooking component450allows the WinBioEnumBiometricUnits function call to complete such that the response provided to application270includes an array containing only one _WINBIO_UNIT_SCHEMA structure and a UnitCount value of 1. Application270, and the redirecting user, will therefore only have access to his or her redirected WinBio device.

FIGS. 6A-6Eprovide a substantially similar example of how hooking component450and filter401can interoperate to enforce session level restrictions for Morpho devices. In this example, biometric service170aand biometric library170bcan represent the MorphoSmart SDK rather than the Windows Biometric Framework.

In step1shown inFIG. 6A, application270requests that each of the Morpho devices connected to the server be enumerated. Although not shown, application270will first call InitUsbDevicesNameEnum to obtain the total number of connected Morpho devices. With this number, application270can then iteratively call GetUsbDevicesNameEnum for each Morpho device as is represented in step1. In particular, the GetUsbDevicesNameEnum takes as input an index parameter that has a value between 0 and the number returned from the call to InitUsbDevicesNameEnum.

Each time application270calls GetUsbDevicesNameEnum, hooking component450can allow the call to proceed in a typical manner to biometric service170awhich will employ the specified index parameter to retrieve the serial number of the Morpho device defined by that index. Accordingly, in step2depicted inFIG. 6B, biometric service170ais shown as providing a response that includes the serial number SN1 which hooking component450will intercept in step3.

In step4shown inFIG. 6C, hooking component450sends the serial number to filter driver401, and in step5, filter driver employs the serial number to retrieve the mapped session ID from mappings401b. In this example, because the serial number is SN1, filter driver401will retrieve SessionID25.

In step6shown inFIG. 6D, filter driver401returns the session ID to hooking component450which then, in step7, compares the session ID to the session ID of the session in which it is executing. In this example, it is assumed that hooking component450(and therefore application270) is executing within sessionID13 and therefore, hooking component450will determine that the biometric device having a serial number of SN1 is not redirected to the current session.

In step8shown inFIG. 6E, because the session ID returned by filter driver401does not match the current session's ID, hooking component450will remove the serial number from the GetUsbDevicesNameEnum response. This removal may entail deleting the o_pc_MsoName and o_pc_MsoProperties strings from the response or modifying the response in any other way that prevents application270from obtaining the serial number (e.g., by causing it to return an error). Finally, in step9, hooking component450will allow the response to proceed to application270.

As indicated above, application270will call GetUsbDevicesNameEnum a number of times equal to the number of Morpho devices that are connected to the server as reported in the response to InitUsbDevicesNameEnum. Therefore, steps1-9will be repeated for each connected Morpho device. Because of step8, the response provided to application270will only include the serial number of a Morpho device if that Morpho device is currently redirected to the same session in which the application is executing thereby preventing the application from discovering Morpho devices that are redirected to other user sessions. For example, when the GetUsbDevicesNameEnum response includes SN2 (which in this example would presumably occur on the second call to the function), filter driver401would return SessionID13 which matches the current session ID. Hooking component450would therefore leave the response unmodified in step8thereby allowing application270to discover the Morpho device with a serial number of SN2 since this Morpho device is currently being redirected to the same session in which application270is executing.

FIG. 8provides a flowchart summarizing the process that filter driver401may perform during the enumeration of biometric devices. This flowchart would generally encompass steps5and6in each of the examples provided above.

In summary, hooking component450can hook the appropriate APIs of biometric library170bto allow it to inspect and modify an application's attempt to enumerate connected biometric devices. During an attempt to enumerate biometric devices, hooking component450can employ an identifier of an enumerated device to query filter driver401for the session ID of the user session to which the enumerated device is redirected. Only if the returned session ID matches the current session will hooking component450allow the identifier to be returned to the requesting application.

FIG. 9provides a flowchart of an example method900for isolating a redirected biometric device to a remote session. Method900can be implemented by hooking component450and filter driver401.

Method900includes an act901of, in response to an application that is executing in a user session requesting enumeration of biometric devices that are connected to the server, intercepting, by a hooking component, an enumeration response that includes an identifier of a biometric device. For example, hooking component450could intercept a response to an application's call to the WinBioEnumBiometricUnits function of the Windows Biometric Framework or the GetUsbDevicesNameEnum function of the Morph® Smart SDK.

Method900includes an act902of extracting the identifier of the biometric device from the enumeration response and sending the identifier to a filter driver. For example, hooking component450could extract a device instance ID or a serial number from the intercepted response and send the device instance ID or serial number to filter driver401.

Method900includes an act903of employing, by the filter driver, the identifier of the biometric device to obtain a session ID of a user session to which the biometric device is redirected and returning the session ID to the hooking component. For example, filter driver401could access mappings401aor401bto obtain a session ID to which the device instance ID or serial number was mapped.

Method900includes an act904of comparing, by the hooking component, the session ID received from the filter driver to a session ID of the user session in which the application is executing such that, when the hooking component determines that the session ID received from the filter driver does not match the session ID of the user session in which the application is executing, the hooking component removes the identifier of the biometric device from the enumeration response prior to allowing the enumeration response to be provided to the application. For example, hooking component450can remove the device instance ID or serial number from the enumeration response whenever the mapped session ID does not match the session ID of the user session in which the hooking component is executing.