Tony CantaveMy CompTIA Security+ Notes on Authentication, Authorization and Accounting

When I studied for CompTIA Security+, the section that tripped me up at first was not encryption or attacks. It was the vocabulary around identity. Authentication, authorization and accounting sound similar, and the exam loves to test whether you can tell them apart. Once I tied each term to something I had already done at work, it clicked. These are the notes I wish I had on day one.

AAA in one sentence each

• Authentication answers "who are you?" It is the step where you prove your identity, usually by signing in.
• Authorization answers "what are you allowed to do?" It happens after you are identified and decides which files, systems or actions you can reach.
• Accounting answers "what did you do?" It is the record of activity: logins, changes, failed attempts and the time each one happened.

A simple way to remember it is a warehouse. Showing your badge at the door is authentication. The badge only opening the shipping dock and not the office is authorization. The door system recording that you entered at 6:02 AM is accounting. I spent years in logistics and production, and every site I worked at ran on some version of this, long before I knew the term.

The authentication factors

Security+ groups proof of identity into factor types. Knowing which bucket something belongs in is worth easy points.

• Something you know: a password, a PIN, the answer to a security question.
• Something you have: a phone with an authenticator app, a hardware key, a smart card.
• Something you are: a fingerprint, a face scan, other biometrics.
• Somewhere you are: location based checks, such as only allowing sign in from a certain country or network.
• Something you do: behavior patterns, such as typing rhythm.

The key exam detail is that multifactor authentication means factors from different categories. A password plus a PIN is still only "something you know" twice. A password plus a code from an app on your phone combines two categories, so it counts as multifactor.

Authorization models

Once a person is identified, the system needs a rule for what they can reach. These are the models I made flashcards for.

• Discretionary access control: the owner of a resource decides who gets access. Sharing a folder from your own drive is a good example.
• Mandatory access control: access is set by labels and clearance levels that users cannot change. Think classified documents.
• Role based access control: permissions attach to a job role, and people get the role. A new dispatcher gets the dispatcher role and everything that comes with it.
• Rule based access control: access depends on conditions, such as time of day or the network you are on.
• Attribute based access control: decisions use several attributes together, such as department, device type and location.

Role based control is the one I see most in real business software. When I worked with ERP systems in manufacturing, setting someone up correctly meant picking the right role, not hand picking a hundred permissions.

Least privilege and separation of duties

Two principles show up again and again.

Least privilege means giving each account only the access it needs to do its job, and nothing more. If a laptop or account is compromised, the damage stays small.

Separation of duties means no single person controls an entire sensitive process. The person who approves a payment should not be the same person who sends it. Manufacturing has the same idea with quality checks: the person who builds the part is not the one who signs off on it.

Accounting is more than logs

Students often treat accounting as an afterthought. On the exam and in real life it matters. Good accounting means logs are collected, time stamped accurately, stored somewhere an attacker cannot easily edit, and actually reviewed. A log nobody reads does not help anyone. A good habit to practice in a home lab is sending firewall and sign in logs to one place and reviewing failed logins on a regular schedule.

Single sign on and federation

Single sign on lets you authenticate once and reach several applications. Federation extends that trust across organizations, so you can use one identity provider to sign in to a partner's service. The protocols to recognize by name are SAML, OAuth and OpenID Connect. A quick way to sort them: SAML is common for enterprise web sign in, OAuth is about granting an app permission to act on your behalf, and OpenID Connect adds identity on top of OAuth.

How I studied this section

I wrote each term on one side of a card and a real example from my own work on the other. Then I quizzed myself by reading the example and naming the term. Turning abstract words into situations I had lived through made the difference. If you are working toward Security+, try building your own examples instead of memorizing someone else's. The definitions stick when they are attached to something you already understand.