Authentication Systems Implementation

Picking the Right Protocol for the Scenario

A consulting firm needs its employees to access a dozen SaaS applications with a single login. A hospital needs to authenticate doctors to bedside terminals using a badge tap. A telecom company needs to control which network engineers can configure which routers, with full command-level audit logging. Each of these is an authentication problem — and each demands a different protocol.

The CISSP does not expect you to trace Kerberos ticket exchanges at the packet level. It expects you to know when Kerberos is the right answer versus SAML versus RADIUS — and why.

This module covers CISSP objective 5.6: implement authentication systems. The exam presents scenarios and asks you to select the appropriate authentication protocol based on what is being authenticated, where it is happening, and what governance requirements apply.

Kerberos

Kerberos is a ticket-based authentication protocol designed for single sign-on within a trusted network. It is the default authentication protocol in Active Directory environments.

How It Works (Architecture Level)

• Key Distribution Center (KDC) — The central authority with two components: the Authentication Server (AS) and the Ticket Granting Server (TGS)
• Ticket Granting Ticket (TGT) — When a user logs in, the AS verifies their identity and issues a TGT. This TGT proves the user has authenticated without requiring them to enter credentials again
• Service Ticket — When the user needs to access a specific service, they present their TGT to the TGS, which issues a service ticket for that resource. The user presents the service ticket to the resource
• Realm trusts — Kerberos domains are called realms. Cross-realm trusts allow users in one realm to authenticate to services in another, enabling SSO across organizational boundaries within a trusted environment

When to Select Kerberos

• Internal enterprise SSO within an Active Directory or similar on-premises environment
• When mutual authentication is needed (both client and server verify each other)
• When time-limited tickets are desirable (Kerberos tickets expire, limiting exposure from credential theft)

Limitations

• Requires reliable time synchronization — tickets include timestamps, and significant clock skew causes authentication failures
• The KDC is a single point of failure and a high-value target
• Not designed for web-based or cross-organizational authentication — SAML and OIDC handle those cases

RADIUS and TACACS+

Both are AAA (authentication, authorization, accounting) protocols used for centralized access control. They solve the same general problem but are designed for different environments.

RADIUS (Remote Authentication Dial-In User Service)

• Primary use case — Network access authentication: VPN connections, wireless access points, dial-up (historically), and 802.1X port-based authentication
• Protocol — Uses UDP. Combines authentication and authorization into a single step
• Encryption — Only encrypts the password in the access request; the rest of the packet is cleartext
• Strength — Widely supported across network equipment from all vendors. The standard for network access authentication

TACACS+ (Terminal Access Controller Access-Control System Plus)

• Primary use case — Device administration authentication: controlling who can log into routers, switches, and firewalls, and what commands they can execute
• Protocol — Uses TCP. Separates authentication, authorization, and accounting into independent functions
• Encryption — Encrypts the entire packet body, not just the password
• Strength — Granular command-level authorization. You can define policies like “this engineer can run show commands but not configuration commands on core routers”

The Decision: RADIUS vs. TACACS+

• Authenticating users to the network (Wi-Fi, VPN, wired port access) → RADIUS
• Authenticating administrators to network devices (router/switch/firewall management) → TACACS+
• Need full packet encryption → TACACS+
• Need per-command authorization on network equipment → TACACS+

The exam frequently presents a scenario describing one of these use cases and asks which protocol is most appropriate. The RADIUS-for-network-access, TACACS+-for-device-administration distinction is the key differentiator.

LDAP and Directory Services

LDAP (Lightweight Directory Access Protocol) is the protocol used to query and modify directory services. It is not strictly an authentication protocol — it is the way applications talk to the identity store.

• Directory services like Microsoft Active Directory and OpenLDAP store identity information: user accounts, group memberships, attributes, and organizational structure
• LDAP bind is the operation where a client authenticates to the directory. Simple bind sends credentials in cleartext (a security concern). SASL bind supports stronger authentication mechanisms
• LDAPS wraps LDAP in TLS to encrypt the entire communication channel

LDAP is the backend that other authentication protocols rely on. Kerberos uses the directory to look up accounts. RADIUS can authenticate against an LDAP directory. SAML identity providers query LDAP to verify user credentials. When the exam asks about the identity store that supports authentication, the answer is usually a directory service accessed via LDAP.

SAML (Security Assertion Markup Language)

SAML is an XML-based standard for exchanging authentication and authorization data between organizations. It is the protocol that makes enterprise single sign-on to web applications work across organizational boundaries.

Key Components

• Identity Provider (IdP) — The organization that authenticates the user and asserts their identity. Your corporate directory is typically behind the IdP
• Service Provider (SP) — The application that trusts the IdP’s assertion and grants access based on it
• SAML Assertion — The XML document the IdP sends to the SP containing the user’s identity, attributes, and the authentication statement

When to Select SAML

• Enterprise SSO to web-based SaaS applications (Salesforce, Workday, ServiceNow)
• Cross-organizational federation where one organization trusts another’s authentication
• When the use case is browser-based and involves enterprise applications

SAML is mature and widely deployed but is primarily a browser-based protocol. For mobile apps and API-level authentication, OAuth/OIDC is the better fit.

OAuth and OpenID Connect (OIDC)

OAuth 2.0 is an authorization framework — it handles the question “what is this application allowed to do on behalf of the user?” It was not designed for authentication. OpenID Connect (OIDC) is a layer built on top of OAuth 2.0 that adds authentication — it answers “who is this user?”

OAuth 2.0

• Designed for delegated authorization: “Allow this calendar app to read my email schedule without giving it my email password”
• Issues access tokens (not identity assertions) that grant specific, scoped permissions
• The user authenticates at the authorization server, and the application receives a token with limited permissions — never the user’s credentials

OpenID Connect

• Adds an ID token to the OAuth flow that contains user identity information
• Enables “Sign in with Google/Microsoft/Apple” functionality
• The standard for modern mobile and web application authentication

SAML vs. OIDC Decision

• Enterprise web SSO between organizations → SAML
• Consumer-facing mobile/web apps, API authentication → OIDC
• Legacy enterprise applications → Often SAML (they were built for it)
• Modern applications with REST APIs → OIDC with OAuth 2.0

802.1X and EAP

802.1X is a port-based network access control standard. It prevents devices from accessing the network until they authenticate. EAP (Extensible Authentication Protocol) is the framework used within 802.1X to carry the actual authentication exchange.

• Supplicant — The device requesting network access
• Authenticator — The network switch or wireless access point that acts as the gatekeeper
• Authentication server — Typically a RADIUS server that makes the access decision

EAP methods determine how authentication actually occurs:

• EAP-TLS — Mutual certificate-based authentication. Both the client and server present certificates. Strongest EAP method but requires PKI infrastructure to issue and manage client certificates
• PEAP — Creates a TLS tunnel to the authentication server, then uses a simpler method (typically MSCHAPv2) inside the tunnel. Does not require client certificates
• EAP-TTLS — Similar to PEAP but supports a wider range of inner authentication methods

Exam signal: When the scenario describes controlling which devices can connect to the wired or wireless network, 802.1X with RADIUS is the answer. When it asks for the strongest EAP method, EAP-TLS with mutual certificate authentication is correct.

FIDO2 and WebAuthn

FIDO2 is the modern standard for passwordless authentication. It consists of two components: WebAuthn (the web browser API) and CTAP (the protocol for communicating with external authenticators like security keys).

• How it works — During registration, the authenticator creates a public/private key pair. The private key stays on the device; the public key is registered with the service. During login, the service sends a challenge, the authenticator signs it with the private key, and the service verifies the signature with the public key
• Phishing resistance — The authenticator binds the credential to the specific origin (domain). A phishing site with a different domain cannot trigger the correct credential, even if the user is fooled by the visual appearance
• Authenticator types — Hardware security keys (YubiKey), platform authenticators (fingerprint readers, Face ID), and software authenticators

FIDO2/WebAuthn is the answer when the scenario asks about phishing-resistant authentication or passwordless authentication for web applications.

Certificate-Based and Smart Card Authentication

Certificate-based authentication uses X.509 digital certificates to prove identity. The certificate contains the user’s public key, identity information, and the issuing CA’s digital signature.

• Smart cards store the user’s private key and certificate on a tamper-resistant chip. Authentication requires both physical possession of the card and knowledge of a PIN — two factors
• Common Access Card (CAC) — Used by the U.S. Department of Defense for physical and logical access
• PIV (Personal Identity Verification) — The federal civilian equivalent of CAC
• PKI dependency — Certificate-based authentication requires a functioning PKI: certificate authority, registration authority, certificate revocation (CRL or OCSP), and certificate lifecycle management

Smart card authentication is the answer for high-assurance environments — government, military, regulated industries — where strong two-factor authentication with non-exportable keys is required.

Protocol Selection Summary

• Internal enterprise SSO (on-premises) → Kerberos
• Web SSO to SaaS applications → SAML
• Mobile/modern web app authentication → OIDC + OAuth 2.0
• Network access control (Wi-Fi, VPN) → RADIUS + 802.1X
• Network device administration → TACACS+
• High-assurance government/military → Smart cards + certificate-based (CAC/PIV)
• Phishing-resistant passwordless → FIDO2/WebAuthn
• Identity store queries → LDAP/LDAPS

Pattern Recognition

Authentication systems questions on the CISSP follow these structures:

• “Users need single login for cloud applications” — SAML federation or OIDC, depending on whether the applications are enterprise (SAML) or consumer/modern (OIDC)
• “Control which commands network admins can execute on routers” — TACACS+. This is the per-command authorization differentiator
• “Prevent unauthorized devices from connecting to the network” — 802.1X with RADIUS
• “Authentication that resists phishing attacks” — FIDO2/WebAuthn. The origin binding prevents credential phishing
• “Single point of failure in the authentication infrastructure” — Kerberos KDC. If it goes down, no one can get tickets

Trap Patterns

Watch for these wrong-answer traps:

• “OAuth is an authentication protocol” — OAuth 2.0 is an authorization framework. OIDC adds the authentication layer on top of it. If the question asks specifically about authentication, the answer is OIDC, not bare OAuth
• “RADIUS encrypts the entire communication” — RADIUS only encrypts the password field. TACACS+ encrypts the entire packet body. This distinction appears regularly on the exam
• “Kerberos works well for web-based SSO across organizations” — Kerberos is designed for internal, trusted network environments. SAML and OIDC handle cross-organizational web SSO
• “EAP-TLS does not require certificates” — EAP-TLS requires both client and server certificates. If the question describes an environment without PKI, EAP-TLS is not practical — PEAP would be the alternative

Scenario Practice

Question 1

A large enterprise wants to provide its 15,000 employees with single sign-on access to 25 different SaaS applications including Salesforce, Workday, and ServiceNow. The company maintains an on-premises Active Directory as its identity store. Employees access these applications through web browsers.

Which authentication approach is MOST appropriate?

A. Deploy Kerberos constrained delegation to all 25 SaaS providers
B. Implement SAML federation with the on-premises AD as the identity provider
C. Configure each SaaS application with a direct LDAP connection to the on-premises AD
D. Deploy RADIUS servers to authenticate users to each SaaS application

Question 2

A telecommunications company needs to control administrative access to 500 network devices (routers, switches, and firewalls) across its infrastructure. The security team requires that different engineering teams have different command-level permissions — the backbone team can modify routing configurations but not firewall rules, and the security team can modify firewall rules but not routing configurations. All administrative sessions must be logged.

Which AAA protocol BEST supports these requirements?

A. RADIUS with vendor-specific attributes
B. TACACS+ with per-command authorization policies
C. Kerberos with service tickets for each network device
D. LDAP with group-based access control

Question 3

A financial services company has experienced three successful phishing attacks in the past year where attackers captured employee credentials through convincing fake login pages. The CISO wants to deploy an authentication method that is resistant to phishing even if users are tricked into visiting a fraudulent website.

Which authentication method BEST addresses this requirement?

A. Time-based one-time passwords (TOTP) sent via authenticator app
B. SMS-based two-factor authentication
C. FIDO2/WebAuthn with hardware security keys
D. Smart card authentication with PIN

Key Takeaway

Authentication protocol selection on the CISSP always comes back to context. Ask yourself: Is this internal or cross-organizational? Is it network access or application access? Is it browser-based or device-based? Is it user authentication or device administration? Does it need to resist phishing? Those five questions will consistently point you to the right protocol. Kerberos stays inside the enterprise. SAML crosses organizational boundaries through the browser. OIDC serves modern apps and APIs. RADIUS authenticates to the network. TACACS+ manages network devices. FIDO2 defeats phishing. Match the protocol to the problem.