Access Control And Identity Inside Applications

🎯 CISSP Lens

Pick answers that align business risk, governance intent, and practical control execution.

Access control in applications is about three related ideas:

• Authentication, proving who or what is acting.
• Authorization, deciding what that identity is allowed to do.
• Accounting, recording what was done.

Good application designs apply all three consistently at multiple layers.

Authentication patterns

Common patterns include:

• Session based authentication using cookies after login.
• Token based authentication using JWT or opaque tokens.
• Federated identity using SAML or OpenID Connect.

Regardless of mechanism, secure designs:

• Protect credentials in transit and at rest.
• Use secure session management with timeouts and rotation.
• Support multi factor authentication where risk justifies it.

Authorization models

The two main models you will encounter are:

• Role based access control (RBAC): permissions group into roles, and users are assigned roles.
• Attribute based access control (ABAC): decisions use attributes of users, resources, and context, such as department, classification, or location.

RBAC is simpler and works well in many business systems. ABAC can support rich policies but requires more design and governance.

Enforcement in applications

Access control should be enforced on the server side, not only in the user interface.

Good practices:

• Centralize authorization logic where possible, for example in middleware or a dedicated service.
• Protect every API endpoint that returns sensitive data or performs sensitive actions.
• Ensure the data layer enforces constraints that align with application logic.
• Require re authentication for especially sensitive operations.

📋 Domain cross-reference

📋 Domain cross-reference

For the exam:

• Distinguish clearly between authentication, authorization, and accounting.
• Recognize RBAC and ABAC examples and choose models that fit business needs.
• Emphasize server side checks and defense in depth.
• Consider usability and administrative overhead in design choices.

Domain 8 also intersects with Domain 5 on identity and access management, but here you focus on how applications consume and enforce identity information.

An internal admin interface hides certain links unless the user is marked as an admin in the UI. However, the underlying API endpoints do not check authorization.

An attacker with a normal account inspects network traffic and discovers admin endpoints. By calling these directly, they can perform actions intended only for administrators.

The fix involves:

• Moving authorization checks into the API layer, validating user roles and scopes on every request.
• Adding logging for all administrative actions.
• Updating tests to cover authorization failures.
• Reviewing other services to ensure they do not rely on UI only protection.

⚠️ Watch for this mistake: Relying on hidden UI elements or client side checks as the main access control mechanism.

⚠️ Watch for this mistake: Applying authorization inconsistently across services and endpoints.

⚠️ Watch for this mistake: Creating overly complex role structures that nobody reviews or cleans up.

⚠️ Watch for this mistake: Allowing long lived sessions without re authentication for critical actions.

⚠️ Watch for this mistake: Ignoring service to service authentication and authorization in microservice architectures.

• ✅ ✅ Document key roles and permissions for each major application.
• ✅ ✅ Ensure server side authorization checks protect every sensitive endpoint and action.
• ✅ ✅ Implement centralized access control logic or libraries so rules are applied consistently.
• ✅ ✅ Set reasonable session timeouts and require re authentication for high risk actions.
• ✅ ✅ Review and adjust role assignments regularly, removing unused or overly powerful roles.
• ✅ ✅ For microservices, implement strong service authentication using mutual TLS or signed tokens.

• 💡 💡 Access control is a combination of authentication, authorization, and accounting.
• 💡 💡 Server side enforcement is essential, UI checks alone are never enough.
• 💡 💡 Simple, well governed roles or attributes work better than complex, unmanaged ones.
• 💡 💡 CISSP Domain 8 expects you to design access control that is both secure and manageable.

📝 Exam practice

📝 Exam practice

An application hides the "Admin" menu from non admin users but does not enforce authorization checks on the related URLs. What is the primary risk.

Short answer: Users who know or discover the admin URLs can access privileged functions without proper authorization. Relying only on the UI to enforce access control leaves critical functions exposed.