IWS CloudID® is a highly modular, software platform that enabled rapid development and deployment of highly secure, yet flexible biometric identity management solutions.
IWS CloudID® is easily incorporated into new or existing cloud-enabled environments or integrated as cloud-ready software into traditional networked client server and data center IT infrastructures.
- Virtually any biometric modality and algorithm from any vendor can be quickly incorporated into the system.
- The system can be easily scaled to satisfy the requirements of small organizations or entire counties, providing ultra-scalable real-time solutions.
IWS CloudID® Server Platform
IWS CloudID server platform consists of a set of configurable, server-based cloud identity management software modules designed to add or enhance biometric identity management and credential issuance capabilities to existing applications or support the development of these capabilities in new end-to-end applications.
IWS’ CloudID server platform consists of the
- IWS Biometric Engine®
- Doc Server
- Credential Management Server
- EBTS Server
- Analytics Server
With the exception of IWS’ Biometric Engine, each server module operates independently and can be replaced by or integrated with other third party or custom servers.
IWS Biometric Engine
IWS Biometric Engine is a real-time (no copying of templates), high-performance, scalable, clusterable, biometric database. It is biometric algorithm agnostic (supports 70+ and growing) and hardware/software scalable to support large populations and multiple modalities.
- Supports multiple biometric modalities
- Supports multiple biometric algorithms
- Real-time high performance biometric template cache
- Supports multiple biometric query types including 1:1: verification, 1:N identification, X:N watch list, N:N duplicity checking and optional meta-data filtering
- Supports biometric fusion (combining of multiple biometric modality scores into a single score)
- Supports SOA interfaces for easy integration with ESB’s, thin, fat and mobile applications
- Query Router / Query Engine interface
- Supports distribution of biometrics, matching across multiple machines (both physical and virtual), and computing processors via the Query Router/Query Engine that is scalable to populations in the hundreds of millions
- Supports data striping and mirroring for optimized distribution of template cache and processing
- Runs on Windows Server operating systems with plans for porting to Linux
- Support for Anonymous Biometric Identity Management (patents pending)
- Persistent data management for backup and restore
- It’s the Oracle® of biometrics
In terms of the GoCloudID stack, a document is any binary object that needs to be stored and managed:
- Images from biometric captures (face, finger, iris, etc.)
- Image scans from document scanners (passport, driver’s license, etc.)
- Binary documents used in the management of identity information (EBTS transactions, data structures, etc.)
Document management server stores and manages binary documents, associates meta-data with them for rapid search, retrieval, and runs on Windows Server and Linux operating systems. The document management server uses a SQL RDBMS (same as IDMS) to store and retrieve binary documents.
Meta-Data and Documents
Meta-data (name-value pairs) are used to identify each document for later retrieval. Examples of meta-data associated with a document:
- Biometric modality (left index finger, face, right iris, etc.)
- Document type (driver’s license, passport, EBTS transaction, etc.)
- Identity association (unique person identifier)
Meta-data provides flexibility in storing, managing, and retrieving binary objects (documents) from the server.
Replacing the Document Management Server
In the instances where a project has an existing document server we can work with an existing document management solution on the GoCloudID server stack to build custom business service layers (BSL). This allows for the integration of the document management with the other components of the GoCloudID server stack.
Credential Management Server
In terms of the IWS CloudID® stack, a credential is any card, badge, or document used as a factor in verifying an identity. Card Management Server creates, encodes (in the case of smart cards), and manages the lifecycle of credentials by using a SQL RDBMS (same as IDMS) to manage all credential information.
Card Management Server integrates with other CloudID Server products including:
- Biometric Engine, Identity Management Server, Document Management Server, IWS PrintServer
- Multiple credentials can be associated with a single identity
The IWS Credential Manager
- Runs on Windows Server and Linux operating systems
- Integrates with Physical Access Control Systems (PACS)
- Works with Print Server print and encode credentials, using the EPI Builder and EPI Designer for card layouts, printing, and encoding
- Uses a RDBMS to store and manage credential/lifecycle data
- Manages card lifecycle
- Print, encode, validate, activate, deactivate
- Manages participation in lists (white list, black list, etc.)
Integration with IWS Print Server
- Print Server is an add-on to IWS Card Management Server
- Runs only on Windows Server operating systems
- Works with multiple card servers to print larger volumes of credentials
- Highly recommended to sell Print Server only with Card Management Server
- Uses EPI Builder to:
- Support multiple card layouts created by EPI Designer (DGN’s)
- Abstract card printer interfaces
- Encode smart cards (HSPD-12/PIV/TWIC, Mifare, iClass, etc.)
- Print credentials with Card Management Server using Print Server
IWS Card Management Server in the CMS Market
- Card Management Server is an integral part of the IWS CloudID server stack
- It is designed to be open, configurable, and extensible, which gives it an advantage over our competitors
Replacing the Card Management Server
When we need to integrate with a project that has an existing CMS in place, we can work with the existing document management solution on the IWS CloudID server stack by building a custom business service layer (BSL) to manage the integration of the CMS with the other components of the IWS CloudID server stack.
Electronic Biometric Transmission Specification Server (EBTS)
It was the descendant of EFTS (fingerprint); created by the FBI to accept AFIS requests and enrollments. Unlike EFTS, which only supports fingerprints, EBTS supports multiple biometric types.
It’s not an identity management system on its own. It is a gateway for identity management data to go from inactive (file based) to active (searchable and manageable) and it integrates with external services via custom workflow. There’s nothing else like it.
- Types of EBTS Transactions
- Transactions can be of different types, as defined by the agency or community that accepts and works with them.
- Each agency has their own set of ToT’s and each one has a purpose.
- An EBTS type of transaction (ToT) is a definition of the data and purpose of a given transaction definition
- Data in a ToT are defined as records:
- Each record has a specific purpose and type of data that it contains (biographic, iris, face, fingerprint, etc.)
- The types and number of records define the total structure of the EBTS transaction
Transaction Record Type Examples
- Type 1: Transaction Information
- Type 2: Biographic data (agency defined name-values)
- Type 6: HighRes binary fingerprint image
- Type 8: Signature data
- Type 10: Facial and SMT image
- Type 15: Variable resolution palm-print image
- Type 17: Iris image
- Type 99: CBEFF/M1 biometric data record (catch-all)
- The EBTS server is part of the GoCloudID® server stack
- Stores and Manages EBTS transactions
- Enrolls identity information from EBTS transactions into the GoCloudID Server stack
- Identity data is enrolled into IWS Identity Management Server
- Biometrics are enrolled in IWS Biometric Engine
- Biometric images are saved in IWS Document Management Server
- Works with all EBTS ToT’s using OpenEBTS (part of the Open Biometrics Initiative)
- Manages sending and receiving EBTS transactions to external agency services (AFIS, background check, etc.) with a custom workflow for processing and tracking EBTS transactions and responses
- Runs on Windows Server operating systems
Problem with most EBTS
Each agency/community can and does define their own ToT’s without a lot of overlap in the biographic data record definitions (type 2). EBTS transactions are files, and contain data/images, which are great for capturing and sharing identity information, but not appropriate for true identity management (it’s not a database).
Biometric Management Engine
Biographic identity relates to data that represents an identity. This is data that is usually intrinsic to the identity and typically contains text, numbers, dates, etc. A common example is first/middle/last names, addresses, birthdate, etc. Biographic identity management relates to the management of biographic data.
In IWS CloudID®, biographic data is separated from biometric data and stored in the IWS Identity Management Server (IDMS). The IWS Identity Management Server manages all biographic identity information in the CloudID server stack. It runs on Windows Server and Linux operating systems and uses a relational database for storing, retrieving, and managing all biographic data. This allows IWS to separate biometric data from biographic data.
- Needs real-time, optimized storage
- Matches take place against the actual data, not a copy
- Supports the use of different biometric matching algorithms
- Biographic data:
- Needs optimized storage and retrieval of text, date and numeric data
- Needs the ability to store and manage data elements defined specific to a project
- Biographic data is text, numbers, dates, etc. It is perfect for traditional, relational databases (RDBMS)
- Fast indexing, fast retrieval, clustered processing, etc.
- Elements vary based on the project requirements
How IDMS supports Biographic Data
- IDMS supports standard data elements (name, address, birthdate, etc.)
- IDMS supports several RDBMS’ including Microsoft® SQL Server, Oracle® Database and MySQL
- IDMS supports variable data through the use of meta-data
- Uses meta-data as data elements that make up the identity itself
- Most biographic data elements are common to all identity definitions
- Meta-data fills the gap by providing variable data element definitions that make up the biographic identity data
- In the database, Meta data is implemented as name-value pairs, which are data elements that are stored in the database in a non-structured way and can store any type of data necessary
- In standard, relational database theory, data elements are broken down in to named columns inside of a logical construct called a table.
- Data can be related to each other in 1-to-many relationships with each 1-to-many relationship stored in a table and defined as related. E.g.: each identity can have multiple aliases, addresses, etc.
- We can’t think of all of the data that will need to be stored and associated with an identity
- We use meta-data to implement the storage and management of data elements that are specific to an identity management system implementation
- Meta-data is implemented as name-value pairs. Name-value pairs are data elements that are stored in the database in a non-structured way, and can store any type of data necessary. The data is stored in a native data type (text, number, date, etc.) and a unique name is used as an identifier (similar to a column name)
Meta-Data in IDMS
- Extends the capabilities of the IDMS to store data that is not standard in the IDMS database
- Not the same as meta-data in Biometric Engine. In the Biometric Engine, meta-data is an index filter that is associated with a template. In IDMS, meta-data are unique data elements that are associated with specific identities and can be used to search and filter
Replacing a Project’s Existing IDMS
Sometimes a project has an existing IDMS in use, such as:
- Oracle IDMS
- Microsoft IDMS
- Custom built IDMS
- Relate biometric data with biographic data using unique person identifiers (PersonID)
- Build custom business service layer (BSL) to manage the integration of the biographic component(s) with the Biometric Engine
- We can work with 3rd party IDMS’ on the CloudID stack