Windows Biometric Framework core platform
This topic describes the Windows Biometric Framework (WBF) core platform.
This information applies to the following operating system:
- Windows 7
The WBF core platform consists of the following components:
- Windows Biometric Driver Interface (WBDI)
- Windows Biometric Service (WBS)
- WBF API
The following figure shows these components and their relationship to each other.
Windows Biometric Driver Interface (WBDI)
WBDI provides a common interface that biometric drivers use to expose the device through WBS. WBS exposes all Plug and Play devices that implement WBDI. This lets any user-mode application access biometric device through the WBF API.
WBDI drivers can be implemented by using any driver technology that the Windows operating system supports, including the following:
- User-mode driver framework (UMDF).
- Kernel-mode driver framework (KMDF).
- Windows Driver Model (WDM).
Note To improve overall driver quality and system stability, we recommend that driver writers use the UMDF driver model whenever possible.
For more information about these driver technologies, see the Related topics section in Introduction to the Windows Biometric Framework.
WBDI drivers must do the following:
- Support the WBDI driver interface GUID.
- Support all mandatory WBDI I/O controls (IOCTLs), including handling multiple IOCTL requests and supporting IOCTL cancellation.
Driver developers should review the documentation and sample WBDI driver code in the Windows 7 Windows Driver Kit (WDK). Developers should also use the following WDK tools to verify their drivers:
- PREfast for Drivers
- WDF Verifier
- Application Verifier
- WBF tools, including the WBDI driver test harness (WBDIDriverTest.exe)
For more information about these tools, see the documentation in the Windows 7 WDK.
Windows Biometric Service (WBS)
WBS is a component that manages fingerprint biometric devices through WBDI drivers that are installed on the system. WBS supports the WBF API, which provides managed access to these devices through client applications.
WBS protects user confidentiality by maintaining a strict separation between client applications and biometric data. Specifically, WBS acts as an I/O proxy between the application and the biometric device, and performs all capture, processing, and storage operations on the device.
The WBS never gives unprivileged client applications direct access to biometric samples or templates. Instead, WBS associates a handle, such as a security identifier (SID) or a GUID, with the biometric data. Applications use this handle to indirectly access the biometric data or template.
Within WBS, fingerprint biometric devices are managed by a component that is named the Biometric Service Provider (BSP). BSP implements all policies or behaviors that are specific to the device’s biometric category.
Note In Windows 7, devices that sample fingerprints are the only supported biometric category, and Microsoft supplies the BSP for this type of device.
Another feature of WBS is that it normalizes biometric hardware behavior. Therefore, all fingerprint biometric devices behave more or less the same to client applications, regardless of the device’s physical capabilities.
WBS does this by creating a virtual software component, which is known as a biometric unit (BU), for each biometric device. BU is an idealized version of the device that can perform capture, processing, and storage functions.
If the physical device lacks on-board processing or storage capabilities, this functionality is supplied by plug-in components that are called BU adapters. Regardless of the capabilities of the biometric device, its associated BU and BU adapters always provide a common behavioral interface to BSP.
WBS manages all BUs by grouping them together in pools. WBS maintains the following three pools:
- System: The system pool contains shareable BUs that provide easy access to Windows-based authentication services. The system pool is used for logon, UAC, and any other client that wants to associate Windows account SIDs with a user’s biometric template. Each BSP on the system has exactly one system pool.
- Private: The private group contains one or more BUs that is allocated for exclusive use by an application program. The private pool makes it possible to support applications that perform authentication that is not Windows based. There can be as many private pools on the system as there are BUs.
- Unassigned: The unassigned group contains BUs that do not belong to either the system or private pool. Unlike the other BU pools, the unassigned pool can be empty.
A BU is made up of the following three pluggable BU adapter components:
- Sensor adapter: The sensor adapter performs all sample-capture operations.
- Engine adapter: The engine adapter performs all processing including data normalization, feature extraction, and biometric template generation. Also, the engine adapter matches biometric data to templates during enrollment, identification, and verification operations.
- Storage adapter: The storage adapter stores, manages, and retrieves all templates.
The following figure shows the relationship between the BSP, BUs, and the various BU adapters.
In Windows 7, BU adapter components are provided in the following way:
- For fingerprint biometric devices that do not have on-chip storage or matching capabilities, Microsoft provides inbox sensor and storage adapters components. An IHV or ISV must supply the engine adapter component for these devices.
- For fingerprint biometric devices that do support on-chip matching and storage, the IHV or ISV must supply all BU adapter components.
Driver developers who want to write BU adapter components for WBF should see the documentation and sample WBDI driver code in the Windows 7Windows Driver Kit (WDK).
WBS exposes fingerprint biometric devices through the WBF API. This API lets applications enroll, identify, and verify user identities. In addition, the WBF API provides:
- Query of the biometric device capabilities.
- Biometric device location.
- Session management.
- Event monitors.
- Biometric template storage.
The WBF API also provides an extension API that can be used to access proprietary device-specific capabilities.
Developers who want to write applications that use the WBF API should see the documentation in the Microsoft Windows Software Development Kit (SDK) for Windows 7 and .NET Framework 4.0.