Authentication And Authorization Across VMs | Ethereal Lab Course Materials

Overview

Registration and login across the App, RabbitMQ, and DB VMs
Identity, sessions, and access to protected resources
Evidence for the Module 4 authentication and authorization milestone

Prerequisite: the Module 3 role-based VM baseline and logging system, with working RabbitMQ communication between roles

Authentication, Authorization, And Sessions

Authentication checks who is signing in, for example by verifying a password against a stored password hash
Authorization checks whether the current user may reach a resource or perform an action
A session lets the app recognize an authenticated user on later requests without asking for the password each time
Registration creates an account; login verifies it; a protected action requires an active session and the appropriate permission

Knowing an email address, seeing a login form, or hiding a link in the browser does not authorize a server action

Account Roles And Permissions

A permission allows a particular action on a resource; an account role groups additional permissions

General users start with no assigned roles
- They can use the application's normal user features
The required admin role grants maintenance access for user accounts, role assignments, and the application's own data
The server checks permissions for each requested action
For private records, also check which account owns the record

Project Checkpoints

Checkpoint	Working behavior
Module 4 / Milestone 2	Registration, login, a persistent session, logout, and one protected application action
Module 6 / MVP	An authenticated, authorized admin uses browser pages to create, read, update, and delete the named team-owned records
Project Showcase	The remaining approved product scope, including users updating their own profiles and admin account/role maintenance

Profile and admin account/role-management pages belong in the MVP when the approved proposal maps them there; otherwise they remain required by the Project Showcase

Password security and the service boundaries apply throughout this progression

Service Responsibilities

Service	Responsibility
App VM	Handles browser requests, sessions, and server permission checks
RabbitMQ VM	Carries account-operation requests and replies
DB VM	Stores accounts and verifies credentials
API VM	Handles approved project integration work; participates in authentication where the design requires it

The App has no direct DB connection or DB credentials

The Module 3 fanout exchange sends log-event copies to each VM's queue. Account operations use requests with replies delivered to the waiting caller

Restrict broker access so only the intended DB worker can publish authentication results to the App's reply route

Authentication Requests And Replies

The team defines the request and reply fields, routing, timeout, and malformed-message behavior before implementation
A correlation ID pairs a reply with its waiting request; handle late or duplicate replies without creating another session
Broker permissions control which worker may publish results on the App's reply route
On timeout or an unavailable DB worker, report a retryable failure and create no session

The example below shows two pending login requests

The App is waiting for two fictional test-account logins: Ada's request login-A and Sam's request login-B

The DB worker replies in reverse order: login-B fails, then login-A succeeds

How does the App determine which pending login each reply belongs to?

Match each reply's correlation ID to the pending request, then apply only that request's result

Reply	Waiting request	Result
`login-B`	Sam's login	Reject; no session
`login-A`	Ada's login	Create Ada's session

The correlation ID identifies the waiting request. Verified credentials and permissions determine access

Registration And Password Storage

Collect at least an email address and password, then reject invalid input and a duplicate account
A password hash is a one-way derived value for checking a password without storing the original
A salt is fresh random data used for each stored password; the library handles it so equal passwords do not produce equal stored hashes
The DB VM stores the account record and uses a password-hashing library that makes guessing costly; a fast general-purpose hash such as SHA-256 is unsuitable here
Keep passwords and session secrets out of source, logs, screenshots, and persistent queue history

The App waits for a registration result before telling the user the account was created

The DB worker checks the submitted password with the password library's verification operation
An unknown email and a wrong password both fail; the user sees the same generic invalid-credentials message
Internal failure records distinguish the reason without recording the submitted password or other secrets
A successful result lets the App create a new session for that user

A broker delivery confirmation alone does not prove that credentials were verified

Session Creation, Expiry, And Logout

After successful login, issue an unpredictable session credential and associate it with the authenticated identity using the team's chosen strategy
On a later request, validate that credential and check whether the session is still valid
Apply the authorization rule to the requested resource or action on the server
Logout invalidates the session; expiry also ends access

The team chooses a session strategy and a reasonable expiry, then demonstrates navigation, expiry policy, and logout behavior

Example strategy: the App stores session state and sends a random session ID to the browser

Ada logs in; the App creates a fresh random ID mapped to Ada's account and an expiry
The browser stores the ID in a cookie and sends it on a later request to the App
The App looks up the valid session and checks Ada's permission before returning protected data
Logout invalidates the server record; the old ID no longer grants access

The session ID is a credential linked to the account; the App validates it on protected requests
Use HTTPS and the framework's session/cookie protections
The team chooses a session strategy supported by its stack

Server Permission Checks

Consider an author-created saved-items app: a private saved item belongs to the account that saved it; only that account may open or change its saved item

Request state	Expected protected-action result
No session	Deny and ask the user to sign in
Ada's valid session and Ada's item	Permit the action
Ada's valid session but Sam's item ID in the URL	Deny that action
Session invalidated by logout	Deny, even if an old page remains visible

What would happen if the App hid the button but never checked the server action?

A direct request could still reach the action; the server must enforce the decision

Manage App Data In The Browser

Continue the saved-items example: admins maintain the app's own catalog entries, while users manage their private saved lists

CRUD means create, read, update, and delete

At MVP, admins must manage the proposal's named team-owned records through browser pages
Changes must persist in the team's database
API endpoints or command-line tools alone do not satisfy the web-interface requirement
Deny signed-in non-admin users access to both pages and server actions

Operation	Browser behavior in this example
Create	Add an app-owned catalog entry
Read	View stored catalog entries
Update	Edit an entry and see the saved change after refresh
Delete	Remove a selected app-owned entry

Provider-owned data stays read-only unless the provider supports changes and the instructor approves them separately. A local copy gives no permission to change provider records

Authentication Failures

Observation	Safe behavior to design and test
MQ or DB worker unavailable	Show a retryable failure; do not create a session
Reply arrives after timeout	Reject it as stale or reconcile it without a second success
Malformed request	Reject it without crashing the worker or exposing secrets
Protected request after logout	Deny it on the server

Use the existing logging system to record useful authentication failures without logging credentials or session identifiers

Knowledge Check 1

Questions

How do authentication and authorization differ?
Why does a request/reply exchange need a correlation ID?
Why use a password hash instead of storing the original password?
What must happen to a session on logout?

Answers

Authentication verifies identity; authorization decides whether that identity may perform an action
It matches a reply to the request whose result the App is waiting for
It stores a derived verifier and makes guessing costly if account data is exposed
It must be invalidated so later protected requests are denied

Use Next to reveal each answer

Knowledge Check 2

Questions

What is an account role?
What does CRUD mean?

Answers

An account role groups additional permissions above the general user baseline
Create, read, update, and delete

Use Next to reveal each answer

Key Terms And Further Learning

Key Terms

Authentication: verifying identity
Authorization: checking permission for an action
Session: recognizing a signed-in user on later requests
Password hash: a derived password verifier
Salt: random data unique to a stored password hash
Correlation ID: pairing a reply with its request
Role: a group of additional account permissions
CRUD: create, read, update, and delete

Further Learning

Summary

Account operations travel from App through RabbitMQ to DB; the DB VM stores account records
A successful login starts a session; every protected action still needs a server-side authorization check
General users start without account roles; admins need authorized browser maintenance pages
Milestone 2 demonstrates the live auth path and each member's contribution; the MVP adds browser CRUD for the named team-owned records

Next presentation: MVP Feature Work