4. Identity, Access and Secrets Management

Introduction and Context

Identity, access and secrets management forms the control plane through which an organization decides who or what may use a digital resource, under which conditions, and for how long. In cloud, Internet of Things (IoT), and enterprise environments, this question extends beyond employees. Customers, contractors, applications, containers, virtual machines, APIs, devices, service accounts, and autonomous workloads all require identities. Consequently, security can no longer rely only on a network perimeter or a static list of usernames and passwords.

A modern enterprise must establish confidence in identities, assign appropriate privileges, protect authentication material, and continually reassess whether access remains justified. These activities are related but distinct. Identity management concerns the creation, maintenance, and retirement of digital identities. Access management determines how those identities authenticate and what they may do. Secrets management protects credentials, keys, tokens, and other sensitive machine-readable values. Identity governance provides oversight, policy, evidence, and accountability across the entire lifecycle.

The central challenge is to achieve both security and operational usability. Excessively broad permissions increase the impact of compromise, while excessively restrictive controls may encourage workarounds, shared accounts, or unsafe credential storage. Effective programs therefore apply least privilege, separation of duties, risk-based authentication, strong lifecycle processes, and continuous monitoring.

Learning Objectives

After completing this chapter, the learner should be able to:

1. Explain the relationship among identity management, authentication, authorization, accounting, and secrets management.

2. Compare federation, single sign-on, multifactor authentication, RBAC, ABAC, and policy-based access control.

3. Design lifecycle processes for human, machine, workload, and device identities.

4. Evaluate privileged access management and continuous authorization strategies.

5. Apply certificates, cryptographic keys, and secrets-management techniques in cloud and IoT environments.

6. Analyze governance, privacy, regulatory, ethical, and operational risks.

7. Recommend an identity architecture for a complex enterprise scenario.

The Identity Problem in Distributed Environments

An identity is a representation of an entity that can be recognized by a system. The entity may be a person, device, service, application, workload, or organization. An identifier, such as a username, device ID, or service principal name, distinguishes the entity; authentication provides evidence that the entity controls the identifier; authorization determines permitted actions; and accounting records what occurred.

These functions are often summarized as identification, authentication, authorization, and accounting. They should not be confused. A username identifies a claimed subject but does not prove ownership. A password, cryptographic key, biometric characteristic, or hardware-backed token may authenticate that subject. Authorization then evaluates policies, attributes, context, and requested actions. Accounting, often called auditing or accountability, preserves evidence for investigation and compliance.

Cloud and IoT systems complicate this model. A cloud application may call several managed services, each requiring a separate machine identity. An IoT device may operate unattended for years, communicate intermittently, and have limited computing capacity. A hybrid enterprise may use identities issued by an internal directory, a cloud identity provider, a partner organization, and device-manufacturing infrastructure. The resulting environment is not a single directory but an identity ecosystem.

A useful distinction is between identity proofing and authentication. Identity proofing establishes confidence that an identity corresponds to a real person or legitimate organization. Authentication occurs repeatedly when the subject requests access. Federation allows one organization to accept authentication assertions issued by another trusted identity provider. Authorization remains the responsibility of the resource owner or relying service; trusting an external authentication provider does not imply granting unrestricted access.

Identity Lifecycle and Governance

Identity governance treats access as a managed business process rather than a purely technical configuration. The lifecycle normally begins with registration or provisioning, continues through changes in role and entitlement, and ends with suspension or deletion. A robust lifecycle includes ownership, approval, periodic review, evidence, and exception handling.

For employees, authoritative data may originate in a human-resources system. A joiner-mover-leaver process can create an account when a person joins, adjust access when responsibilities change, and revoke access promptly when employment ends. The process should distinguish a change of department from a temporary project assignment and should avoid accumulating old permissions. This accumulation is known as privilege creep.

Governance also covers entitlement catalogs, access requests, approval workflows, certification campaigns, toxic-combination analysis, and reconciliation. An entitlement is a specific permission or permission bundle. An access review asks whether the entitlement is still needed, appropriate, and approved by a responsible owner. Separation of duties prevents one individual from controlling incompatible activities, such as creating a supplier and approving payment to that supplier.

Identity governance must include non-human identities. Service accounts should have owners, documented purposes, defined scopes, expiration or review dates, and monitored use. Orphaned accounts, unmanaged API keys, embedded credentials, and inactive certificates are common sources of avoidable exposure. Automated discovery and inventory are therefore essential, particularly in environments with infrastructure as code and rapidly changing workloads.

Authentication, Federation and Single Sign-On

Authentication factors are commonly grouped as knowledge factors, possession factors, and inherence factors. Passwords and PINs are knowledge factors. Hardware security keys, smart cards, and authenticator applications are possession factors. Fingerprints and facial characteristics are inherence factors. Multifactor authentication (MFA) requires evidence from two or more different factor categories; using a password and a second password is not genuine MFA.

MFA reduces the effect of stolen passwords, but its strength depends on implementation. Phishing-resistant methods, such as passkeys based on public-key cryptography or hardware security keys, provide stronger protection than one-time codes that can be relayed through phishing. Recovery processes require equal attention because an attacker may bypass strong authentication by persuading a help desk to reset an account.

Single sign-on (SSO) enables a user to authenticate once with an identity provider and access multiple relying applications without separately entering credentials for each application. SSO improves usability and can reduce password reuse, but it concentrates risk in the identity provider. Strong administrative controls, resilient recovery, monitoring, and carefully scoped trust relationships are therefore necessary.

Federation uses standardized assertions or tokens to communicate authentication and identity information between domains. SAML is widely used for browser-based enterprise federation, while OpenID Connect provides an identity layer over OAuth 2.0 and is common in modern applications. OAuth 2.0 is primarily an authorization framework, not a user-authentication protocol by itself. Confusing these roles can lead to insecure application designs.

Federation requires attention to issuer validation, audience restriction, token lifetime, signing-key protection, clock synchronization, redirect URI control, and claim minimization. A relying party should accept only the claims and scopes necessary for the requested operation. Trust should be explicit, documented, and periodically reviewed.

Authorization Models and Policy Decisions

Authorization can be implemented through several models. Role-based access control (RBAC) assigns permissions to roles and then assigns users or workloads to roles. It is understandable and effective where job functions are stable. However, role proliferation may occur when organizations attempt to represent every location, project, device, and temporary condition as a separate role.

Attribute-based access control (ABAC) evaluates attributes of the subject, resource, action, and environment. A policy might allow a clinician to read a patient record when the clinician is assigned to the patient, the request originates from an approved device, and the purpose is treatment. ABAC offers expressive, context-sensitive decisions but requires reliable attributes, governance of policy logic, and explainable denial outcomes.

Rule-based and policy-based approaches express conditions directly, often combining roles and attributes. Relationship-based access control evaluates relationships such as “user is a member of project” or “service is authorized by resource owner.” In practice, mature systems frequently combine models: RBAC provides broad job-function permissions, while attributes and contextual rules refine the decision.

A policy decision point evaluates a request, while a policy enforcement point applies the decision. A policy information point supplies attributes such as device posture, location, risk score, or employment status. This separation supports centralized policy while allowing enforcement at gateways, applications, databases, APIs, and service meshes. Authorization decisions should be logged with the subject, resource, action, context, policy result, and reason where feasible.

Least privilege means granting only the permissions necessary for an approved purpose and duration. Just-in-time access grants elevated permissions temporarily rather than permanently. Just-enough administration limits the scope of an administrative session. Both practices reduce the attack surface and the blast radius of compromised credentials.

Privileged Access Management

Privileged accounts can alter security controls, identities, infrastructure, or sensitive data. Privileged access management (PAM) governs these accounts through discovery, segregation, credential protection, approval, session control, and monitoring. A PAM architecture may place administrator credentials in a vault, rotate them automatically, require approval for sensitive actions, and record administrative sessions.

PAM should cover domain administrators, cloud tenant administrators, database administrators, CI/CD service accounts, emergency accounts, and privileged application identities. It should also address indirect privilege. For example, a developer who can modify a deployment pipeline may effectively obtain production administrator access even without a formal administrator role.

Emergency or break-glass accounts are necessary when identity infrastructure is unavailable, but they must be tightly protected, rarely used, independently monitored, and tested. Their credentials should not become the normal means of administration. Dual authorization, out-of-band notification, and post-event review are appropriate for high-risk operations.

Machine Identities, Certificates and Workload Security

Machine identities enable software and devices to authenticate without human interaction. Examples include service principals, managed identities, workload identities, device certificates, API clients, and cryptographic key pairs. The key design question is whether an identity is unique, attributable, narrowly scoped, and renewable.

Certificates bind a public key to an identity through a certificate authority (CA). Mutual TLS allows both client and server to authenticate using certificates. It is useful for service-to-service communication, device onboarding, and zero-trust network designs. Certificate management includes issuance, validation, renewal, revocation, inventory, and protection of private keys. Expired certificates can interrupt operations; poorly protected private keys can permit impersonation.

Public key infrastructure (PKI) may use offline root CAs, subordinate issuing CAs, certificate policies, hardware security modules, and automated enrollment. IoT deployments particularly benefit from device certificates provisioned during manufacturing or secure onboarding. However, device identity alone does not establish that the device is healthy or authorized for every action. Device posture, firmware status, network context, and behavioral signals may also be required.

Cloud platforms increasingly provide managed identities that remove the need to distribute long-lived credentials to workloads. Where managed identities are unavailable, short-lived tokens, workload identity federation, and automated rotation are preferable to permanent access keys. Secrets should never be embedded in source code, container images, public repositories, or unprotected configuration files.

Secrets Management

A secret is sensitive information used to authenticate, authorize, encrypt, or otherwise protect a system. Examples include passwords, database credentials, API keys, OAuth client secrets, private keys, encryption keys, and signing keys. Secrets management encompasses secure generation, storage, distribution, use, rotation, revocation, recovery, and destruction.

A secrets manager should provide encryption at rest and in transit, strict access policies, audit trails, versioning, automated rotation where possible, and separation of administrative duties. Applications should retrieve secrets at runtime using an identity rather than receiving a shared master password. Secret values should be excluded from logs, error messages, telemetry, and diagnostic dumps.

Rotation is not a substitute for good scope design. A broadly authorized key that is rotated frequently may still cause substantial damage if compromised. Short-lived credentials, narrowly scoped permissions, dual control for critical keys, and automated detection of exposed secrets are stronger design choices. Secret zero—the initial credential needed to access the secrets manager—requires special treatment through hardware-backed identity, cloud workload identity, secure bootstrapping, or an equivalent trust mechanism.

Encryption keys deserve separate governance from ordinary application secrets. Key management includes generation, storage, usage policy, rotation, backup, escrow decisions, and destruction. Losing a key may make data permanently inaccessible; retaining it indefinitely may undermine deletion requirements. These are governance decisions as well as technical decisions.

Continuous Authorization and Zero-Trust Access

Traditional access decisions often occur at login and remain valid for an extended session. Continuous authorization treats access as a decision that may change as risk and context change. Relevant signals can include user behavior, device health, network location, resource sensitivity, threat intelligence, time, transaction value, and recent authentication strength.

A continuous model does not require constant interruption of the user. It may reduce privileges, require step-up authentication, revoke a token, terminate a session, or block a transaction when risk changes. For example, a user authenticated from a managed laptop may be permitted to view records, but a sudden change to an unmanaged device or anomalous geographic pattern may trigger reauthentication or denial.

Zero-trust architecture applies the principle that no request should be trusted solely because it originates inside a network. Each request is evaluated using identity, device, application, resource, and environmental context. Zero trust is not a single product and does not eliminate the need for network controls; it redistributes security decisions toward explicit verification and least privilege.

Continuous authorization creates challenges. Signals may be inaccurate, policies may conflict, and excessive monitoring may intrude on privacy. Organizations should define risk thresholds, provide understandable user feedback, maintain safe failure modes, and test policies against legitimate operational scenarios.

Practical Implementation Approach

An enterprise identity program can be developed through a staged method. First, establish an inventory of identities, authoritative sources, applications, privileged functions, certificates, secrets, and trust relationships. Unknown identities cannot be governed effectively.

Second, classify resources and access risks. A public information portal, a production control system, and a regulated health-data repository should not receive identical authorization treatment. Third, define ownership and policy: who approves access, who reviews it, what evidence is required, and how exceptions expire.

Fourth, strengthen the identity foundation through centralized authentication, phishing-resistant MFA for sensitive roles, federation where appropriate, lifecycle automation, and secure recovery. Fifth, implement least privilege through role engineering, attribute quality, PAM, workload identities, and temporary elevation. Sixth, protect secrets and certificates with vaulting, rotation, monitoring, and automated renewal.

Finally, integrate identity telemetry with security operations. Useful indicators include dormant privileged accounts, failed MFA patterns, anomalous token use, excessive standing privilege, secret exposure findings, certificate-expiry risk, and access-review completion. Metrics should measure risk reduction rather than merely counting accounts or login events.

Illustrative Case Study: Federated Identity for a Smart Manufacturing Enterprise

Background

Orion Components, a fictional manufacturer, operates corporate offices, cloud analytics, factory networks, robotic production cells, and thousands of sensors. Employees authenticate through a corporate directory, while contractors use partner accounts. Factory devices were historically configured with shared passwords, and several cloud applications used long-lived API keys.

Situation and Problem

An assessment found that terminated contractors sometimes retained access for several days, administrators used permanent privileges, and device credentials could not be traced to individual equipment. The security team also discovered that application logs occasionally recorded API keys. Management wanted SSO and improved productivity but feared that centralizing authentication would create a single point of failure.

Analysis

The primary issues were weak lifecycle integration, shared machine identities, excessive standing privilege, inadequate secrets protection, and incomplete monitoring. The organization also had a trust-boundary problem: corporate users, partners, workloads, and factory devices required different assurance levels and authorization rules.

Approach and Solution

Orion established the human-resources system as the authoritative source for employee lifecycle events and created automated joiner-mover-leaver workflows. Partner federation was introduced with explicit audience, scope, and termination requirements. Phishing-resistant MFA was required for administrators and remote access, while lower-risk users received a risk-based transition plan.

The enterprise deployed SSO for approved applications and created an entitlement catalog with business owners. RBAC supplied baseline job permissions; ABAC conditions restricted production access by site, device posture, shift, and operational purpose. Privileged access moved to a PAM platform with approval, time-limited elevation, credential rotation, and session recording.

Factory devices received unique certificates through a managed PKI and secure onboarding process. Cloud workloads used managed identities or short-lived federated tokens instead of embedded API keys. Application secrets were moved to a vault, retrieved at runtime, excluded from logs, and rotated automatically. Identity and access events were sent to security monitoring, where unusual device behavior or token use could trigger step-up authentication or isolation.

Outcome

The program reduced shared credentials, improved traceability, and made access removal faster. Operations staff initially expressed concern about certificate renewal and additional authentication steps. The organization addressed this through automated renewal, staged deployment, clear exception procedures, and testing in a non-production factory cell.

Learning Points

The case demonstrates that identity security is an architectural and governance problem, not merely a login project. SSO is valuable but must be paired with strong identity-provider protection. Machine identities require ownership and lifecycle controls just as human identities do. Finally, authorization should reflect resource sensitivity and operational context rather than rely on a single universal role model.

Risks, Limitations and Common Mistakes

Common mistakes include treating authentication as proof of authorization, retaining access after role changes, assigning permissions directly to individuals, using shared administrator accounts, and storing credentials in code repositories. Another frequent error is creating excessively broad roles because fine-grained policy design appears difficult. This often produces a false sense of simplicity and a large compromise radius.

Automation can propagate errors at scale. An incorrect provisioning rule may grant access to an entire population, while a faulty revocation process may disable essential operations. Changes to identity policies should therefore use testing, staged deployment, rollback plans, and independent review.

Biometric authentication raises concerns about privacy and irreversibility. Unlike a password, a biometric characteristic cannot easily be replaced after compromise. Organizations should minimize collection, protect templates, provide lawful alternatives where necessary, and evaluate proportionality.

Identity systems are also vulnerable to denial of service. If the identity provider, certificate authority, or secrets manager becomes unavailable, dependent operations may fail. Resilience requires redundancy, carefully designed offline procedures, tested recovery, and controlled emergency access.

Governance, Ethics and Regulation

Identity decisions affect autonomy, privacy, employment, and access to essential services. Organizations should collect only attributes necessary for a stated purpose, restrict their use, retain audit records appropriately, and provide processes for correction and appeal. Automated risk scoring should be explainable enough for responsible review and should be tested for discriminatory outcomes.

Regulatory obligations vary by sector and jurisdiction, but common expectations include least privilege, access reviews, strong authentication for sensitive systems, protection of personal data, auditability, and timely response to compromise. Evidence should demonstrate not only that a policy exists but that it operates consistently.

Accountability must be assigned. Security teams may operate controls, but business and system owners should remain responsible for deciding who needs access to business resources. Exceptions should have a documented rationale, compensating controls, an owner, and an expiration date.

Emerging Developments

Passkeys and hardware-backed credentials are reducing dependence on phishing-prone passwords. Workload identity federation is replacing static cloud keys in many software-delivery environments. Policy engines are becoming integrated with API gateways, service meshes, databases, and cloud control planes. Continuous risk evaluation is also expanding through device telemetry and behavioral analytics.

Artificial intelligence can assist with entitlement discovery, access-review prioritization, anomalous-use detection, and identification of privilege paths. It should support, not replace, accountable governance. False positives, opaque recommendations, poisoned data, and automated overreaction remain significant concerns. Human review is especially important for employment, safety, financial, and regulated decisions.

Best Practices

• Maintain an authoritative inventory of human, machine, workload, device, certificate, and secret identities.
• Use unique identities and avoid shared accounts except where technically unavoidable and formally controlled.
• Apply phishing-resistant MFA to privileged and high-risk access.
• Automate joiner-mover-leaver processes and review dormant or orphaned accounts.
• Combine RBAC with contextual attributes where static roles are insufficient.
• Prefer least privilege, short-lived tokens, just-in-time elevation, and just-enough administration.
• Store secrets in managed vaults and never embed them in code, images, or logs.
• Automate certificate issuance and renewal and protect private keys with appropriate hardware or platform controls.
• Monitor identity-provider, PAM, federation, token, certificate, and secrets-manager events.
• Test break-glass access, recovery procedures, policy changes, and failure modes.
• Treat access reviews as decisions requiring accountable owners, not as a clerical exercise.

Chapter Summary

Identity, access and secrets management provides the foundation for secure cloud, IoT, and enterprise operations. Effective security begins with reliable identity lifecycle governance and distinguishes identification, authentication, authorization, and accountability. Federation and SSO improve usability when trust relationships, claims, tokens, and recovery processes are controlled. MFA, particularly phishing-resistant MFA, strengthens authentication.

RBAC is useful for stable job functions, while ABAC and policy-based controls introduce context and precision. PAM limits the risks of administrative power through vaulting, approval, temporary elevation, and monitoring. Machine and workload identities require unique attribution, short-lived credentials, certificates, secure key protection, and automated renewal. Secrets management protects credentials throughout their lifecycle and prevents exposure in code and operational data.

Continuous authorization and zero-trust principles evaluate requests using identity, device, resource, and environmental context rather than relying on network location or a single login event. Successful programs combine technology with governance, privacy protection, resilience, accountable ownership, and continuous measurement.

Key Terms

Identity: A digital representation of a person, device, workload, service, or organization.

Authentication: Verification that a subject controls a claimed identity.

Authorization: Determination of which actions an authenticated subject may perform.

Identity federation: Trust arrangement in which one domain accepts identity assertions from another.

Single sign-on: Access to multiple applications through one authentication process.

Multifactor authentication: Authentication using evidence from at least two distinct factor categories.

RBAC: Access control based primarily on assignment of permissions to roles.

ABAC: Access control based on attributes of subjects, resources, actions, and context.

Least privilege: Granting only the permissions necessary for an authorized purpose.

Privilege creep: Accumulation of unnecessary permissions over time.

Privileged access management: Governance and technical control of high-impact administrative access.

Machine identity: An identity used by a device, application, service, or workload.

Certificate: A digitally signed binding between an identity and a public key.

Public key infrastructure: Systems and processes for managing certificates and public-key trust.

Secret: Sensitive data used for authentication, authorization, encryption, or signing.

Secrets manager: A controlled system for storing, distributing, rotating, and auditing secrets.

Workload identity: A digital identity assigned to an executing application or service.

Continuous authorization: Reassessment of access as risk, context, or policy changes.

Policy enforcement point: A component that applies an authorization decision.

Break-glass account: An emergency account used when normal administrative access is unavailable.

Review Questions

Short Answer Questions

1. Distinguish authentication from authorization.

2. What is privilege creep, and how can identity governance reduce it?

3. Why is OAuth 2.0 not, by itself, a user-authentication protocol?

4. State two advantages of unique machine identities.

5. What is the purpose of a secrets manager?

Long Answer Questions

1. Explain the human and non-human identity lifecycle in an enterprise environment.

2. Compare RBAC and ABAC, including situations in which a combined approach is appropriate.

3. Describe the components and operating principles of a privileged access management program.

4. Explain how certificates, PKI, and mutual TLS support cloud and IoT security.

5. Discuss continuous authorization and its relationship to zero-trust architecture.

Analytical / Application Questions

1. A contractor changes from a development project to a production-support role. Design a lifecycle and authorization process that prevents privilege creep while preserving necessary access.

2. A cloud application uses a permanent database password stored in its container image. Analyze the risks and propose a replacement architecture.

3. An enterprise wants to introduce SSO but is concerned that compromise of its identity provider would affect every application. Recommend technical and governance safeguards.

22. Multiple Choice Questions with Answers

Question 1

A user successfully authenticates through an approved identity provider but is denied access to a database because the requested action is not permitted. Which principle does this illustrate?

A. Authentication automatically grants all resource permissions

B. Authentication and authorization are separate decisions

C. Federation eliminates the need for authorization

D. Accounting replaces access control

Correct Answer: B. Authentication and authorization are separate decisions

Question 2

Which design best reduces the risk associated with a cloud workload credential?

A. Store a permanent administrator key in the container image

B. Use a shared password rotated annually

C. Use a managed workload identity with short-lived, narrowly scoped credentials

D. Allow the workload to use a human administrator account

Correct Answer: C. Use a managed workload identity with short-lived, narrowly scoped credentials

Question 3

An organization needs to restrict access based on a user's role, device health, work location, and transaction purpose. Which approach is most suitable?

A. Static password authentication only

B. ABAC or a policy-based model using contextual attributes

C. A single shared account for the department

D. Network location as the only authorization factor

Correct Answer: B. ABAC or a policy-based model using contextual attributes

Question 4

Which control is most characteristic of privileged access management?

A. Permanent administrator access for all developers

B. Time-limited elevation with approval and session monitoring

C. Disabling audit logs for administrators

D. Embedding privileged passwords in scripts

Correct Answer: B. Time-limited elevation with approval and session monitoring

Question 5

Why should an organization avoid treating OAuth 2.0 as a complete authentication protocol?

A. OAuth 2.0 cannot transport any authorization information

B. OAuth 2.0 is primarily an authorization framework and does not by itself establish user identity

C. OAuth 2.0 requires shared passwords between all applications

D. OAuth 2.0 is limited to physical devices

Correct Answer: B. OAuth 2.0 is primarily an authorization framework and does not by itself establish user identity

Question 6

A factory device uses a unique certificate and private key to establish mutual TLS. What is the primary security benefit?

A. Every device can use the same password safely

B. The device can be individually authenticated and its communication encrypted

C. The certificate removes the need for authorization policies

D. The private key may be published to simplify renewal

Correct Answer: B. The device can be individually authenticated and its communication encrypted

Question 7

Which practice most directly addresses privilege creep?

A. Assigning all permissions during initial onboarding

B. Periodic access reviews linked to role changes and authoritative personnel data

C. Allowing users to approve their own permanent access

D. Using more complex usernames

Correct Answer: B. Periodic access reviews linked to role changes and authoritative personnel data

Question 8

Under continuous authorization, what may happen when a previously trusted device becomes unmanaged during an active session?

A. The original authorization must remain valid indefinitely

B. The system may require step-up authentication, reduce privileges, or terminate access

C. The device automatically receives administrator rights

D. All audit records are deleted

Correct Answer: B. The system may require step-up authentication, reduce privileges, or terminate access

Question 9

Which is the strongest treatment of an application secret?

A. Commit it to a private source-code repository

B. Place it in an error message for troubleshooting

C. Retrieve it at runtime from a controlled vault using workload identity

D. Store it in a publicly readable configuration file

Correct Answer: C. Retrieve it at runtime from a controlled vault using workload identity

Question 10

In the illustrative manufacturing case, why were RBAC and ABAC combined?

A. RBAC cannot represent any business function

B. ABAC eliminates the need for identity lifecycle governance

C. RBAC supplied baseline permissions while attributes refined access by context

D. The combination allowed shared credentials to remain unmanaged

Correct Answer: C. RBAC supplied baseline permissions while attributes refined access by context