To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
In short, testing an enterprise single sign-on (SSO) implementation is done by logging in using the SSO system and then trying to log on to separate applications accessed by the system.
Enterprise SSO implementations use either a hardware or software module to authenticate individual applications. When using a software module, the SSO application may sit on a dedicated server. In that case, the software module resembles a hardware device. Either way, the SSO system sits between the user and the applications. Before SSO, there was nothing between the user and the applications; the user logged directly on to each application separately.
The difference with SSO is that this module completes the authentication done previously by the user. The module establishes a trust relationship with each application after the user logs in. The module must create and maintain an authenticated session as long as the user is logged on. That session must be active and able to log on to each application registered with the SSO system.
To test the SSO system, the user logs into their desktop per usual, but this time, he or she is actually logging into the SSO module. After login, the user should be able to access each application registered with the system separately without providing a username and password.
The same goes for testing enterprise single sign-on for a Web application. The user should be able to log on to the Web application acting as the SSO gateway, and then log on to any other registered Web application without being prompted for credentials.
Conversely, the SSO system should extinguish credentials when the user logs out. This is testing in reverse. If the user logs out of the system, he or she shouldn't have immediate or unauthenticated access to member applications.
This is a very high-level overview of testing an SSO system. In reality, you should have a set of test user IDs and passwords, or other log-in credentials, and set up a series of scripts with different log-on scenarios. The scenarios should test for logon, logoff and logging into the registered applications within the system.
If access to each application can be done without being prompted, or without an error, then your SSO system is working properly.
For more information:
Read about your options when accessing multiple applications through a remote Citrix server.
Learn how single sign-on can improve productivity, save money and protect corporate information.
|
