Implemented correctly, Single Sign On (SSO) saves an organization time and money through productivity gains. Users do not have to enter numerous logins and passwords to access each of their applications on one system. SSO relieves users of the burden of having to remember a handful of login names and passwords to access various sub-environments and applications. SSO can also provide assistance in tracking and monitoring user accounts, making a system more secure.
However, many IT professionals do not correctly implement SSO, which more than offsets the productivity and security benefits by adding highly dangerous security vulnerabilities. A hacker who is able to access a user account under a Single Sign On system would have access to all of that user’s applications and data used in the system.
A poorly configured system does not provide adequate security to the authentications. In a Single Sign On system, authentications must pass through the prospective users’ access point. At that point, an opportunity exists to intercept the authentication and modify it to “approve” the access of an unauthorized user. Also, an improperly or poorly designed SSO system may leave the approved authentication on the user’s access point. An unauthorized user could later retrieve and use the orphaned authentication at another location for system access.
One of the most commonly used and available Single Sign On programs, made by Microsoft, is called Active Directory Federation Services (ADFS). ADFS comes “free” with Windows Server and serves as an SSO for applications and web locations that cannot be directly integrated into the native Integrated Windows Authentication used by Active Directory.
Like many Microsoft components, IT professionals can set up ADFS quickly “out of the box” using default settings. However, the default settings may create security vulnerabilities depending on the configuration of the organization’s IT environment. Moreover, ADFS presumes the Windows Server is also correctly configured and security hardened to resist online attacks. So, a review of the Windows Server configuration settings may also be required. IT professionals have also reported that adding new applications under ADFS can be very complicated and time-consuming.
Third party cloud-based Single Sign On applications are a good alternative to ADFS. Cloud-based SSO functions exactly like a standard SSO, except the authentication comes from the application’s secured, and dedicated Web location. A cloud-based applications’ primary advantage is their resource savings. An organization is not required to purchase Windows Server to implement SSO. Nor is the organization required to purchase hardware to support the SSO database and ancillary access.
Cloud-based SSO applications also provide risk management benefits. If an organization’s core systems are damaged due to some physical disaster, the Single Sign On remains functional for any surviving elements and applications in the IT environment. Some are platform independent, and can, therefore provide coverage for Microsoft, Apple, Linux, and other basic operating environments.
ETTE can help your organization build a robust SSO solution, either as a standalone element or as an integrated part of other IT projects. While we can configure an ADFS system, we also excel at cloud-based SSO implementations. ETTE can often provide cloud-based SSO for less than the ancillary hardware, license and security costs of the “free” ADFS.
As part of our Single Sign On project, ETTE provides an extensive security test of the SSO with your actual system to ensure that:
Contact ETTE to get more information about how we can perform a surprisingly affordable SSO project for your organization.
Single Sign On (SSO) is an IT environmental configuration that allows an authorized user to access their system, and all applications and data with one login. It is a simple principle that can be complicated to implement and potentially costly if implemented incorrectly.
In non-technical terms, when a user logs in, an application checks the credential against a dedicated SSO database (usually provided by a third party). The database holds all the access information for a given user. If the provided credential is correct, the Single Sign On database returns an electronic key (called an “authentication” or “authentication message”) to the user’s access point (be it physically connected or through a Web browser). The key then allows the user access to the IT environment. The authentication allows the user access to all their applications without having to re-enter credentials when moving in and out of applications. User access lasts as long as they are logged in for the current session.