User's Manual

28
8 Integration
This chapter describes how to integrate the WebOTP device into an authentication service.
8.1 Integration into a web service
WebOTP has been designed for making the use of a web service as user-friendly as possible. Both in case a new
authentication service is to be created and in case such a service is to be integrated into an existing one.
The integration of the WebOTP authentication service into a web service requires the following activities:
• Definition of the new authentication system.
• Integration of the SDK into the server application and the user database.
•
Adaptation of the client part for reception and transmission of authentication codes.
8.1.1 Authentication system
According to one's needs and the possible already-existing authentication system different operating scenarios can be
foreseen.
The most common scenario is using WebOTP both for identifying the user and for authenticating him/her, adding the
request for a PIN as second authentication factor in order to protect oneself against any possible theft of the device. In
case an identification system via userid and password is already present it is possible to add WebOTP as second
authentication factor.
After completing authentication it is possible to use the application server session management for enabling the user to
surf the reserved pages.
It is also possible to require a further insertion of the WebOTP device as a confirmation of operations that are regarded
as especially important. The request for a manual operation by the user enables a greater control on transactions,
preventing any possible malware present in the user’s system from carrying out an arbitrary number of fraudulent
operations.
8.1.2 Server
At the server level it is necessary to integrate the use of the SDK for checking the authentication information and for
modifying the database containing the user’s information in order to add the authentication Blob, the device serial
number and the possible PIN as second authentication factor.
During the SDK initialization and operation it will be necessary to provide the server-key and the blob-key. It is
particularly important to keep in mind where such keys are stored. It is essential that the applications that use them are
carried out within a protected environment. In those cases in which security is an especially critical factor, all
authentication operations should be carried out via remote on a special server residing in a highly secure environment.
The information necessary for the SDK for carrying out the authentication is the Blob and the serial number of the
device. Such information must be stored into a user database. In case such a database already exists, just add the
relevant fields. It is to be noticed that the database does not require special security expedients as the information
contained in the Blob are always encrypted via the blob-key.
During the authentication process of the time-based devices it is necessary to provide the correct time. If the clock in
use is not correct the authentication of the time-base devices might fail. If the system clock is used use an NTP client for
maintaining and synchronizing it with a public timer server.
In the W
INDOWS
environment it is possible to use the W32T
IME
service for keeping the system clock updated. Please
refer to the M
ICROSOFT
documentation for further details on the service configuration, in particular the Knowledge
Base:
•
How to configure an authoritative time server in Windows 2000
-
http://support.microsoft.com/kb/216734
•
How to configure an authoritative time server in Windows XP - http://support.microsoft.com/kb/314054
• How to configure an authoritative time server in Windows 2003 - http://support.microsoft.com/kb/816042
Within a U
NIX
environment it is possible to use a periodically executed NTP client or to install an NTP demon. An
O
PEN
S
OURCE
implementation of both is available on the website http://www.ntp.org