Protocom Development Systems SecureLogin Single Sign-On (SSO)

Ant Allan Product Report 18 October 2002 Protocom Development Systems SecureLogin Single Sign-On (SSO) Summary Protocom SecureLogin SSO addresses the problems of multiple target-system passwords through directory-based SSO with optional passtickets, a flexible scripting language and script-generating Wizards. Table of Contents Overview Analysis Pricing Competitors Strengths Limitations Insight List Of Tables Table 1: Overview: SecureLogin Table 2: Features and Functions: SecureLogin: Identity Management Table 3: Features and Functions: SecureLogin: Interfaces Table 4: Features and Functions: SecureLogin: Authentication Methods Table 5: Features and Functions: SecureLogin: Single Sign-On Table 6: Features and Functions: SecureLogin: Security Table 7: Features and Functions: SecureLogin: Administration Table 8: Features and Functions: SecureLogin: Auditing Table 9: Features and Functions: SecureLogin: System Requirements Table 10: Price List: SecureLogin Password Management Suite Table 11: Competitors List Of Figures Figure 1: SecureLogin SSO Network Diagram Figure 2: SecureLogin Advanced Authentication for LAN and Remote Access Gartner Entire contents 2002 Gartner, Inc. All rights reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The reader assumes sole responsibility for the selection of these materials to achieve its intended results. The opinions expressed herein are subject to change without notice.

Corporate Headquarters Protocom Development Systems Australia Street Address: 7 Phipps Close Deakin ACT 2600 Australia Postal Address: PO Box 1101 Tuggeranong Mail Centre ACT 2901 Australia Tel: +61 2 6208 4888 Fax: +61 2 6281 7460 E-Mail: sales@protocom.com Internet: www.protocom.cc Overview Protocom s SecureLogin Single Sign-On (SSO), or SLSSO, provides SSO to virtually all Windows, Java, custom, midrange and mainframe target systems as well as intranet and Internet sites. It can detect password expiry and generate random replacements that conform to an organization s security policy. It is the main component of Protocom s SecureLogin Password Management Suite, which also includes: SecureLogin Advanced Authentication (AA) Provides a flexible authentication architecture that can support multiple strong authentication hardware and software products. SecureLogin Self-Service Password Reset Allows users to reset their own network passwords without calling the help desk. SecureLogin SSO SLSSO can leverage an organization s established directory Microsoft Windows 2000 Active Directory, Novell NDS/eDirectory, NT Domains, stand-alone or any LDAP-compliant directory, such as Sun ONE. SLSSO makes three schema extensions: the user, organization and organizational unit objects are assigned extra attributes that are used to store SecureLogin data. (Novell edirectory with SecretStore is handled somewhat differently.) SLSSO can also work with Microsoft Windows NT enterprisewide information is stored in a file location defined by the administrator, and user-specific information is stored ineachuser shomedrive. 18 October 2002 2

SLSSO supports two methods of SSO to target systems: background authentication and password-storeand-forward. The first method, background authentication, operates with components on both the server and the client. During background authentication, when the user attempts to access the system, the client component communicates with the server component. The user is authenticated through a secure handshake process. The second, and more commonly used, method of SSO is the password store-and-forward method. The user s authentication credentials are stored securely and forwarded by SLSSO to the target system as required. The user is not prompted for a user ID or password. The user s log-in credentials are entered by SLSSO. It will appear to the user as though they are no longer required to log in to a target system. SLSSO allows administrators to define which target systems are to be enabled for single sign-on. This option gives the organization: Full control of which target systems can be used for single sign-on. The ability to update the entire directory database with a new target-system application definition by updating a single object. Figure 1: SecureLogin SSO Network Diagram 18 October 2002 3

Administration SLSSO can be administered from the server or the workstation. A central administrator can create and store scripts in the directory, and set preferences on Container and User Objects, allowing all users in and beneath each container to inherit rights to the application definition. Scripts at the Container Object level are called Corporate Scripts. Corporate Scripts allow SSO to be enabled for all corporate target systems without touching them. An administrator can also administer SLSSO at the User Object level, to allow each user s SSO configuration to be customized to suit individual needs. Users themselves can, if permitted by an administrator, use the Workstation Administration Tool to manage log-ins. SecureLogin Advanced Authentication 18 October 2002 4

SecureLogin Advanced Authentication (SLAA) is a suite of authentication modules for LANs (Microsoft Windows, Novell NetWare), Unix servers, IBM mainframes and RADIUS servers. Implementing SLAA enables support of additional authentication methods: Fingerprint Smart cards Onetime-password (OTP) hardware tokens OTP software tokens SLSSO client authentication SLAA supports hardware from most of the major vendors. SLAA also provides the same range of authentication methods for dial-in users via any RFC2138-compliant RADIUS server and a Dial-Up Networking (DUN) Dialer Replacement. Administrators manage users authentication information through integration with a directory and its associated management tool, as for SecureLogin SSO. SLAA can be deployed independently or in conjunction with SLSSO to provide primary authentication via a strong authentication method. Figure 2: SecureLogin Advanced Authentication for LAN and Remote Access 18 October 2002 5

Table 1: Overview: SecureLogin Version SecureLogin v3 Date Announced GA June 2002 18 October 2002 6

Table 1: Overview: SecureLogin Platforms Supported Backgound authentication (passticket) support: IBM OS/390 and z/os with either RACF or Computer Associates etrust CA-ACF2 Unix OSes, via Pluggable Authentication Modules (PAMs) Novell NetWare RADIUS Password store-and-forward (script) support: Prebuilt scripts for many target systems, including: Microsoft Windows 32-bit applications. Any Web-based application using forms-based or HTTP-header-based authentication. IBM OS/390 and z/os via 3270 HLLAPI emulators. IBM OS/400 via 5250 HLLAPI emulators. Unix OSes via VBA-enabled and non-vba emulators. Healthcare applications (including HBO StarNavigator, Lawson and Meditech). Microsoft Terminal Server. Citrix MetaFrame. NfuseElite. Lotus Notes (requires Lotus Notes SSO DLL). Additional platforms can be supported through the scripting Wizard provided with SLSSO which can automatically create corporate application definitions, or scripts can be manually customized by the organization or Protocom. Installed Base Over 1.1 million users worldwide: 1,050,000 users of SLSSO alone, with 50,000 users using both SLSSO and SLAA. By region: North America, Canada and Latin America: 200+ customers and over 500,000 users EMEA: 150+ customer and over 500,000 users Asia/Pacific: 20+ customers and over 100,000 users Table 2: Features and Functions: SecureLogin: Identity Management User Definition User Registration Target-System User Name Assignment SLSSO does not maintain its own user repository. Not applicable. SecureLogin discovers each user s IDs across all target systems as each one is accessed. Table 3: Features and Functions: SecureLogin: Interfaces Target System Interface SLSSO supports two methods of SSO to target systems: background authentication and password-store-and-forward. 18 October 2002 7

Table 3: Features and Functions: SecureLogin: Interfaces Background Authentication Password Store-and- Forward SLSSO background authentication works through the use of passticket authentication that requires software components on client and target system server: When the user attempts to access the system, the client component communicates with the server component. The server responds with a request for a passticket rather than a request for a password. The client replies to the server s request by providing a passticket. SLSSO supports RACF, etrust CA-ACF2, Unix operating systems and RADIUS servers. For IBM mainframes with for IBM s RACF or CA s etrust CA-ACF2 background authentication requires an interface module. This comprises a Unix System Services application that synchronizes the directory data with the RACF database or ACF2 s InfoStorage and a System Authorization Facility (SAF) validation exit. SLSSO stores the user s authentication credentials in an established corporate directory. Workstation agents read the user s SSO information, interpret the scripts and perform the appropriate function for example, forward username and password to the target system. The user is not prompted for a user ID or password: it appears to the user as though the target system no longer requires a log-in. A user s credentials (and scripts) can also be encrypted and cached on the local workstation to provide fault tolerance and mobile user support and to reduce network traffic. The workstation cache is synchronized each time the user connects to the network. Any changes that are made on the workstation are sent to the directory, and any changes made in the directory are sent to the workstation. SLSSO provides three methods of configuring scripts: Automatically detecting password fields (as described above). After a password field is detected, SLSSO offers to launch its Wizard to configure the target system for SSO. Administrators can create scripts automatically, using the SecureLogin Wizards. The Wizards work with approximately 90 percent of all target systems. For more involved, or highly customized target system log-on processes, administrators can manually write or edit scripts. Protocom Development Systems offers a 24x7 Technical Support Department that can provide assistance to SLSSO customers. 18 October 2002 8

Table 3: Features and Functions: SecureLogin: Interfaces User Desktop There are three SLSSO workstation agents: The Web browser agent provides SSO to Web sites accessed through Microsoft Internet or Netscape. The agent automatically detects a log-in or password field, sets the values for the fields and submits the form to log in to the site. This agent allows SSO with sites using Hypetext Transfer Protocol (HTTP) dialogue authentication. The Windows 32-bit agent provides SSO to the majority of 32-bit window applications running on the user s workstation, as well as Windows 16-bit applications and DOS applications running under Windows. This agent fully automates the log-in process. The Terminal Launcher agent provides SSO to mainframes and other terminal emulator sessions (such as telnet). Terminal Launcher is integrated with terminal emulators that support the HLLAPI interface, VBA, DDE and generic Windows support, and also those that have built-in scripting language support. Almost all terminal emulators can be SSO-enabled using Terminal Launcher. Agent software can be distributed via standard tools, such as Novell ZENworks, SMS, Tivoli, CA Unicenter, and is fully MSI compliant. Table 4: Features and Functions: SecureLogin: Authentication Methods Memorized Passwords Self-Service Password Reset Advanced Authentication Methods Onetime-Password (OTP) Tokens Smart Cards Biometrics SLSSO uses a person s established network OS password as the primary authentication method. In offline mode, it can use either the person s SLSSO passphrase or network OS password. SecureLogin Password Reset provides Web-based reset for established network OS passwords. A person can verify his or her identity using multiple passphrase questions and answers created when they first used SecureLogin. Optionally, a second person can use his or her established credentials to vouch for the requestor. This product can be used alone or in conjunction with SLSSO. SecureLogin Advanced Authentication (SLAA) alone allows the organization to use other authentication methods with LANs, Unix OSes, mainframes, etc. In conjunction with SecureLogin SSO, SLAA allows other primary authentication methods for SSO. VASCO Digipass Any PKSC#11 compliant smart cards Fingerprint devices, including: Precise Biometics. Secugen. 18 October 2002 9

Table 5: Features and Functions: SecureLogin: Single Sign-On Target-System Password Discovery Target-System Password Change Primary Password Timeout Desktop Locking Where password store-and-forward is in use, once an administrator publishes a target system for SSO the next time a user accesses that target systems, SLSSO sees the log-in panel and prompts the user to enter the username and password for that system. The user fills in the username and password and SLSSO encrypts them (with Triple DES) and stores them in the directory. (The next time the target system is accessed, SLSSO retrieves the stored credentials and transparently logs on to the target system.) Administrators can configure SLSSO scripts to detect a failed log-on attempt and display a dialogue box advising of an invalid username and/or password and allowing the user to reenter them. Optionally, SLSSO can display a message advising the user to contact the IT Helpdesk, send SNMP alerts or kill a session. SLSSO accommodates different password change rules and password policies. Administrators can customize password change periods and password policies to meet the organization s requirements for each target system. SecureLogin SSO s Password Policy feature allows administrators to create password policies with rules such as length of password; whether or not to use numerals; repeating, sequential and duplicate characters; number of upper and lowercase; and so on. Administrators can assign a policy to one or many target systems. When a target system requires a new password, SLSSO can either: Generate a random password that conforms to the appropriate password policy. Allow the user to enter a new password (SLSSO enters the user s old password into an old password field if required). Administrators can set time interval for password reauthentication, so that users will authenticate every log-on, once per session or as frequently as desired, to provide some protection against walk-away security breaches. Administrators can also configure sensitive target systems to demand reauthentication. SLSSO activates a screen saver after a period of inactivity, configurable for each user (or for groups of users at the Container Object level). There is a five-second delay between SecureLogin activating the screen saver and locking the desktop. There is an optional audible warning that plays a short tone through the system speaker when the screen saver is activated so that a user who may be looking away from the screen is alerted and can deactivate the screen saver before the screen is locked. Table 6: Features and Functions: SecureLogin: Security Communications Communications between SLSSO components and target systems are encrypted using OpenSSL and Novell International Cryptographic Infrastructure (NICI) for FIPS-140 compliance. 18 October 2002 10

Table 6: Features and Functions: SecureLogin: Security Server/Repository Resilience Scalability SLSSO stores all user credentials target-system usernames and passwords and other SecureLogin information (for example, which target systems are SSOenabled) and other settings in the directory with Triple-DES (3DES). Optionally, SLSSO can also cache the user credentials in an encrypted format on the local workstation. On first use of SecureLogin SSO, the user is prompted to enter a passphrase question and answer combination. The primary use of this passphrase is when the directory is down or unavailable and the user cannot authenticate via a trusted network OS password. The user must supply the passphrase answer before the SLSSO client will unlock the user s data and enable SSO. This passphrase also protects the user s data if an administrator changes the user s network OS password. SecureLogin can detect that the password has been changed by someone other than the user and will prompt for the passphrase answer on the next network log-in, before enabling SSO to target systems. SLSSO employs multiple methods of fault tolerance. One method uses local encrypted caching to ensure that network downtime does not affect single sign-on performance. Even if the corporate network is down, caching enables target system log-ins to continue uninterrupted. A second method uses scripting to cater to different log-in conditions and errors during log-in. A third method is that SLSSO can be configured to replicate throughout the directory, thus eliminating single point of failure and WAN communications exposures. SLSSO leverages the corporate directory and scales to the maximum limit of the directory. (Protocom cites successful tests of SLSSO with more than one billion users.) Table 7: Features and Functions: SecureLogin: Administration Interface Reporting Local Administration Integrated management with Microsoft Management Console (MMC), Novell ConsoleOne, Novell NetWare Admin (NWADMIN), SL Manager for NT Domains and other LDAP-compliant directories, and Protocom s stand-alone tool. In addition, the Workstation Administration Tool is provided for self-service. SecureLogin can produce log files for error checking and SNMP traps to any management console. SecureLogin supports decentralized administration with security delegation. In addition, the Workstation Administration Tool allows a user to: View established target-systems that are single sign-on enabled. Add new target-systems for single sign-on. Modify passwords to established single sign-on enabled target-systems. Change control settings and preferences. Administrators can limit users access to the Workstation Administration Tool at the User or Container Object. 18 October 2002 11

Table 7: Features and Functions: SecureLogin: Administration Utilities Window Finder A component used to find out information about the window that a log-in box is on. Window Finder shows the name of control buttons (for example, OK or Next ) and reveals the button s control ID number. The Window Finder component works with all Windows applications that have generic username and password prompts and with most specialized applications that have very complex log-ins. Login Watcher A utility to assist administrators in gathering information about an target system that they want to enable for SSO. An administrator runs Login Watcher and the target system at the same time, and Login Watcher captures information about the target system and saves that information to a log file. Table 8: Features and Functions: SecureLogin: Auditing Event Logging Log Archiving Reporting Alerting SLSSO provides configurable audit logging of log-on and change password events and error messages. As for host system. As for host system. As for host system. Table 9: Features and Functions: SecureLogin: System Requirements Directory Server Administrator Client Client Novell Directory Services (NDS) on NetWare 4.12 or NetWare 5.1 or later Novell edirectory on NetWare or Windows NT: In the non-secretstore mode, SecureLogin runs against edirectory on any platform. Microsoft Windows 2000 Server or Advanced Server with Active Directory Microsoft Windows NT 4.0 Domains Microsoft Windows NT 4.0 Terminal Server Microsoft Windows XP Server Any server running an LDAP-compliant directory: For example, Sun ONE Identity Server Stand-alone directory OS: Microsoft Windows 95, 98, NT 4.0 Workstation, 2000 Professional or XP Snap-ins: Microsoft Management Console (MMC) Novell Console One 1.3.2 or later Novell NetWare Admin (NWAdmin) OS: Microsoft Windows 95, 98, NT 4.0 Workstation, 2000 Professional or XP Browser: Microsoft Internet Explorer 5.01 or later Netscape 4.7.x or later Analysis Protocom Development Systems is a privately owned company with headquarters in Canberra, Australia, with regional offices in Portland, Oregon, U.S.A., and Oostvoorne, NL. Protocom was founded in 1989 and is now incorporated in the U.S., the Netherlands, the U.K., South Africa and Australia. Protocom s 18 October 2002 12

flagship products are SecureLogin and SecureConsole (a secure console management tool for NetWare servers). With the SecureLogin Password Management Suite (SecureLogin), Protocom offers what it calls a holistic approach to password management. Typically, organizations are faced with a choice of single sign-on (SSO) or self-service password reset and/or password synchronization from one vendor. With the SecureLogin, an organization can combine SSO with strong authentication methods and, with the release of SecureLogin 3.03 announced for October 2002, self-service password reset. SLSSO is a stable, mature SSO product backed by partnerships with Novell, Microsoft and Citrix. It has one of the largest deployed user bases in the world, with British Telecom recently purchasing an enterprise license to allow deployment to its 140,000 users. Production implementations include many government offices and other leading private corporations with up to 26,000 users, the largest of which has been using SLSSO for six years. (Protocom can provide details of reference sites on request). Directory-Enabled Single Sign-On SLSSO is designed to work with an organization s established corporate directory, so the organization does not have another server and repository to implement and manage as they would with, say, CA etrust SSO. It supports the most common directory services Active Directory, NDS and Sun ONE and can work with any LDAP-compatible directory. It also supports directory-less Microsoft Windows NT environments. SLSSO data user credentials, target-system scripts, etc. is stored and protected in the directory. When used with Novell s NDS edirectory, SecureLogin can use SecretStore technology to provide an additional level of security. SLSSO stores corporate scripts in a Container Object rather than individual User Objects, so reducing complexity and increasing manageability. Powerful, Flexible Scripting Protocom s proprietary scripting language is another feature of SecureLogin SSO. This simple language is designed to provide compatibility with almost all network environments and target systems. An organization can define SSO methods for almost any Windows, Terminal Server, mainframe, Unix, Internet or intranet target system. SLSSO can handle several versions of one target system, especially important during system upgrades. SLSSO includes a scripting Wizard that can automatically configure new applications, effectively hiding the scripting language from the user. The Wizard has been set up to support a large range of target systems (applications, terminal emulators, etc.) and provides an efficient configuration tool for both administrators and individual users. The scripting language is used in individual target-system scripts to retrieve and enter the correct log-in details. These scripts are stored and secured within the directory to ensure support for single-point administration, manageability and maximum security. Administrators can write and define single sign-on scripts once for the whole organization while still allowing for customized subordinate Container Objects and User Objects. If a subordinate object has a different script for the same target system defined locally, the local copy will be used instead of the version on the higher object. The organization can use the scripting language to automate many log-in processes, such as multipage log-ins and log-in panels requiring other information such as surname and telephone number that can be stored in the directory. The scripting language also contains the commands required to automate password changes on behalf of users and request user input when it is required. The scripting language can also be used to provide transaction verification. SLSSO can watch a target system, recognize transaction screens and prompt the user to reauthenticate before a transaction is 18 October 2002 13

entered. Reauthentication can be driven by data values for example, it can be invoked only for monetary values over a certain value. This approach is easier to implement than an API-based intra-session authentication, but it does not allow the reauthentication event to be recorded with the transaction that is, there s no electronic signature. Range of Primary Authentication Options SLSSO alone supports only memorized passwords. In this case, the password is that normally used to log in to the network OS. By using SLAA in conjunction with SLSSO, an organization can use stronger primary authentication methods, such as VASCO Digipass OTP tokens, smart cards and fingerprint biometrics. This does, however, incur an additional cost. Single Sign-On Improves Security SLSSO allows the organization to transparently implement strict password policies across all target systems. SLSSO can generate more complex, and hence more secure, passwords than users would normally use or remember. In addition, an administrator can change the frequency of password changes to any desired interval, from weeks to every session, with no additional burden on the users. Where target-system passwords are not revealed to the user, security is further increased as users must have access to a system with SLSSO installed to get into the systems. This can be a big problem if the directory is unavailable if user s do not know their target system passwords, they cannot log-in directly. An organization can, however, address this with SLSSO as it can cache the users credentials on their workstations. If memorized passwords are used as the primary authentication mechanism, each user has only one to remember. This password can be made more complex and changed more often (for example, every month) to improve security, without it becoming to onerous for the user to remember. Single Sign-On and Password Reset Reduce Costs If each user has only one password to remember, it will not be forgotten so often, and Protocom and other vendors estimate that this can eliminated up to 80 percent of password problems. This reduces both lost user productivity and calls to the organization s help desk (which Gartner Research estimates can account for upwards of 30 percent of all help-desk calls). With the addition of SecureLogin Password Reset (at an additional cost), an organization can gain the further benefits of self-service password reset other vendors experience shows that about 65 percent of users can resolve their own problems via self-service reset. Protocom is the first vendor to offer selfservice password reset as well as SSO. Secure Credential Storage All users credentials are stored centrally in a corporate directory. In addition to the access control afforded by the host system, SLSSO encrypts all data with Triple-DES (3DES), keyed by a passphrase for each user, which is set when the user first uses SecureLogin SSO. This ensures that systems administrators cannot retrieve the users passwords to any target systems. To prevent systems administrators and help-desk operators from changing a user s primary network OS password, SLSSO users each have a passphrase. SLSSO can identify when someone other than the user has changed the password and will prompt the user for the passphrase before allowing access to any target system. 18 October 2002 14

Support for Roaming and Mobile Users Because SLSSO is directory enabled, users can log in from anywhere on the corporate network and get the same capabilities as if they were at their own desks; roam the enterprise, logging into several different machines during the day; or securely use a shared kiosk-type workstation that is, in healthcare environments, where many people log in temporarily for quick work and then log out. The use of a locally encrypted cache allows all mobile and remote users to use SLSSO regardless of network connectivity. If granted by the administrator, mobile users can update their single sign-on credentials when disconnected from the network and update the directory with these details when they are next attached. Ease of Deployment SecureLogin SSO s use of an established corporate directory makes it easy to deploy. Protocom asserts that a typical implementation project for 1,000 users will take three to six months, while a project for up to 50,000 users with a large number of applications will take between six months and one year. Relationship With Novell Protocom has an OEM relationship with Novell for SecureLogin SSO, which it offers as Novell SecureLogin. The other components of the SecureLogin Password Management Suite are not included. In Novell s deployment, Novell Modular Authentication Service works with SLAA to provide integrated authentication via OTP token, smart card or biometric device. Pricing Protocom offers per-user licensing with discounts for tiered quantities. Table 10: Price List: SecureLogin Password Management Suite Product Price per User (US$) SecureLogin Single Sign-On (AD, NT and LDAP) v3.03 79 SecureLogin transfer from Novell version to other 20 versions SecureLogin AA (Advanced Authentication) when bundled with SecureLogin SSO v1.8 SecureLogin Advanced Authentication Stand-alone Version v1.8 SecureLogin AA for Unix (Solaris/Linux) with background authentication support v2.0 SecureLogin ACF2 and RACF background Authentication modules v1.5 SecureLogin for RADIUS v2.0 20 40 25 25 Included with SLAA Maintenance: Protocom has a standard maintenance contract of 20 percent of the current RRP minus quantity discount price per year. The maintenance agreement provides software upgrades as well as 24- hour technical support. Three months maintenance is included in the initial purchase price of all products. GSA Pricing No. 18 October 2002 15

Competitors SLSSO competes directly with other SSO products. When combined with SecureLogin Advanced Authentication, it competes with authentication management infrastructure (AMI) products. (AMI products typically offer centralized management of multiple authentication methods and flexible authentication policies, sometimes with SSO.) Table 11: Competitors ActivCard Inc. Trinity Internet: www.activcard.com BioNetrix Systems Corp. BioNetrix Authentication Suite (BAS) and BioNetrix SSO Internet: www.bionetrix.com Computer Associates, Inc. etrust SSO Internet: www.ca.com Passlogix, Inc. v- GO SSO Internet: www.passlogix.com Ankari s Trinity AMI product supports multiple authentication schemes, including memorized passwords, RSA SecurID, smart cards and biometrics (fingerprint only). It also supports a wide range of platforms including Unix and IBM mainframe operating systems, and groupware such as Lotus Notes. SSO functionality is integrated with the core product. BioNetrix s BAS supports multiple authentication schemes, including memorized passwords, smart cards and various biometrics, but no onetime password tokens. It also supports a wide range of platforms but not Unix or IBM mainframe operating systems. It allows user reauthentication to be built into workflow applications for transaction security. A separately licensed product, BioNetrix SSO adds SSO functionality, but by itself the only supported primary authentication method is memorized passwords. CA s etrust SSO developed from Memco/Platinum s Proxima provides SSO via a directory-base architecture. It supports a range of primary authentication methods that includes an independent SSO password, network OS passwords, onetime password tokens, smart cards and various biometrics. It supports a wide range of Windows, Web and terminal-emulated target systems via pre-built and custom Tool Command Language (Tcl) scripts. Passlogix s v-go provides SSO via a client-oriented architecture that supports roaming and offline access. Its modular primary authentication allows an organization to use Windows network passwords, PKI (Entrust, RSA Keon) passwords, graphical user passwords, and provides an API to allow the integration of other strong authentication methods, such as smart cards and biometrics. It supports a wide range of Windows, Web and terminal-emulated target systems via Wizards. Novell used to offer this product under license as Novell Single Sign-On (NSSO) with v-go bundle, but this has been discontinued. SecureLogin Password Reset will compete with password management products from Blockade (ManageID Selfserv), Courion (PasswordCourier), M-Tech (P-Synch) and others. While it is not a fully featured stand-alone product, SecureLogin Password Reset will be the first self-service password reset product to be integrated with an SSO product. Strengths Works With Any Corporate Directory SLSSO works with an established corporate directory Microsoft Windows Active Directory, Novell NDS or edirectory, Sun ONE or any other LDAP-compliant directory. An organization does not have an SSOspecific server and repository to manage. Furthermore, there is no lock in to any one directory an organization can easily migrate SLSSO from, say, Active Directory to complete user transparency. Directory-Based Architecture Eases Manageability and Customization 18 October 2002 16

SecureLogin SSO s architecture provides easy manageability and customization. Administrators can manage everything centrally and using simple extensions to established directory management tools. As scripts and configurations can be stored at Container Object and User Object levels, administrators can easily create enterprisewide settings, with more specific settings taking precedence at the organizational unit (OU) and user level. This approach also makes it easy to disable SSO for some applications for individual OUs and users by creating null (that is, do nothing ) scripts. SecureLogin Wizard and Versatile Scripting Language The SecureLogin Wizard allows automatic generation of log-in scripts and guides administrators or users through a series of steps to create or modify a new log-in script. If desired, administrators can also use SLSSO s proprietary scripting language to maximize the versatility of the SLSSO deployment. Although it is a proprietary language, it will be easily grasped by anyone familiar with Tcl, Perl or Rexx. SLSSO documentation includes a full Command Reference Guide, and Protocom s Technical Support can provide further guidance. Scripting keeps all software implementation at the client level: an organization does not need to install software on target-system servers or change target-system code. It also gives administrators the flexibility to identify some target systems for advanced authentication, to bring up message boxes that users must respond to, to redirect the user to another URL and so on. Limitations Strong Authentication Methods Require Additional Components SecureLogin Advance Authentication provides out of the box support for strong authentication methods, but at an additional cost. While most organizations will continue to rely on memorized passwords as the primary authentication method, this additional cost (about 25 percent of the SLSSO cost when licensed together) may deter organizations looking to move toward strong authentication. As most organizations will be happy to use only network OS passwords, however, a separate license for the advanced authentication option keeps down the cost of the SSO product. Scripting May Be a Barrier for Some Organizations Although SLSSO s scripting language makes SLSSO extremely versatile and Protocom provides many pre-built scripts, some organizations may be averse to this approach. The SecureLogin Wizard goes a long way toward addressing this problem, however, and an organization should recognize that it can deploy SLSSO effectively in many environments without the need to use the scripting language directly. Insight Protocom s SecureLogin SSO is a flexible, scalable SSO product with many long-term, large (more than 5,000 users) deployments. Its directory-centric architecture can integrate easily with any corporate directory (as well as Windows NT domains), with easy management through snap in components, and provides easy manageability and customization. Its target-system interfaces use a proprietary scripting language. Some organizations may be averse to this approach, but Protocom supplies many pre-built scripts and SecureLogin Wizards that allow administrators to generate additional log-in scripts without having to edit code. An organization can customize scripts to achieve a high degree of tailoring say, to allow organization-specific error handling. SecureLogin Advanced Authentication allows an organization to use smart cards and biometrics with SSO across the whole enterprise or with selected target systems, but this adds about 25 percent to the licensing cost. For many medium to large enterprises, SLSSO will be a sound choice. 18 October 2002 17