Contents Index Changing passwords File-Based Downloads

MobiLink Synchronization User's Guide
  Authenticating MobiLink Users

Custom user authentication


You can choose to use a user authentication mechanism other than the built-in MobiLink mechanism. Reasons for using a custom user authentication mechanism include integration with existing DBMS user authentication schemes, or supplying custom features, such as minimum password length or password expiry, that do not exist in the built-in MobiLink mechanism.

There are three custom authentication tools:

The dbmlsrv9 -zu option allows you to control the automatic addition of users. For example, specify -zu+ to have all unrecognized MobiLink user names added to the ml_user table when they first synchronize. The -zu option works with built-in MobiLink authorization.

The authenticate_user script and authenticate_parameters script both override the default MobiLink user authentication mechanism. Use authenticate_user to create custom authentication of user IDs and passwords. Use authenticate_parameters to create custom authentication that depends on values other than user IDs and passwords.

For more information, see

Java and .NET user authentication 

User authentication is a natural use of Java and .NET synchronization logic, as Java and .NET classes allow you to reach out to other sources of user names and passwords used in your computing environment, such as application servers.

A simple sample is included in the directory Samples\MobiLink\JavaAuthentication. The sample code in Samples\MobiLink\JavaAuthentication\CustEmpScripts.java implements a simple user authentication system. On the first synchronization, a MobiLink user name is added to the login_added table. On subsequent synchronizations, a row is added to the login_audit table. In this sample, there is no test before adding a user ID to the login_added table.

For a .NET sample that explains user authentication, see .NET synchronization example.

SQL user authentication 

A typical authenticate_user SQL script would be a call to a stored procedure that uses the parameters. The order of the parameters in the call must match the order above. For example, in an Adaptive Server Anywhere consolidated database, the format would be as follows:

call my_authentication( ?, ?, ?, ? )

where the first argument is the error code, and so on. The error code is an integer type, and the other parameters are VARCHAR(128).

A Transact-SQL format would be as follows:

execute ? = my_authentication( ?, ?, ? )

where the error code is the parameter on the left hand side.


Contents Index Changing passwords File-Based Downloads