SecureLogin supports the use of four different types of variables:
NOTE:Specify variables without spaces, for example $Username_Alias. If you use spaces you must enclose the entire variable in quotation marks, for example "$Username Alias".
This section contains the following information:
Each variable defaults to the platform specified in the Application Definition/Predefined Application name. You can use a variable to change the platform, for example you may have an Application Definition named www.website1.com, for example:
type $username type $password password
An Application Definition named www.website2.com may use the variables from www.website1.com, for example:
type $username(www.website1.com) type $password(www.website1.com) password Directory attribute variables
SecureLogin has the ability to read directory attributes from the currently logged on user's object. For example:
type%cn
will read the CN attribute from the currently logged on user's object and type it in. You can only use the percentage sign (%) variables when SecureLogin is configured to use a directory, and only on single-valued text attributes.
SecureLogin has the ability to read directory attributes from the currently logged on user's object. For example:
type%cn
The above command reads the CN attribute from the currently logged on user's object and types it in. You can only use the percentage sign (%) variables when SecureLogin is configured to use a directory, and only on single-valued text attributes.
Stored variables are the most common style of variable used in Application Definitions and Predefined Applications. They are preceded with a dollar sign ($). Use these variables to store the values used during the log on process, such as usernames, passwords and any other details that are required.
This section contains the following information:
The values of these variables are stored in the directory under the user object. They are encrypted so that only the user can access them. You can store variables separately for each Application Definition and Predefined Application, so that you can have a different username variable for one application from the username variable for another application. It is, however, possible to set an application to read variables from another application's Application Definition and Predefined Application. This is useful for applications that share user accounts or passwords. For details on how to do this, see Section 5.2.71, SetPlat.
If a stored variable is referenced in an Application Definition and Predefined Application, and there is no value stored for that variable for example, the first time the program is run, SecureLogin prompts the user to enter a value for the variable. This is an automatic process. It is also possible to manually trigger this process to prompt a user to enter new values for particular variables. For more information, see Section 5.2.21, DisplayVariables and Section 5.2.10, ChangePassword.
Example of stored variables in use:
Dialog Class #32770 Title "Log on" EndDialog Type $Username #1001 Type $Password #1002 Click #1
NOTE:If you want to hide a variable from an administrator by displaying it as **** instead of clear text, begin the variable name with $Password. For example, the $PasswordPIN variable is protected as described, however $PIN is not.
Runtime variables are generally used for storage of calculations, processing data, and date information. You can also use them for temporary passwords and usernames.
Runtime variables are preceded with the question mark symbol (?). They have two modes:
Runtime variables are Normal by default. For details on how to switch a runtime variable to Local mode, see Section 5.2.43, Local.
Runtime variables are not stored in the directory or the SecureLogin cache; they are used straight from the computer's memory. For this reason, it is important not to use runtime variables for the storage of usernames, passwords, or other details SecureLogin will need to access in the future. If runtime variables are used for such details, the user is prompted to enter them each time the Application Definition or Predefined Application is run, or each time SecureLogin is restarted. Users are not prompted for ?variables that have no value. These variables are given the value <NOTSET>.
Example of using a runtime variable:
Dialog Class #32770 Title "ERROR" EndDialog Local?ErrorCount Increment?ErrorCount If?ErrorCount Eq "2" MessageBox "This is the second time you have8 received this error. Would you like to reset the8 application?" -YesNo?Result If?Result Eq "Yes" KillApp "App.exe" Run "C:\App\App.exe" Else Set?ErrorCount "0" EndIf EndIf
Passticket variables are preceded with the exclamation mark symbol (!). To use a passticket variable, you must create and define numerical values for stored variables with the names $DESKEY and $DESOFFSET. These numbers are then used by the SecureLogin Application Definition or Predefined Application parser to generate the one time password.
Once you have defined the stored variables, use the following passticket variable to generate a password.
!<Name of application definition>
or
!default
For example, if you wanted to use a passticket variable for the Outlook application, you would create two stored variables called $DESKEY and $DESOFFSET under the Outlook application definition. You then set values for the two stored variables, which allows you to use the variable "!Outlook" whenever you need to generate a one time password.
You could also use "!Default" which automatically reads the values from the current application definition.
If the credentials used to generate One Time Passwords (OTP's) do not already exist in a secured area of the SecureLogin cache (that is, the $DESKEY and $DESOFFSET variables are not defined), then they are retrieved from the closest SecureLogin Advanced Authentication server. For more information on this, contact Novell Technical Services.