OneSpan Authentication Server data model

OneSpan Authentication Server uses an ODBC-compliant database as its data store. The following topics describe the types of records stored in the OneSpan Authentication Server data store.

Authenticator records

An authenticator record must exist in the data store for each authenticator in use. This record type contains:

  • Information about the authenticator, i.e. serial number and model
  • The names and programming parameters of authenticator applications
  • The status of various options, i.e. authenticator lock

Some of the information in this record is encrypted and stored together in the so-called authenticator BLOB. There is one BLOB per authenticator application. Each time a one-time password (OTP) is used (whether or not the authentication is successful), OneSpan Authentication Server updates the BLOB to prevent the OTP from being reused.

User account records

Each user logging in via authenticators will require a user account. The user account record contains information needed by OneSpan Authentication Server (i.e. authentication settings). An authenticator must be assigned to a user account before it can be used for authentication.

In addition, administrative privileges are assigned to user accounts. As such, each administrator also needs a user account.

Client component records

Clients are machines, which connect to OneSpan Authentication Server and send authentication or administration requests. Clients might be end-user machines, servers hosting web services, RADIUS clients, or IIS modules.

Client component records are created to represent:

  • OneSpan Authentication Server instances
  • Authentication, signature validation, and provisioning clients
  • Administration clients

A client record must exist in the OneSpan Authentication Server data store for any machines that will make authentication requests to OneSpan Authentication Server. OneSpan Authentication Server uses client records to determine, which requests from which clients can be processed. Client records also specify, which policy should be used when processing requests (see Policy records).

Client records are also used to store the following:

  • Shared secrets and character encoding for RADIUS clients.
  • License keys for OneSpan Authentication Server instances and DIGIPASS Authentication Module components.

Policy records

A policy specifies various settings that affect how requests, e.g. authentication or administration requests, are processed. Each request is handled according to a policy that is identified by the applicable component record.

Examples of policy settings include:

  • Whether local authentication and/or back-end authentication should be used.
  • Whether various automatic management features should be used
  • The required authenticator application types.
  • Settings for backup Virtual Mobile Authenticator

Back-end server records

A back-end server is a server, e.g. a RADIUS or LDAP server, that may be used by OneSpan Authentication Server for back-end authentication, i.e. authentication done by another system as well as OneSpan Authentication Server.

Each back-end server available must have a record defined in OneSpan Authentication Server. It is possible to create more than one back-end server record for fail-over purposes. You can also allocate different back-end servers for different user domains.

Domain records

Domains are the base for the organizational structure in an ODBC database.

They serve the following purposes:

  • Allow different user groups to be separated.
  • Provide the ability to limit administrator activities to the administrator's own domain (delegated administration).
  • Allocate unassigned authenticator records to different domains, e.g. to mirror the geographic location of the devices.

Each authenticator user and authenticator must belong to a domain. One domain is identified as the master domain– this will be the default domain when none is specified. In addition, administrators in the master domain can be given rights to access data in all other domains, while other administrators are limited to data in their own domain.

User IDs must be unique within a domain, but may be repeated between domains. Authenticator serial numbers must be unique in the database.

Organizational unit records

Organizational units allow further compartmentalization of user accounts, authenticator records, and administration duties. Organizational units are included to:

  • Limit the activities of administrators to their own organizational unit (i.e. delegated administration).
  • Allocate unassigned authenticators to different organizational units, e.g. to mirror the geographic location of the devices.

The user account and authenticator records may belong to an organizational unit, but this is not mandatory.