What is the recommended approach to perform a simple SSO proof of concept for a few applications without having to modify the existing IT environment or install any new equipment?

  • 7940824
  • 19-Aug-2009
  • 30-Jan-2014

Environment

SecureLogin
SecureLogin SSO

Situation

Question

What is the recommended approach to perform a simple SSO proof of concept for a few applications without having to modify the existing IT environment or install any new equipment?

Resolution

Answer

Because SecureLogin leverages your existing infrastructure security and choice of Directory (e.g. ADS – including ADAM, eDirectory, SunOne, Critical Path) it does not require additional hardware to operate, making it extremely scalable and robust, and easily deployable.

While SecureLogin requires no new hardware and leverages your existing infrastructure, other solutions may require new hardware in the form of a servers or appliances that store Single Sign-on data.

Of course, the extra servers or appliance must be secured, installed, configured, maintained, backed up and supported. The number of servers or appliances required increases with the size of your organization, since access to Single Sign-on data is typically required locally and must be highly available.

For example, if you have offices in Sydney, London and New York, a primary device, and another for fail over, should be installed in each location, adding to the cost and management overheads associated with your Single Sign-on project.

Using SecureLogin, by simply deactivating the SecureLogin icon in the system tray on the workstation, the entire IT environment will function exactly as it did before SecureLogin was deployed, making it much easier to troubleshoot, support and maintain.

Prerequisites for the POC

  • A Windows XP or Windows 2000 workstation connected to the production network
  • An account with permissions to install SecureLogin on the workstation
  • Applications to be SSO enabled should be installed on the workstation
  • Test logons for all production applications to be SSO enabled. To limit the scope of the POC, we suggest 3 applications.
  • Password policies for the applications to be SSO enabled (e.g. min/max, numerals etc.)

To perform a simple proof of concept that can just as easily be removed once completed, perform the following tasks;

1. Install SecureLogin in standalone mode (on a production workstation)

With SecureLogin installed in Standalone mode on a workstation connected to the production network, all applications are readily available on the workstation without having to configure a separate test environment, and you don’t have to extend the Directory for the POC.

In Standalone mode, changes are only made on the local workstation (and can easily be removed – they don’t affect the production network whatsoever).

You will not have full functionality and will not be able to evaluate the full power of the product, but applications can be fully SSO enabled and show you enough to prove the concept.

TIP: During installation, SecureLogin is placed in the run key of the registry HKLM so it will start for all users that logon to the workstation. However, specific users should be targetted for the proof of concept to limit the scope.

Delete the HKLM (run key) entry and create an entry in HKCU (run key) or the user’s Windows startup group so SecureLogin only starts for that user.

2. To support roaming on the network, set the cache location to the user’s home drive (preferably their roaming profile)

To redirect the cache file to a directory other than the default (%USERPROFILE%\Application Data\SecureLogin) set the following registry setting;

HKLM/Software/Protocom/SecureLogin

CacheDirectory=H:\HomeDrivePath

If possible, set the location to a path that is synchronized between the workstation and the server so it is available both online and offline (e.g. disconnected laptop).

3. Using the predefined applications and/or powerful wizards, configure the applications to be SSO enabled for the POC

In addition to out of the box support for many popular applications, SecureLogin includes powerful wizards and tools to Single Sign-on enable applications and web sites, such as those that are in-house developed or externally managed.

Because there are literally thousands of applications and web site logons, SecureLogin does not lock you in to 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).

Examples of ways SecureLogin can interact with your applications include; detecting and reading dialog boxes, messages, prompts, windows events, and application events; reading URLs, fields, drop down boxes, check boxes, HTML and text on web pages; decompiling Java; and interrogating HLLAPI dll’s and reading text to query terminal emulator screens.

Using SecureLogin, 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.

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.

4. Configure password policies for the applications to be SSO enabled for the POC

Configure the password policies and associate them with the SSO enabled applications. Consider using password randomization where appropriate.

5. Set the appropriate SSO preferences e.g. turn off Windows wizard

Configure the desired SSO preferences.

6. Backup the configuration using the system tray icon Advanced>Backup User Information

Backup the configuration (applications, password policies and preferences) to restore to other workstations to be included in the POC.

7. Install SecureLogin on all workstations to be included in the POC

Although SecureLogin is ""user based"" and the SSO data follows the user so they have access to their SSO credentials (e.g. application UserIDs and passwords) from any workstation, the SecureLogin client must be installed on all workstations the user will logon to and this must be taken into consideration for the proof of concept.

Install the SecureLogin client in Standalone mode and edit the startup as described earlier.

8. Restore the configuration using the system tray icon Advanced>Restore User Information

Once the client has been installed, restore the SSO configuration (applications, password policies and preferences) using the system tray icon.

9. Once the POC is complete, simply remove SecureLogin from the workstation

Remove SecureLogin using Control Panel Add/Remove Programs and delete the local cache file to completely remove SecureLogin without a trace.

TIP: In standalone mode the user can view their passwords so they can take note of them before removing SecureLogin (so they can logon to applications with SSO uninstalled). In Directory mode the ability to view passwords can be optionally be disabled for security reasons.