Single Sign-On, Single Log-On, Social Log-On – What are the Differences?

Single Sign-On is a heavily used term in the IT industry. Sometimes inaccurately used to refer to any tool that simplifies login for the end-user.

The 3 most commonly used forms on sign-on are:

Single Sign-On: The user is required to log-in only once on Active Directory or another directory service. After logging in, the user is prompted to enter credentials to access apps/resources that integrate with the directory service.

Single Log On (aka centralised authentication): The user logs in on Active Directory or another directory service and all apps/resources using the same credentials. The user will see log-in dialogs for each individual app or resource requiring these credentials.

Social Login: A form of single sign-on using existing information from a social networking or SaaS service (such as LinkedIn, Facebook, Microsoft services) to sign into a 3rd party website/app instead of creating a new set of credentials specifically for that website/app. It is designed to simplify logins for end users as well as provide more and more reliable demographic information to web application developers.

It is important that the distinction between the different forms of sign-on are understood as they all have different use cases, and levels of security.

Planning on enabling SSL decryption? Watch out for this…

SSL is a commonly used terminology when discussing HTTPS. It is a growing category of network traffic that delivers private and secure communication. Unfortunately, it can also be used inaptly to hide application usage, transfer data to unauthorised parties, and mask malicious activity.

SSL Decryption is the ability to view inside SSL traffic as it passes through a firewall.

Quick UDP Internet Connection (QUIC) is Google’s experimental, low-latency Internet transportation protocol over UDP.

Chrome browsers have the QUIC protocol enabled by default. When users try to access Google apps using the Chrome browser, a session to a Google server is established using QUIC instead of TLS/SSL. This means your firewall won’t be able to decrypt it using SSL decryption.

To overcome this, you need to create a security policy in the firewall to block the QUIC application. On some firewalls this is done by creating a security policy that specifically denies the quick application and, on some others, it’s a checkbox. Either way, once QUIC is blocked, Chrome will seamlessly revert back to good old SSL and your firewall will be able to decrypt it.

SSL Decryption Is a Must Have

SSL Decryption Is a Must Have – But not quite enough for assuring the Cyber-Welfare of School Students

IT leaders from schools will agree that SSL is a good first step into achieving greater visibility into network traffic. However, it is not quite enough to establish cyber-welfare for students.

SSL decryption is vital for enhanced network security. It is a great feature to have on a layer 7 firewall. As more web traffic moves towards SSL, firewalls can no longer determine the identity of the applications that are passing through them leveraging simple constructs such as port numbers.

Also, in most cases, firewalls perform decryption, identify apps, check for malware, check for potential data breaches etc. These are great for network security but not enough for cyber-welfare. Where do firewalls fall short? They aren’t enough to expose whether someone is lookup up suicide hotline or getting cyber-bullied constantly. This is where cyber-welfare software, such as Saasyan’s Assure product comes in to play. Assure allows schools to have best of breed network security and the functionality required to provide cyber-welfare to students.

How do tech savvy students bypass the school’s firewall?

Network administrators working for schools are usually more concerned about tech-savvy students trying to gain open access to the Internet by bypassing their firewalls or web filters than outsiders trying to hack into the school’s network and systems.

These tech-savvy students employ a variety of methods to achieve this. Some of the more common ones are listed below:

  1. They establish an SSL tunnel through the school’s firewall using readily available and free VPN clients such as OpenVPN and DotVPN.
  2. They publish a terminal server running at home over TCP port 80, log on to the terminal server from school and access any site through the terminal server. Non- application-aware firewalls are unable to tell the difference between this kind of traffic and Web traffic as both of them to use TCP port 80.
  3. They use smartphones as a wireless access point to gain full access to the Internet via their 3G/4G/5G connection.

This is precisely why we at Saasyan, recommend the use of best of breed firewalls such as those provided by Fortinet and Palo Alto.

Our software, Assure, allows ICT and non-technical staff in schools to be notified when a student is using a VPN on the school network – and who it is, even if the student is using their personal device. Visit our Assure page, or contact us if you would like to know how your school can use Assure to protect against the internal threat of VPN software.