|
IMPRIVATA OneSign
| IMPRIVATA OneSign - Flash Demo
|
IMPRIVATA OneSign - How it is working. |
| |
|
|
|
OneSign consists of two main components, the appliance with the web-interface for administration and the OneSign Agent installed on the client for executing the automatic authentication locally.
The appliance can be used with the most important directories like Microsofts Active Directory 2000 / 2003 Server, NT 4.0 Domain, Sun ONE Directory Server 5.0, Oracle Internet Directory 10g and many more. Thus importing the user is easy, a simple synchronisation and all Users are available in the OneSign Administration. The training of the application dialogs, which have to be known to the OneSign Agent, is done with the comfortable Application Profile Generator (APG). Using policies it is determined, how a user is authenticated, the possible options are password, smart card, fingerprint-sensor or ID-Token. Because of the support of kerberos communication with Microsoft Domain Controller the primary logon can be realised in many ways (considering Standard Windows Smart Card Logon)
|
|
|
|
|
|
Erweiterte Windows-GINA mit Authentifizierung an OneSign |
Für die Anmeldung via Smart Card ist keine erweiterte GINA notwendig. Vorbedingung ist eine vorhandene PKI und Kerberos |
Anmeldung via Fingerprint-Sensor (z.b. AET 60 ). Vor der ersten Anmeldung, muss OneSign den Fingerabdruck des Anwenders erlernen |
|
 |
 |
 |
 |
 |
|
|
Learned applications are deployed automatically to the agents initiated by the agents (intervall-based and each user logon) and are fit for service immediately. At first time the user is logs onto the application as always. But the credentals are stored by the agent and the next logon everything is done by the agent. If the user has to change the password or it has been forgotten, the agent is recognizing password changes and initiates necessary password resets. If one user quits the company, he can be disabled by the administrator centrally, there is no possibility for him to be authenticated automatically.
|
|
|
|
|
Definition of the authentication policies, there you can define, how the user is authenticated |
Administration of the user. There the administrator has the possibility to edit the user or create new user accounts. Of course a synchronisation with a directory is possible. |
|
 |
 |
 |
 |
 |
|
How applications are learned |
The comfortable Application Profile Generator (APG) allows to train the login-screens with drag and drop. Intelligent recognition algorithms identify the criteria of the login screens of classic windows applicationsn, websites, terminal applications, Java-Applikations or legacy applications. Additional APG is offering many options for fine-tuning or keyboard simulation. Learned profiles are deployed for the users by the agents.
|
|
|
|
|
|
Learned applications, which can be deployed to the users. |
Define the screens of the applications to be learned - also a change password dialog can be recognized, if the user wants to change his password. |
Each login screen consists of several characteristics in URL, fields, text, and so on. With this characteristics the login screen is recognised, the APG detects this characteristics itself, but manual fine-tuning is possible. |
|
 |
 |
 |
 |
 |
|
|
|
|
|
|
|