UPI Study › Courses › Ethics in Technology › Free lessons › Lesson 10.2 Free with a free account
Authentication, Access Control, and Identity Verification
Ethics in Technology · Chapter 10: Defending the Network: Firewalls, VPNs, and Security PoliciesSection 10.2 · lesson 53 of 11615 min · free with a free account
Free preview
Create a free account to keep watching
It takes a minute and costs nothing. Your free account unlocks all of Chapter 1 and 3 more lessons of Ethics in Technology.
Lesson complete
Earn the 3 college credits for Ethics in Technology
Enrolling adds a quiz after each lesson, the graded work and the official transcript. Recommended for credit by NCCRS.
Next lesson: Encryption Protocols and Secure Communication Standards →← Fundamental Concepts of Network ProtectionNext lesson: Encryption Protocols and Secure Communication Standards →
In this lesson
Authentication evidence, authorization policy, and the working life of an account.
- Distinguish identity claims, evidence, and permissions.
- Compare factors, phishing resistance, and biometrics.
- Explain federation, Kerberos, RADIUS, and access models.
- Manage account lifecycles and ethical responsibilities.
Free study notes
Get this lesson's notes by email
The key points and 4 practice questions with answers, in your inbox. One email, free.
One email. Unsubscribe in one click.
Transcript
Everything said in the video, section by section (1,679 words). Read along, or search it.
Chapter 10
Identity and Access
Identity systems distinguish a claim, evidence supporting it, and the permissions that follow. Identification supplies the claimed identity, while authentication evaluates appropriate evidence. Authorization then decides what resources and actions are permitted. Three factor categories are knowledge, possession, and inherence. Multiple knowledge questions do not become multifactor authentication simply because there are two of them. We compare second factors by their actual protections, especially resistance to a convincing fake sign-in page. Biometric matching uses similarity thresholds, with accuracy, privacy, and accessibility consequences. Single sign-on and federation concentrate both protection and risk. Kerberos uses tickets, while RADIUS helps network equipment obtain central access decisions. Access models and account lifecycle processes keep permissions justified over time. Bank, door-access, hospital, and manufacturing examples connect technical choices with ethical responsibilities.
Claims, Evidence, and Permissions
Identification, Authentication, and Authorization Answer Different Questions
Providing a username identifies a claimed account, rather than proving control of it. Authentication supplies evidence, such as control of a registered authenticator. Authorization applies policy to the requested resource and action. Knowledge includes a password or a local activation PIN. Possession includes a device-held key, security key, smart card, or appropriate code generator. Inherence uses a biometric characteristic, such as a fingerprint or face. Each category brings different loss, theft, accuracy, privacy, or implementation risks. A password and security question remain within the knowledge category. Security-question answers may be discoverable, and NIST does not accept them as suitable digital authentication secrets. Location, timing, and behavioral observations can support a risk decision without replacing a required factor. Evaluate the actual evidence and policy, rather than counting screens or treating a successful identity claim as unlimited permission.
Second-Factor Choices
Phishing Resistance Depends on the Protocol, Rather Than the Shape of the Device
Second factors differ in the attacks they resist. Text-message codes add possession evidence, but number redirection, interception, and fake-site relay remain concerns. Authenticator-app codes avoid text-message delivery while still allowing an impostor site to relay typed output. Simple push approvals can be accepted mistakenly after repeated unwanted prompts. Number matching requires a more deliberate interaction and mitigates simple approval fatigue. It does not become phishing-resistant authentication merely by displaying a number. Appropriate FIDO security keys and passkeys bind cryptographic responses to the relying party. Not every hardware token uses that method; some generate ordinary transferable codes. A passkey is multifactor when possession is combined with required local PIN or biometric verification. Physical touch alone demonstrates presence, rather than a separate knowledge or biometric factor. For the bank, replace the second knowledge question with suitable stronger authentication, accessible alternatives, and equally careful recovery.
Biometric Matching
A Similarity Threshold Trades Different Kinds of Error
Biometric matching begins with a sensor reading affected by quality and presentation conditions. The system extracts features into a mathematical representation and compares them with an enrolled reference. A chosen similarity threshold determines whether the comparison matches. A false match accepts an unrelated reference, while a false non-match misses the genuine reference. False acceptance and rejection describe corresponding harmful decisions in the wider system. Within a fixed system, stricter thresholds generally reduce impostor matches and increase missed genuine matches. The equal-error point is where measured comparison error rates coincide. That point is a summary, rather than automatically the correct threshold for every use. The source curve illustrates the tradeoff; its percentages are not product measurements. Algorithm, population, capture conditions, configuration, and faults can also affect results. A rejected phone reading therefore does not prove the phone is simply strict or necessarily functioning correctly.
Biometric Design and Ethics
Protect Sensitive References, Offer Alternatives, and Assess the Actual System
Biometric references are sensitive because the underlying face or fingerprint is difficult to replace. Some template-protection methods allow revocation, but their availability is limited. Evaluate the chosen system across affected people and realistic capture conditions. Demographic differences and image quality vary by algorithm, so one overall accuracy number is insufficient. Provide workable alternatives for disability, unreliable readings, or people who cannot use the proposed method. Presentation-attack detection and trusted sensors help, without creating a universal guarantee. Local biometric verification can unlock a device-held credential without sending the biometric reference to the service. Central storage creates additional security, retention, consent, and reuse obligations. For workplace doors, compare badges and device credentials against the proposed system using actual risk and performance. Employment power can undermine meaningful choice, while later attendance or surveillance reuse changes the purpose. Any necessary central use needs documented justification, safeguards, oversight, and alternatives rather than a claim that convenience settles the ethics.
Single Sign-On and Federation
Centralize Authentication Carefully, While Keeping Resource Permissions Separate
Single sign-on lets a supported authentication session serve several integrated applications. Federation lets an identity provider supply a trusted assertion to a relying service, potentially across organizations. The service validates that assertion and still applies its own resource permissions. This can reduce repeated password handling and support consistent strong authentication. It also concentrates the importance of provider administration, signing keys, trust relationships, enrollment, and recovery. Connected-service lifecycle changes need verification. Disabling one account may not immediately end every existing session, token, local account, or independent service. Central sign-in records can be useful while containing sensitive information. They do not necessarily record every action within each application. Provider compromise or outage can affect connected services, with scope depending on the actual design. Protect availability and recovery alongside identity evidence, rather than assuming centralization either guarantees safety or compromises everything automatically.
Kerberos
Tickets Authenticate to Services Without Sending the Password to Each One
Kerberos is a ticket-based system widely associated with enterprise domain authentication. The client first establishes identity with the authentication service in the key distribution center. It receives a ticket-granting ticket and associated session material. The client then uses that ticket with the ticket-granting service to request a particular service ticket. It presents the service ticket and an authenticator to the intended server. Where requested and implemented, mutual authentication also verifies the service. In standard password-based authentication, password-derived cryptographic material is used, while the password itself is not sent across the network. Password provisioning or changes are separate processes. Configured ticket lifetimes limit validity, but compromised endpoints can expose usable tickets and session material. Synchronized time, suitable initial authentication, and protected service keys remain important. The key distribution center needs strong protection because compromise can enable serious impersonation within its authority.
RADIUS and AAA
Network Equipment Requests a Central Decision, then Enforces the Result
RADIUS means Remote Authentication Dial-In User Service and supports centralized network-access decisions. A network access server, such as an access point or gateway, acts as the RADIUS client. It requests authentication and authorization, then enforces the returned result. The first part of the three As establishes who or what is connecting. Authorization decides what that connection may reach, including suitable returned policy or network assignment. Accounting records supported session events and usage for investigation or other justified purposes. These functions support enterprise wireless, VPN gateways, and network port access. Centralization does not mean the edge equipment is automatically free of credential material. Handling depends on the authentication method and transport, and some exchanges carry password-related material through that equipment. Protect methods, channels, device administration, and the relevant secrets or certificates. Authentication alone does not establish every resource permission, while accounting records need justified collection, access, and retention.
Access-Control Models
Distinguish the Policy Basis, and Expect Combinations in Practice
Discretionary access lets an authorized owner control resource permissions within system constraints. This supports flexible sharing while potentially dispersing policy choices. Mandatory access uses centrally enforced classifications or labels that ordinary owners cannot override. Role-based access attaches permissions to suitable organizational roles. It aligns access with jobs, while excessive roles and accumulated exceptions need control. Attribute-based access evaluates subject, resource, action, and environmental attributes against policy. Contextual decisions depend on reliable attributes, tested rules, and understandable conflict handling. Roles can themselves be attributes, and role-based systems can include constraints or combine with context. The source's flexibility arrow is a teaching simplification, rather than a universal complexity ranking. Most practical designs can combine models, so explain the resulting decision rather than relying on labels. Test intended grants, denials, stale information, exceptions, and changing roles, with an owner accountable for review.
Identity and Access Management
Control Joining, Moving, Leaving, Privileged Use, and Review
Identity and access management covers the account's working life, rather than one sign-in. Joining should grant justified role access instead of copying a colleague's accumulated privileges. Moving should add needed rights and remove previous ones unless a current reason justifies retention. Leaving requires relevant account, credential, external-service, and session revocation, followed by verification. Privileged access needs appropriate approvals, limited duration, and useful evidence. Periodic reviews must examine current necessity rather than approve every entry in bulk. The manufacturing manager's three earlier jobs illustrate privilege accumulation. Each grant may have been justified then, while their combined present access crosses payroll, customer records, and factory control. Remove stale rights and restore appropriate separation of duties. Automation, responsible owners, meaningful review, and privileged access management address the lifecycle failure. Application, script, and service identities also need ownership, limited rights, suitable credential management, review, and retirement.
Hospital Scenario
Combine Role Structure, Care Context, and Accountable Emergency Exceptions
Hospital records need policy that supports care without blanket access to every patient's information. Roles provide structure for nurses, physicians, pharmacy, billing, and administration. Attributes can add the relevant care relationship, patient, action, device, and working context. Mandatory restrictions may enforce particular sensitive-data or organization-wide requirements. A clinician's job title alone need not justify reading every record. Emergency care may require an authorized break-glass procedure instead of waiting for routine approval. The exception needs a recorded reason, appropriate alert, and later review. Attributable access evidence supports investigation, while those records also need protection. Test necessary clinical workflows, failure conditions, and review responsibilities. Avoid unrestricted personal sharing decisions for clinical records. The combined policy should remain understandable to clinicians and administrators, with accountability to the people affected.
Ethics and Review
Strong Identity Controls Must Remain Proportionate, Accessible, and Accountable
Ethical identity design asks whether legitimate users can actually authenticate and recover access. A smartphone, steady hands, consistent biometric readings, or reliable connectivity cannot be assumed for everyone. Match verification strength and data collection to the protected resource and actual risk. Reading a public catalog rarely justifies collecting biometric references solely for access. Explain and limit uses of identity and network records instead of silently extending them into surveillance. Protect central providers, keys, sensitive records, and exceptional access with proportionate oversight. The bank needs distinct factors and protected recovery. Facial-recognition doors require a justified need, tested performance, safeguards, and alternatives. Kerberos retains ticket and central-key risks, while hospital access needs context and accountable emergencies. Job changes require removing old rights, and automated identities need lifecycle care too. Verify legitimate permissions, preserve accessibility, apply suitable law and policy, and manage identity evidence throughout its working life.
About Ethics in Technology at UPI Study
Ethics in Technology (Computer Science 195) is a self-paced online course of 116 video lessons in 15 chapters, from cybersecurity basics, privacy and surveillance to big data, hacking, malware, network defense, intellectual property, cybercrime, encryption, emerging technology and digital citizenship. It carries a NCCRS credit recommendation for 3 semester credits.
Every lesson transcript is free on pages like this one, and the videos are free with a free UPI Study account. Enrolling adds a practice quiz after each lesson, the graded work and final exam that earn the credit, lifetime access, and an official transcript on completion. UPI Study has helped over 130,000 students with college credits. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Enroll now → Course details Download the syllabus All Computer Science courses
Compare: Cybersecurity vs Ethics in Technology · Which ethics course?
Why take it here
Why students take Ethics in Technology with UPI Study
Where the credit goes
Universities that work with NCCRS
Ethics in Technology carries a NCCRS credit recommendation. These universities work with NCCRS; some are UPI Study's signed partners. ACE and NCCRS have over 2,100 cooperating colleges that will consider accepting credits; the final decision is with the universities.
Thomas Edison State UniversitySigned partner
University of the PeopleSigned partner
Charter Oak State CollegeSigned partner
Strayer UniversitySigned partner
Columbia Southern UniversitySigned partner
Indiana TechSigned partner
Penn StateWorks with NCCRS
Southern New Hampshire UniversityWorks with NCCRS
SUNYWorks with NCCRS
+many more cooperating universitiesFind my college →Find my college → Not listed? Ask Athena in the corner of this page, or book a 15-minute call.
FAQ
Questions students ask us
About Authentication, Access Control, and Identity Verification
What is the difference between identification, authentication, and authorization?
Why are a password and a security question not multifactor authentication?
Which types of MFA are phishing-resistant?
How does Kerberos authentication work?
About the Ethics in Technology course
How many college credits is Ethics in Technology?
How much does Ethics in Technology cost and what is included?
Which universities accept UPI Study credits?
How long does Ethics in Technology take?
How are the exams done?
How do my credits reach my college?
Ready for the full course? Earn 3 credits in Ethics in Technology.
116 video lessons, a quiz after each one, and the graded work that earns the credit. Recommended for credit by NCCRS.
3 credits · NCCRSEnroll →