Environment
Situation
Question
What criteria should I test against during a proof of concept (POC) to make sure I purchase the best of breed SSO solution?
Resolution
Answer
A common misconception is that "as long as the vendor sells Single Sign-on, we are pretty much getting the same thing irrespective of which product we purchase."
This statement could not be further from the truth. Products vary significantly in many aspects including their fundamental approach to solving password management issues, features, management, application integration, smart card and strong authentication support, flexibility and power.
NetIQ encourages organizations that are evaluating Single Sign-on to look past fancy marketing messages and to look under the hood at the technical capabilities and thoroughly evaluate products before deciding on the Single Sign-on solution to deploy.
In the past, organizations that have believed marketing hype without defining requirements have been let down and only realized they had purchased an inferior solution after they have deployed and users have forgotten all their usernames and passwords.
Once you have eliminated the need for users to remember and enter passwords, it may be too late to remove the implemented software so it is vital you take time to make an informed decision based on requirements (current and future such as user provisioning, strong authentication, new Directories, new applications etc.) and technology.
The first step when investigating SSO solutions is to gather information and evaluate software. While SecureLogin is easy to install and administer and SSO enables both in-house developed and off-the-shelf applications, many vendors make false claims about their software that are exposed during the evaluation stage.
If you believe the marketing hype without performing an evaluation of the technology you may be left with a ""solution"" that is unable to do what you expected, is difficult to manage and deploy, and is unable to grow as the requirements of your organization invariably change.
For example, you may wish to implement smart cards or user provisioning and integrate them with SSO, or integrate other applications in future.
This document outlines some of the key criteria that should be evaluated when selecting a Single Sign-on product.
Contact NetIQ for best practice recommendations based on your environment and requirements, or to discuss any aspect of Single Sign-on.
Criteria 1 - Security of SSO data (including application UserIDs and Passwords)
Security of a user’s Single Sign-on credentials is critical to any solution. SecureLogin 3DES or AES encrypts ALL Single Sign-on data including password policies, applications that are enabled and all credentials including usernames, passwords, database names and IP addresses.
SecureLogin handles much more than just logon or passwords. It handles all credentials and protects and encrypts all SSO data; in the Directory, in the local cache, during transmission, and in memory.
SecureLogin also protects the user from an administrative attack. For example, by default, if an administrator resets a user’s network (e.g. ADS) password, the next time that user logs on, they will be prompted to answer a user specific SecureLogin question.
This helps protect the user from a rogue administrator simply resetting their network password and logging on as them to access their applications that have been SSO enabled.
SecureLogin also includes support for stronger security mechanisms such as PKI. If you have enabled smart cards (or wish to do so in future) for logon to the LAN, a user’s Single Sign-on credentials can be protected via PKI. Only a user with the smart card (and therefore their Private Key) would have access to their SSO credentials.
Criteria 2 - Easy to install/deploy
with centralized management/administration
SecureLogin is easily distributed to workstations using an MSI package or any software distribution method such as Intel LanDesk, Novell ZenWorks, etc. It is centrally managed using MMC in Microsoft environment, ConsoleOne in a Novell environment and SecureLogin Manager in other environments.
Changes can be made and new applications can be Single Sign-on enabled for all users through the power of the Directory, providing complete control over the Single Sign-on environment, even after the client has been deployed.
Administrators can assign Single Sign-on enabled applications and settings to User objects, Organizational Units, Containers and via Group Policies.
Management is extremely granular. Options such as which applications are enabled/disabled, whether the user is enabled/disabled, whether they have access to an offline encrypted cache for disconnected mode, whether the icon is displayed in the system tray, and whether they have access to Single Sign-on enable their own applications, can all be configured centrally with a few clicks of the mouse.
Criteria 3 - Technical expertise must be available locally
Novell / NetIQ has been developing SSO since 1994. With offices around the world, our global team focuses on providing an organization with everything and anything they need to successfully deploy and support SecureLogin.
SecureLogin has a proven installation base with many large profile customers and successful deployments. The website includes a support knowledgebase that is constantly updated with useful information.
Criteria 4 - Data such as application usernames and passwords must be stored securely in the organization’s choice of corporate directory and must not require additional hardware
All SecureLogin data including SSO enabled applications, settings, and user’s logon credentials is PKI, AES or 3DES encrypted and stored in the organization’s choice of Directory, such as eDirectory, ADS or any LDAP v3 compliant Directory (SecureLogin is platform independent).
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 server or appliance must be secured, installed, configured, maintained, backed up, replicated 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.
Criteria 5 - Application Logon - SSO software must be able to seamlessly logon to applications, including the ability to select multiple users
SecureLogin handles logon to Windows, Java, Web, Citrix and Terminal Emulators. It also handles multiple users to the same application or several applications that share credentials.
In addition, SecureLogin remembers more than just usernames and passwords. It can remember all credentials an application requires including domain names, database names, IP addresses etc.
Applications can be easily enabled using the powerful wizards and tools and can be centrally published for all users.
Criteria 6 - Invalid Username and/or Password entry - Users might accidentally store invalid credentials or lock their accounts. The SSO software must be able to detect invalid credentials are stored and prompt the user to verify them
SecureLogin handles the situation where a user stores an invalid username and/or password. SecureLogin detects application error messages and displays the invalid credential to the user. If the invalid credential is a password, it is displayed in the format ********* or it can be cleared so the user has to enter it from scratch.
When the user corrects the credential, SecureLogin automatically retries logon. SecureLogin can also set a counter to check the number of failed logons to applications that would otherwise lock accounts, and notifies the user to contact the administrator before the account locks, further reducing Helpdesk costs. It could even send an SNMP alert based on the number of failed logons (or any other condition you wish).
Criteria 7 - User Password Change - SSO software must handle password changes if the user invoked the change password function
SecureLogin handles the changing of password when a user elects to change it themselves. SecureLogin is able to see the change password window and invoke the change password process. If desired, you can force the user to change the password and/or automatically generate a random password based on a strong password policy.
Criteria 8 - Password Expiry - SSO software must handle password changes the password if the password expired
SecureLogin handles the changing of password when it expires. SecureLogin is able to see the password expiry message and invoke the change password process. If desired, you can force the user to change the password and/or automatically generate a random password based on a strong password policy.
Criteria 9 - New passwords must meet or improve the application password policy
SecureLogin comes with advanced password policies you can configure according to your application policies. You decide the password policy to apply per application or for a set of applications, and SecureLogin enforces them centrally. SecureLogin can also force password changes, password history checking and strong password policies on applications that are unable to do so natively.
Criteria 10 - For security reasons, passwords must NOT be synchronized on all systems
Although users need only remember one logon method (e.g. ""master"" password, smartcard/PIN, biometric, OTP) to use SecureLogin, the passwords to all the backend systems are all kept different. This means you can have stronger password policies on stronger systems, rather than a ""lowest common denominator"" approach such as password synchronization.
With SecureLogin, users don’t necessarily even know their passwords to backend systems because SecureLogin manages passwords, meaning users cannot write their passwords down, share them and when they leave your organization, they do not know what their passwords are.
Criteria 11 - Must be able to randomly generate passwords or ask the user for a password, depending on the application owner’s requirements
When an application requests a password change or when a user opts to change their password, SecureLogin can prompt the user to choose a new password (and match it to a password policy) or randomly generate passwords, whichever you prefer. You can choose which applications you want the password randomly generated for and which you want the user to choose.
Criteria 12 - For support, change control, installation and management reasons, the solution must not require any modules to be installed on application servers or changes to EXEs or DLLs.
SecureLogin does not require services running on a server or changes to application executables, dynamic link libraries, initialization files etc. Because SecureLogin does not touch backend systems, it is easily integrated with any application (e.g. off the shelf, in house developed and/or externally managed applications) and does not create political, change control or support issues. And no arguments between vendors on whose fault it is when an application or application server fails.
Criteria 13 - The ability to logon to both the network and applications using advanced authentication methods such as biometrics (e.g. fingerprint), smartcard/PIN and tokens
SecureLogin integrates with strong authentication software enabling biometric, smartcard or token authentication to the network and applications. Strong authentication software eliminates the need for users to remember and manage passwords altogether.
Rather than just something you know (such as password), multi factor methods include something you have (such as a smartcard) and something you know (such as a PIN).
In addition to network authentication, SecureLogin can be configured to request application re-verification. SecureLogin can request a biometric, smartcard or token authentication before permitting logon to any or all SSO enabled applications.
Any application (e.g. that was previously secured using a password) can be configured to require the strong authentication before access is granted.
In addition to re-verification at logon, applications can be configured to require strong authentication when particular transactions are performed. For example, SecureLogin could prompt for a fingerprint or smartcard/PIN before printing from a senstive database or transferring large sums of money, even on applications that are unable to do so natively.
From a user point of view, they logon to the network with a logon method such as fingerprint, smartcard or token, and they are also prompted to re-verify their configured logon method when they run SSO enabled applications or perform certain transactions.
Applications require no special configuration or changes to enable this feature, it is EASY!
Criteria 14 - High Availability and Resilience
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.
SecureLogin is closely integrated with your Directory’s administrative consoles, inbuilt resilience, service location, redundancy and high availability.
By simply deactivating the SecureLogin icon in the system tray, the workstations, applications, and application servers will function exactly as they did before SecureLogin was deployed, making it much easier to troubleshoot, support and maintain.
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 appliance must advertise services on the network, be secured, installed, replicated, 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.
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 overheads associated with your Single Sign-on project. And these devices would have to be replicated so SSO data is available as and when required.