← Module 1: Secure Software Architecture
Inquiry Question 1: How are secure systems designed?
Explain the role of authentication and authorisation in restricting access to a system, and identify common implementation methods including multi-factor authentication and role-based access control
A focused answer to the HSC Software Engineering Module 1 dot point on authentication and authorisation. The difference between the two, multi-factor authentication, role-based access control, the worked SaaS-app example, and the traps markers look for.
Have a quick question? Jump to the Q&A page
What this dot point is asking
NESA wants you to clearly distinguish authentication (who you are) from authorisation (what you can do), and describe the standard implementations of each: passwords, multi-factor authentication, single sign-on, role-based access control, and the principle of least privilege.
The answer
Authentication: proving who you are
Authentication confirms a user's identity. It relies on one or more factors:
- Something you know: a password or PIN.
- Something you have: a phone (for SMS or authenticator app codes), a hardware security key (YubiKey), or a smart card.
- Something you are: a biometric like a fingerprint or face scan.
Single-factor authentication (just a password) is weak. Multi-factor authentication (MFA) combines two or more factor categories, dramatically reducing the success rate of credential-theft attacks.
Authorisation: deciding what you can do
Once a user is authenticated, authorisation governs which actions they can perform and which resources they can access. The two dominant models:
- Role-based access control (RBAC). Users are assigned roles; roles have permission sets. Easy to administer at scale. Used in most SaaS apps.
- Attribute-based access control (ABAC). Permissions are computed from user attributes, resource attributes, and environmental context (time of day, IP address). More flexible, more complex.
Least privilege
Whichever model is used, the principle of least privilege says give each user only the permissions strictly needed for their role. A junior support agent does not need access to billing data. A read-only auditor never needs write permissions.
Implementation in Python (Flask)
from flask import Flask, request, abort
from functools import wraps
ROLES = {
"alice": "admin",
"bob": "auditor",
"carol": "support",
}
PERMISSIONS = {
"admin": {"view", "edit", "delete"},
"auditor": {"view"},
"support": {"view", "edit"},
}
def authenticate(username, password):
# ... verify credentials against hashed password store ...
return ROLES.get(username)
def require_permission(perm):
def decorator(f):
@wraps(f)
def wrapper(*args, **kwargs):
role = request.headers.get("X-Role")
if perm not in PERMISSIONS.get(role, set()):
abort(403)
return f(*args, **kwargs)
return wrapper
return decorator
@app.route("/users/<id>", methods=["DELETE"])
@require_permission("delete")
def delete_user(id):
# ... delete logic ...
return "", 204
The authenticate function checks identity. The require_permission decorator checks authorisation. Separating the two is the standard pattern.
Past exam questions, worked
Real questions from past NESA papers on this dot point, with our answer explainer.
2024 HSC5 marksDistinguish between authentication and authorisation, and describe how a system administrator could combine multi-factor authentication and role-based access control to secure an admin portal.Show worked answer →
Authentication is verifying who a user is. Authorisation is deciding what an authenticated user is allowed to do. Authentication happens first; authorisation depends on the identity it produces.
A typical admin portal combines both with two extra layers.
Multi-factor authentication (MFA). When the admin signs in, they supply something they know (a password) and something they have (a one-time code from an authenticator app or hardware key). Even if the password leaks, the attacker still needs the second factor. MFA reduces the risk of credential-theft attacks (phishing, brute force) to near zero.
Role-based access control (RBAC). After authentication, the system assigns the user a role (for example, super-admin, read-only-auditor, support-agent). Each role has a permission set. The super-admin can edit billing settings; the auditor can only view audit logs; the support agent can reset user passwords but not view payment cards.
Together, MFA stops attackers reaching the portal, and RBAC limits the damage if a low-privilege account is compromised. Markers reward the clear distinction between authentication and authorisation, named MFA factors, and a concrete RBAC example.
Related dot points
- Describe how the confidentiality, integrity and availability (CIA) triad is applied to the design of secure software
A focused answer to the HSC Software Engineering Module 1 dot point on the CIA triad. Confidentiality, integrity, availability, how each is enforced in a real system, the worked banking-app example, and the traps markers look for.
- Describe how hashing and salting protect stored passwords, and identify weaknesses in storing passwords in plain text or with reversible encryption
A focused answer to the HSC Software Engineering Module 1 dot point on password hashing. Why passwords are hashed and not encrypted, salting, slow hash functions like bcrypt, the worked example, and the traps markers look for.
- Identify the OWASP Top 10 web application security risks and describe mitigations for each
A focused answer to the HSC Software Engineering Module 1 dot point on the OWASP Top 10. Each risk, an example, and a mitigation, the worked broken-access-control example, and the traps markers look for.