Authentication Tools– Cisco Security Tools
Chapter 19 began the authentication discussion with
authentication, authorization, and accounting (AAA) tools. This section extends the authentication discussion with important concepts like single sign-on (SSO ) and zero trust. None of these authentication systems are foolproof, however; they all require strong passwords or passwordless authentication. The process of creating and enforcing strong passwords is important enough to merit a separate discussion.
Single Sign-On
When you first choose to log in to a website, you might encounter several options, such as log in with Google, log in with Facebook, etc.
Single sign-on (SSO) systems allow a user to provide authentication for one system through another system where they already have credentials. Many organizations—companies, colleges, governments, etc.—use SSO systems. You probably have several questions about SSO, like
• How does this work?
• Can I trust a website with access to my Google or Facebook credentials?
• Why do organizations implement these kinds of systems?
Figure 20-1 shows how an SSO system works.
Figure 20-1 How Single Sign-On Works In Figure 20-1:
1. The user creates an identity with a service offering SSO. This service might be a social media site, a Software as a Service (SaaS) provider, or another federated identity service.
2. The user browses a website.
3. The user’s browser connects to the service.
4. The service request credentials. This credential request often includes several options, such as log in using email, log in using Google, log in via Facebook, etc.
5. The user selects the provider with their identity—the provider they used in step 1.
6. The browser sends an authentication request to the SSO service.
7. The SSO service requests the user’s credentials. The browser usually opens a new tab or redirects to the SSO provider’s page for this step.
8. The user provides their credentials to the SSO service. The SSO service verifies the user’s credentials and creates a token.
This step often includes some form of two-factor authentication (2FA), like a token from an authentication application or a number texted to the user’s phone. The SSO service could also use some form of passwordless authentication.
9. The SSO service provides the token to the web browser, verifying the user’s identity.
10. The browser stores, or caches, the token. If the user browses to another website that uses the same SSO service, the browser can provide this stored token rather than asking the SSO service for authentication again.
11. The browser sends this token to the service.
12. The service verifies the token with the SSO service and then retrieves any information allowed by the service.
13. The user is logged in to the service.
This process might seem complex, but there is no simpler way to solve the problems an SSO system sets out to solve. SSO has several advantages over each service holding its own information about each user.
First, the user needs to manage only one password to log in to multiple services. Because people are generally bad at creating and remembering passwords, reducing the number of passwords individual users must remember is a significant positive aspect of SSO services.
Second, augmenting passwords and passphrases with a 2FA system, or replacing passwords with a passwordless system, is often easier when using SSO. These might increase security, protecting the user and the service.
Third, SSO systems help preserve user privacy. The service can retrieve only information about the user the SSO system allows.
If the SSO system has privacy controls, and the user takes advantage of them, SSO systems can prevent services from knowing much more than “this user is who they say they are.”
For example, most SSO systems do not use your email address as an identifying token, so the service might not even get your email address when you log in to your account.
The SSO service does not know what kind of business you transact with a service, either. Dividing your identity and transactions into two services is a basic form of privacy-preserving information partitioning.
SSO systems also have negative aspects. One common criticism of SSO systems is an attacker gaining access to your SSO credentials gains access to all your accounts. Some organizations or countries may also block access to SSO systems, so users who rely on SSO can no longer access any of their accounts.
Some countries control the SSO services their citizens can use to impose social controls. In some cases, countries restrict what individuals can purchase or do by not allowing them to use their SSO credentials to interact with some services.
Zero Trust
Chapter 19 illustrated the network edge as a sort of walled fortification—how engineers once built networks. There was the inside of the network, where all the trusted users and traffic lived, and the outside of the network, where all the untrusted users and traffic lived, a fortified exterior defense system, and then a demilitarized zone (DMZ) where devices that need access to both inside and outside resources lived.
As noted in Chapter 19, this view of the network is still useful for explaining security terms. Still, it is no longer a useful model for building real-life network security because
• Cloud connectivity and the digitization of business means networks no longer have an “inside” and an “outside.”
• There are no trusted users any longer. Employees, contractors, and other “trusted users” might present a smaller threat than an “outsider,” but they present a threat network operators must mitigate.
You might wonder about the second point here: Why are insiders a threat? The primary reason insiders are considered a threat in modern systems is social engineering attacks. A user with the best intentions can still be tricked into allowing an attacker to access business-critical systems.
How should engineers design systems in a world with lowered levels of trust? Engineers can use zero trust principles.
Zero trust is a security framework requiring users to authenticate each time they access a service or data. It assumes there is no network edge.
Figure 20-2 illustrates the components and terminology of a zero trust system.
Figure 20-2 Components and Terminology of a Zero Trust System
The terminology differs slightly from a traditional security system, but many concepts are the same. In Figure 20-2:
• The subject is the user, a process, or even software running on a device (such as your refrigerator).
• The system is the hardware, such as a host, network middlebox, or thing (such as your refrigerator).
• The policy enforcement point (PEP ) is the device blocking or allowing traffic flows. The PEP includes the configuration or other rules the device follows to enforce policies.
• The resource is a database, application, or anything else you normally access from a host or device.
• The policy administrator is the person or organization making the rules about accessing resources.
• The policy engine is the security plan.
Zero trust systems rely on continuous authentication, authorization, and accounting to protect resources against threats inside and outside the network.