Escolar Documentos
Profissional Documentos
Cultura Documentos
DEMO Apps
(Functionality Issues)
Copyright
For internal use only Supervisor: NI TEKNA Macedonia Darko Kulakov EMail: darko.kulakov@ni-tekna.com Status: Project: progress Id: BioPass (NeuroPass)
Signa ture:
Author: Dept.: NI TEKNA Macedonia Name: Goce Bajatov EMail: goce.bajatov@ni-tekna.com File: Date:
Demo_Apps_Functionality.doc
26.Apr.2012
Page 1/9
Project documentation
Project task
To define the functionality of the DEMO Apps for the NeuroPass product, especially concerning the enrollment of existing and new users in the system. When we started to implement the Add User functionality to the admin panel for the BioPass (NeuroPass) server we encountered a problem that has to be resolved. In the following text we will try to explain the possible cases for client applications and how the currently developed demo applications function.
Contents
Change log..............................................................................................................3 1 Possible Client Server cases..................................................................................4 2 Active Demo with client database and user validation................................................4 3 Passive mode without client database system...........................................................7 4 Additional problems and points that need to be discussed..........................................8
Page 2/9
Project documentation
Change log
Version 1.0 Author(s) Goce Bajatov Version description Draft Version Date 26.Apr.2012
Page 3/9
Project documentation
Mode
1 Active mode with client user Database system
Description
Application that uses Active authentication mode from BioPass, and uses a database for user storage and validation on Client side Application that uses active authentication mode from BioPass server and does not have a client side database system for user and validation. Application that uses passive authentication mode and have a client side database that stores users and performs client side validation Application that uses passive authentication mode and doesnt have client database for user persistence and does not perform client side validation.
Dem o
YES
Active mode without client database system Passive mode with client database system Passive mode without client database system
YES
validation
The following diagram depicts a basic application with active mode and a client database system.
Page 4/9
Project documentation
Page 5/9
Project documentation d. If answer is OK then an entry is made to a users table different from the asp.net membership table that stores the BioPass server id, and may hold additional data like Client application settings etc. Then a Registration success message is displayed and the user can proceed with login. e. In case the answer from the BioPass server is ERROR the procedure is rolled back.
2.2 Login
The login process is described as follows. 1. The login page is displayed and the user enters its username and password. 2. The Client Application performs validation against the ASP.NET membership provider for a valid account. If Validation is success then the user validation process proceeds to the next step, otherwise the login fails. 3. The Client application gets the BioPass id for the current user from its database (Client Database) and with the collected data; it creates a login request to the BioPass server which contains user id and biometric data. And waits for response. 4. If response is OK and the Login value from the response is Success (1) then the application performs its additional logic to complete the login process and grant access to the protected portions of the application. 5. If the response form the BioPass server is Fail (0), the login process does not finish and the user is not logged in.
In case there is no response from the BioPass server the user is not logged in.
2.3 Problems with client applications that user dual user data storage and validation system.
There are two possibilities when administrating two different applications: 1. The administrator from the Client Application is the same person as the administrator from the server application ( or the administrator has ACCESS to the administrating panel to both applications) 2. The administrator from the Client Application is NOT the same person as the administrator from the server application (or the administrator of the client application has NO ACCESS to the server application administration panel) All applications that use application that contain dual database that store connected data, most common problem is consistency between the data is the two databases. This occurs when:
2012, Neurologix Development LLC Page 6/9
Project documentation 1. BioPass Administrator adds users in The BioPass server. 2. BioPass Administrator deletes users in the BioPass server. 3. Client Application administrator adds users to the Client Application 4. Client Application administrator deletes users from the Client Application 5. Other similar operations that may require deletion or adding of data to each database. When the BioPass admin adds an user in the BioPass database through the BioPass server admin panel the same user information is not added in the Client Application Database, thus the login process will fail because the user cannot be validated in the client Membership in the client application (step 2 from the login validation process) and the login process will not continue. The same inconsistency appears when the BioPass admin deletes a user from the BioPass server Admin panel , the data for the user no longer exist in the BioPass database and the login process will fail in biopass validation of the login process ( step 4 from the login validation process). When user is added trough the Administration panel from the Client application it also MUST contain additional logic that will create the same user on the BioPass Server. When user is deleted from the client application additional logic MUST be implemented to remove the user form the BioPass Server as well.
Project documentation 1. The register from is displayed to the user and it is filled out accordingly with valid data. 2. Collected data from the user register form is consolidated and a request is created to the BioPass server containing username, password. Waiting for BioPass server response. 3. If the result from the request is OK and the additional data from the response represents a valid number larger than 0 the registration success page is displayed, and the user can proceed with login to the application. 4. If the result is ERROR the Registration failed message appears.
3.2 Login
1. The login form is displayed to the user, and it is filled out correctly. The user clicks on the login button. 2. From the collected biometric data and the values for username and password a request to the BioPass Server is made and the client application is waiting for response 3. If the response from the BioPass server is OK and the additional data parameter is 1 then the validation is successful and the Client application continues to complete its user login process. If the additional data parameter is different than the above mentioned value the login is considered as failed and the user is not logged in. In case the BioPass does not respond the login process fails and the user is not logged in.
discussed
1. What data should be sent to the BioPass server for user enrollment and login in Active and passive mode. 2. How should the user be added from the BioPass administration panel, should the administrator enter the user password? 3. What happens when the user forgets its password or wants to change it. 4. Additionally if the client application that need to implement BioPass server security already have several thousand users, how the user enrollment process will be handled in both active and passive enrollment.
Page 8/9
Project documentation
Page 9/9