Authentication process

The following is an explanation of the order of events that occur during authentication.

  1. A remote application initiates a synchronization request using a remote ID, a MobiLink user name, and optionally a password and new password. The MobiLink server starts a new transaction and triggers the begin_connection_autocommit event and begin_connection event.

  2. MobiLink verifies that the remote ID is not currently synchronizing and presets the authentication_status to be 4000.

  3. If you have defined an authenticate_user script, then the following occurs:

    1. If the authenticate_user script is written in SQL, then this script is called with the preset authentication_status of 4000, the MobiLink user name you provided, and optionally the password and new password.

      If the authenticate_user script is written in Java or .NET and returns a SQL statement, then this SQL statement is called with the preset authentication_status of 4000, the MobiLink user name you provided, and optionally the password and new password.

    2. If the authenticate_user script throws an exception or an error occurs in executing the script, the synchronization process stops.

    The authenticate_user script or the returned SQL statement must be a call to a stored procedure taking two to four arguments. The preset authentication_status value is passed as the first parameter and may be updated by the stored procedure. The returned value of the first parameter is the authentication_status from the authenticate_user script.

  4. If an authenticate_user_hashed script exists, then the following occurs:

    1. If a password was provided, a hashed value is calculated for it. If a new password was provided, a hashed value is calculated for it.

    2. The authenticate_user_hashed script is called with the current value of authentication_status (either the preset authentication_status if the authenticate_user script doesn't exist, or the authentication_status returned from the authenticate_user script) and the hashed passwords. The behavior is identical to step 3. The returned value of the first parameter is used as the authentication_status of the authenticate_user_hashed script.

  5. The MobiLink server takes the greater value of the auth_user status returned from the authenticate_user script and authenticate_user_hashed script, if they exist, or the preset authentication_status if neither of the scripts exist.

  6. The MobiLink server queries the ml_user table for the MobiLink user name you provided.

    1. If either of the custom scripts authenticate_user or authenticate_user_hashed was called but the MobiLink user name you provided is not in the ml_user table and the authentication_status is valid (1000 or 2000), the MobiLink user name is added to the MobiLink system table ml_user. If authentication_status is not valid, ml_user is not updated and an error occurs.

    2. If the custom scripts were not called and the MobiLink user name you provided is not in the ml_user table, the MobiLink user name you provided is added to ml_user if you started the MobiLink server with the -zu+ option. Otherwise, an error occurs and authentication_status is set to be invalid.

    3. If the custom scripts were called and the MobiLink user name you provided is in the ml_user table, nothing happens.

    4. If the custom scripts were not called and the MobiLink user name you provided is in the ml_user table, the password is checked against the value in the ml_user table. If the password matches the one in the ml_user table for the MobiLink user, the authentication_status is set to be valid. Otherwise the authentication_status is set to be invalid.

  7. If that authentication_status is valid and neither of the scripts authenticate_user or authenticate_user_hashed was called and you provided a new password in the ml_user table for this MobiLink user, the password is changed to the one you provided.

  8. If you have defined an authenticate_parameters script and the authentication_status is valid (1000 or 2000), then the following occurs:

    1. The parameters are passed to the authenticate_parameters script.

    2. If the authenticate_parameters script returns an authentication_status value greater than the current authentication_status, the new authentication_status overwrites the old value.

  9. If authentication_status is not valid, the synchronization is aborted.

  10. If you have defined the modify_user script, it is called to replace the MobiLink user name you provided with a new MobiLink user name returned by this script.

  11. The MobiLink server always commits the transaction after MobiLink user authentication, regardless of the authentication_status. If the authentication_status is valid (1000 or 2000), synchronization continues. If the authentication_status is invalid, the synchronization is aborted.

Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1