ISC2 ISSAP Domain 4.4.3: Architect Identity Authorization

Imagine giving every employee in your company a master key that opens every door, from the lobby to the CEO’s office. Sounds terrifying, right? Yet in cybersecurity, this is exactly what happens when identity authorization is poorly implemented. In an era where identity is the new perimeter of security, ensuring the right people (and only the right people) access the right resources is paramount. The stakes are high: nearly 49% of breaches by external attackers involve stolen credentials, and 80% of security breaches involve compromised privileged accounts. These sobering stats underscore a simple truth: if we do not architect identity authorization correctly, we are essentially handing out those “master keys” to attackers.

As an ISSAP-certified Security Architect (or an aspiring one), you need to master identity authorization to protect your enterprise. With the explosion of cloud services and remote work, identities and access have sprawled beyond the old network perimeter, creating countless unmanaged accounts and credentials.

Authorization Concepts and Principles

Authorization is all about deciding who is allowed to do what after a user or system has been authenticated. Here are some of the key concepts and principles:

• Discretionary vs. Mandatory Access Control (DAC vs. MAC): These are classic models for who controls access. In Discretionary Access Control, the owner of a resource (say, a file or database) gets to decide who else can access it. It is flexible, but puts responsibility on individuals and requires oversight. By contrast, Mandatory Access Control is much stricter; access rules are set by a central authority based on policies or classifications (like security labels), and even resource owners can not alter permissions.
• Least Privilege: This principle means granting a user or process only the minimum access necessary to perform its job; no more, no less. If an employee only needs read access to a database, do not make them an admin on it. Least privilege limits damage from accidents or breaches.
• Separation of Duties (SoD): SoD is like the two-man rule; no single person should have control over all steps of a critical process. By dividing responsibilities among multiple people, you prevent fraud and mistakes. For example, the person who approves vendor payments should not be the same person who can add new vendors in the system.
• Interactive vs. Non-Interactive Access: Not all accounts are used by humans typing at a keyboard. Interactive accounts are those where a real user logs in and actively works (e.g., your employee logging into a workstation). Non-interactive accounts (often service accounts or scripts) operate behind the scenes; they authenticate automatically to run services, scheduled tasks, or API calls without human intervention. Why does this matter for authorization? Because non-interactive accounts often have high privileges and are less monitored.

Authorization Models: Physical, Logical, and Administrative

When designing an authorization system, it’s useful to think in terms of layers of controls. Generally, security controls are categorized into three models or types: physical, logical, and administrative.

• Physical Controls: These are the tangible barriers to entry. Think door locks, access cards, biometrics at the building entrance, security guards, or a gated data center. Physical authorization ensures only authorized people can enter sensitive facilities or access hardware.
• Logical (Technical) Controls: These are the digital permissions built into systems, applications, and networks. Logical access control is what we usually mean by “authorization” in IT: user accounts, roles, privileges, access control lists, encryption, etc. When you assign a user to a role that grants read-only access to a database, that is a logical control. Firewalls and network segmentation, which restrict which IP addresses or devices can access a server, are also logical controls.
• Administrative Controls: This refers to the policies, procedures, and governance around access. Examples include an organization’s access control policy, the process for approving a new user’s access request, security training for employees about proper use of privileges, and audits to verify compliance. Administrative controls set the rules of the road; e.g., a policy might dictate that no new access is granted without manager approval, and all access rights must be reviewed every 6 months.

Authorization Process and Workflow

Authorization is not a one-time set-it-and-forget-it task; it is an ongoing lifecycle. From the moment a user is onboarded to the day they leave (and beyond), their access rights must be governed carefully. A typical authorization process and workflow includes:

• Access Request and Issuance: This is where it all starts. A user (or their manager) requests access to a system or data. The request should follow the principle of least privilege, only what’s necessary. An approval workflow (perhaps through an Identity Governance tool or IT service desk) kicks in.
• Authorization Governance: Governance is the umbrella that ensures the whole process is working. It includes establishing clear policies (e.g., who can approve access to financial data? What segregation of duties must be enforced so one request does not violate SoD?), as well as setting metrics and oversight.
• Periodic Review (Access Recertification): Over time, people’s roles change. Today’s must-have access could be overkill next quarter if an employee switches projects. That is why regular reviews are essential. Many organizations do quarterly or semi-annual access reviews, and managers and system owners must attest that each user still needs their current permissions.
• Revocation and Suspension: When a user leaves the company or no longer requires certain access, you must promptly revoke those rights. Account termination should ideally be automated (e.g., triggered by HR’s termination process to immediately disable accounts). For internal role changes, remove any old privileges that are not needed in the new role (to prevent privilege creep). Sometimes a user’s access might be suspended temporarily; for example, if suspicious activity is detected or if the user is on extended leave.
• Audit and Improvement: Lastly, the process should include feedback loops to ensure continuous improvement. Security teams should audit authorization logs and decisions: Were there any unauthorized access attempts? Any permissions granted outside of the standard process?

Roles, Rights, and Responsibilities in Access Control

When architecting identity and authorization, you will deal with a variety of roles, rights, and responsibilities. Here are some key considerations:

• Defining Roles and Groups: In any medium to large organization, it is impractical to assign permissions user-by-user for every system. Instead, we use roles (or group memberships) to bundle permissions. For example, you might have a role called “HR Manager” that automatically grants access to the HR system and relevant files.
• Rights (Permissions) Management: Different systems express permissions differently; some use access control lists, others use role-based policies, and others use attribute conditions. However, fundamentally, each right grants some level of action on an object (e.g., reading a file, editing a record, executing a transaction). It is important to map out what rights exist, which roles or users should have them, and, importantly, who is the owner or custodian of those rights.
• Data, Application, and System Owners: Part of a mature access control program is having designated owners for key resources. A system owner might be in IT (responsible for an application’s upkeep and security), and an application/data owner is often on the business side (responsible for how data in a system is used and who should see it).
• Digital Rights Management (DRM) and Data Controls: Sometimes, authorization is not just about accessing data, but also about how data is used after access. This is where DRM comes in. DRM technologies allow for fine-grained control, such as preventing a document from being printed or ensuring an email can not be forwarded outside the company.
• Trust Relationships: In modern IT ecosystems, we rarely operate in total isolation. Your organization likely partners with vendors, cloud providers, or perhaps is part of a conglomerate. Trust relationships are established to extend authentication/authorization between domains or systems. A common example is a federation trust (say, your company’s identity provider trusts a partner’s identities for single sign-on).

Management of Privileged Accounts (PAM)

Not all accounts are equal. Privileged accounts, those with administrative or highly elevated rights, are the “keys to the kingdom.” If a regular user account is a house key, a privileged account (like a domain admin or root user) is the master key to all houses.

Privileged Access Management (PAM) is the discipline and tools to manage these powerful accounts. Here’s how to approach it:

• Identify All Privileged Accounts: This includes obvious ones (System Administrators, Database Admins) and less obvious ones (service accounts running critical services, application accounts with broad access, default accounts that come with software, etc.). Do not forget machine identities, e.g., an API key that grants admin access is effectively a privileged account for a script.
• Secure and Vault Credentials: A core PAM practice is to store privileged credentials in a secure vault. Users check out passwords when needed, and the vault can rotate (change) the password after use, so it is not reused. This reduces the risk of someone writing down an admin password or using the same one everywhere.
• Enforce Least Privilege and Just-In-Time Access: We talked about least privilege generally, but for admins, it is often implemented as Role-Based Access Control combined with temporary elevation. For example, an IT support technician may run as a normal user day-to-day and only elevate to admin on a specific system when a ticket requires it. Just-in-Time (JIT) access means that even if someone needs admin rights, they get it for a limited time window or one-time use.
• Monitor and Audit Activities: Every action performed with a privileged account should be watched like a hawk. PAM tools can record admin sessions (video or command logs), alert on suspicious behavior, and provide a trail for forensics.
• Educate and Enforce Accountability: Shared admin accounts (like everyone using the user “Administrator” on some server) are risky because it is hard to tie actions to a specific person. Wherever possible, use named accounts (each admin has their own login, even for elevated access) so there’s accountability.

Approaches to Authorization: SSO, RBAC, ABAC, and More

Finally, let us survey the common authorization approaches and technologies in use. Here are the heavy-hitters every Security Architect should know:

• Single Sign-On (SSO): SSO is not a permission model per se; it is more about authentication federated across systems, but it greatly influences authorization experiences. With SSO, a user logs in once and obtains a token or ticket, which then lets them access multiple applications without re-authenticating each time.
• Token-Based Access (OAuth tokens, API keys): Tokens are like temporary keys that prove you have been authorized. When you log into a cloud service, and it gives your device a JWT (JSON Web Token) or session token, that token is presented to other services to authorize you. OAuth 2.0 is a framework widely used for delegated authorization. For example, when you use “Log in with Google” to allow an app limited access to your Google data, Google issues a token to that app with specific scopes (permissions). API keys and tokens are often used for service-to-service authorization: instead of a username/password, a service gets a token that says “service X is allowed to call API Y.”
• Certificate-Based Authorization: Certificates (like X.509 digital certificates) can serve as a form of identity and access control, especially for devices and servers. For example, in a corporate network, a laptop might present a machine certificate to prove it is a trusted company device, and then be allowed on the network (network access control). Or a user with a smart card (certificate on the card) may be authorized to log into systems without a password; the certificate maps to their account and grants access.

ISSAP Training with InfosecTrain

Architecting identity authorization is both an art and a science. Attackers are relentlessly targeting identities and privileges, making it critical for Security Architects to master principles like least privilege, RBAC/ABAC, PAM, and Zero Trust. Getting it right means smoother user access, stronger controls, and attackers locked out at every door.

Ready to take your expertise to the next level? InfosecTrain’s ISSAP Certification Training equips you with the skills and strategies to design resilient identity authorization frameworks that align with real-world business and regulatory demands.

Enroll today and become the Architect who keeps the keys in the right hands.

TRAINING CALENDAR of Upcoming Batches For

Start Date	End Date	Start - End Time	Batch Type	Training Mode	Batch Status
07-Feb-2026	21-Mar-2026	19:00 - 23:00 IST	Weekend	Online	[ Open ]	Enroll Now