> For the complete documentation index, see [llms.txt](https://framework.aic.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://framework.aic.io/technical-guidelines-code-standards-and-tech-stack/secure-engineering-standards/authentication-authorization-rbac-and-abac.md).

# Authentication, Authorization, RBAC and ABAC

## Purpose

Authentication proves identity. Authorization decides what an authenticated identity can do.

AIC APIs and applications must treat authorization as a first-class design concern.

## AIC Standard

* Authentication uses approved identity providers and protocols.
* Authorization is enforced server-side.
* Sensitive actions require policy-based authorization.
* Object-level authorization must be tested.
* RBAC is used for stable role-based permissions.
* ABAC is used where decisions depend on attributes such as clearance, tenant, classification, ownership, location, time or project.

## RBAC Example

| Role            | Permissions                                            |
| --------------- | ------------------------------------------------------ |
| CaseReader      | Read assigned cases                                    |
| CaseManager     | Create and update cases                                |
| SecurityOfficer | View security fields                                   |
| Administrator   | Manage configuration, not business approval by default |

## ABAC Example Attributes

| Attribute           | Source                                  |
| ------------------- | --------------------------------------- |
| User clearance      | Identity provider / HR / vetting system |
| Project membership  | Project access register                 |
| Data classification | Record metadata                         |
| Tenant              | Claims and route context                |
| Ownership           | Domain record                           |
| Time restriction    | Policy configuration                    |

## Policy Example

```csharp
builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("Cases.Read", policy =>
    {
        policy.RequireAuthenticatedUser();
        policy.RequireClaim("permission", "cases.read");
    });
});
```

## Object-Level Authorization

Do not rely only on endpoint-level roles. Check access to the specific object.

```csharp
if (!await _authorizationService.CanReadCaseAsync(user, caseRecord, cancellationToken))
{
    return Result.Forbidden();
}
```

## Authorization Test Matrix

| Scenario                           | Expected result               |
| ---------------------------------- | ----------------------------- |
| No token                           | 401                           |
| Invalid token                      | 401                           |
| Valid token without role           | 403                           |
| Valid role but wrong tenant        | 403 or 404 by policy          |
| Valid role and matching attributes | 200                           |
| Admin without business permission  | 403 unless explicitly allowed |

## Anti-Patterns

Avoid:

* authorization only in the UI
* hardcoded role strings scattered through code
* treating admin as universal permission
* trusting client-supplied user IDs
* failing open when claims are missing
* untested object-level authorization