Single Sign-On and a Secure Portal
- By Dean Wiech
- Jan 06, 2017
Over the last several years, some of the most common security articles have concerned passwords, potential hacking of accounts, data security and cloud applications. While these topics may seem somewhat disparate, there is actually a common thread among them: They all have security officers and end users concerned.
So how do we start to address the concerns and limit the vulnerability? The combination of single sign-on (SSO) with a secure portal and multi-factor authentication just may be the answer to the majority of the concerns. The number of credentials that an end user must remember to login into personal and work-related applications has most definitely exceeded the average person’s ability to remember them without some crutch. That may be writing them down on a sticky note, storing them in a plain text file or using the same set across multiple systems. The advent of SSO and password manager technology has greatly alleviated the need for these non-secure password storage/use methods. End users only need to remember the single set of credentials (one user name and password combination) to access the SSO login, and access to all authorized applications are automated as the SSO caches or remembers the apps for everything else.
The common concern with this approach has been if that one set of credentials is stolen or compromised, a nefarious individual now has the keys to the kingdom and can wreak havoc on the organization’s information and steal sensitive data. The most common approach to secure that one master key had been two-factor authentication (2FA). By using a form of 2FA – biometrics, fingerprint, keystroke recognition, PIN code, etc. – it is possible to secure the single password with something that only the real user would have.
Also, newer technology has evolved in the form of software enforced security and can be utilized with or without 2FA to make the use of the password even more secure. By introducing a secure portal, which becomes the only avenue that users can access their applications, it is possible to set further restrictions. These restrictions can include IP ranges, on/off company network, time of day, device type and location. Enhancing these measure even further, they can be defined per application, group or individual.
Let’s take a look at a quick example: John Smith works in the finance department as an accounts payable controller. He accesses the financial application only from inside the network between 9 a.m. and 5 p.m. from his desktop PC. However, he accesses email anywhere from 7 p.m. to 11 p.m. from either his PC or his smartphone. Using a combination of the restrictions, the finance application can be restricted to a PC with a specific IP on the network, from 9 a.m. to 5 p.m. while the email supplication can be accessed from the PC or an iOS smartphone with a specific MAC address on any network between 7 a.m. and 11 p.m. If someone were to gain access by hacking John’s password, they would not be able to access the finance application if they were physically on John’s desktop nor would they be able to access the email if they did not have John’s iOS device.
Combining the access rules with 2FA, such as biometrics, safeguards the single password needed to access the secure portal even more so. By locking down the access to especially sensitive applications to time of day, device, IP and network, it is completely feasible to minimize the risk associate with the SSO credential. The result is a happier employee -- as he or she now only needs to recall one set of user credentials -- and a happier security officer as they can be assured that access is tightly controlled.
Until the much-touted, ultimate demise of the password occurs, the best an organization can do is implement as many security fences around applications as possible and secure the password itself with either two- or multi-factor authentication.