Why does SecureLogin Single Sign-On include a scripting language? Where can I get assistance with scripting?

Question

Why does SecureLogin Single Sign-on include a scripting language? Where can I get assistance with scripting?

Answer

Note: Scripts are called Application Definitions in v6 and above.

Because there are literally thousands of applications and web sites logons, SecureLogin does not lock organizations into a single way of enabling an application. It works with applications previously thought impossible to Single Sign-on enable (and which other vendors still believe are).

In addition to out of the box support for many popular applications, SecureLogin includes powerful wizards and tools to Single Sign-on enable even the trickiest applications, including off the shelf, in house developed, or externally managed.

Administrators can typically Single Sign-on enable logon to an application in a matter of minutes using the powerful wizards, and include error handling, password changes and password policies in less than fifteen minutes.

To enhance the user’s experience and minimize support costs, scripting can be optionally used by SSO administrators to customize application definitions and ensure that all application events are taken into account before making the application definition available to all users by publishing it in the Directory. Since the Single Sign-on application definition can be associated with organizational units, organization, and/or group policy objects (in an Active Directory environment), Single Sign-on enabled applications can be made available to all users or selected users and/or groups with a few clicks of the mouse.

Examples of application events that are typically handled include:

• Logon
• Invalid Username
• Invalid Password
• Account Locked
• Password expiry
• Password change invoked by the user (e.g. Tools>Change Password)
• Password policy
• Password history (e.g. new password the same as the old)
• User canceled password change
• User canceled logon
• Any other messages an application produces (e.g. SecureLogin can read an otherwise meaningless error such as e102r and can be used to produce user friendly messages or even resolve the problem without user intervention).

You do not have to be a developer to create or edit SecureLogin application definitions. Anyone with experience in writing batch files or managing standard login scripts is able to start scripting in a matter of minutes.

The Wizards and scripting provide full control over the SSO environment via the ability to customize application definitions to handle and respond to any dialog box, message or event an application triggers. The advantages of using the easy to learn and powerful scripting feature to enable your applications include:

• SSO enable applications using the predefined applications or wizards and optionally customize the application definition using scripting;
• Instead of having to contact development whenever you wish to implement something that would typically not be supported “out of the box”, scripting fills the void by effectively providing you with a resource kit of simple commands;
• SSO enable an application ONCE and publish it centrally for all users in your organization without needing to make changes on all users workstations;
• Application definitions can handle much more than just logon to applications. An application definition handles all logon, change password, password expiry and error messages, minimizing support calls;
• Enables Single Sign-on to the most applications by far;
• Applications (e.g. .EXE or .DLL files) don’t need to be modified in any way and no changes are made to backend application servers. This unobtrusive approach makes enabling, configuring, upgrading and maintaining the SSO environment much simpler and far more powerful, and eliminates change control and support overheads;
• You can make sense of nonsensical error messages. For example, SecureLogin can read error messages and self heal an application that natively returns “error 102e” – which would otherwise confuse users;
• Handles all use cases. For example, if a user clicks cancel on a change password prompt, SecureLogin could launch an Intranet help page advising the user why they should change their passwords regularly.
• Applications can be shutdown based on a failed logon e.g. invalid fingerprint logon closes the application and sends an alert to an administrative console;

The power of scripting is almost endless. Solutions that do not provide scripting functionality are unable to meet requirements and do not live up to the marketing hype when more than 3 applications are SSO enabled.

For more information, please refer to the application definition guide that comes with SecureLogin.