# Kamiwaza 0.13.0 ReBAC Validation Checklist

This is documentation for Kamiwaza **0.13.0**, which is no longer actively maintained. For the current GA release, see [**1.0.1**](https://docs.kamiwaza.ai/).

## Before You Begin

Confirm these prerequisites:

- The environment is reachable at its customer-facing HTTPS hostname.
- Authentication is enabled and users can reach the sign-in flow.
- ReBAC is enabled in the deployment.
- At least two test accounts exist in the identity provider:
  - One account that should be allowed to manage or view the target resource.
  - One account that should be denied for the same protected action.
- You have access to the approved log or observability path for the environment.

If you still need to configure the environment, start with the [ReBAC Deployment Guide](https://docs.kamiwaza.ai/0.13.0/security/rebac-deployment-guide).

## 1. Browser Sign-In

1. Open the Kamiwaza web application.
2. Sign in with a known-good administrator or authorized user account.
3. Confirm you are returned to the application without an auth error or redirect loop.

**Expected result:**
- Sign-in completes successfully.
- The UI loads normally.

## 2. Session Validation

Confirm that the environment recognizes an authenticated session.

One common check is:

```bash
curl -i https://<your-domain>/api/auth/validate
```

Run this with the session or bearer-token method approved for your environment.

**Expected result:**
- HTTP `200`
- Authenticated user context is returned.

## 3. Allow Path

Using an account that should have access:

1. Open a representative protected workflow, such as a model, dataset, or other managed resource.
2. Confirm read access succeeds.
3. If the role is expected to write or administer the resource, confirm one representative change also succeeds.

**Expected result:**
- The permitted action completes successfully.

## 4. Deny Path

Using an account that should not have access to that same action:

1. Attempt the same protected operation.
2. Confirm the request is denied.

**Expected result:**
- The user receives a deny response or equivalent UI error.
- The request does not silently succeed.

## 5. Tenant and Role Scope

If the environment is multi-tenant or uses tenant-scoped policy:

1. Sign in as a user from the intended tenant.
2. Confirm that tenant-scoped resources are visible as expected.
3. Sign in as a user from a different tenant or role scope.
4. Confirm those resources are not exposed outside the allowed scope.

**Expected result:**
- Users see only the resources and actions granted to their tenant and role context.

## 6. Logging and Auditability

Review the environment's approved logging path, such as:

- The Kamiwaza UI log viewer.
- Platform observability dashboards.
- Kubernetes logs collected by your normal operations tooling.

Confirm you can find records associated with:

- Successful authentication.
- Denied access decisions.
- The relevant correlation or request identifiers, if your environment exposes them.

**Expected result:**
- Logs are available for both allow and deny scenarios.
- Security and operations teams can trace the request outcome.

## 7. Session Controls

If the deployment uses session revocation, inactivity timeout, or ephemeral-session behavior:

1. Verify the expected timeout or logout behavior with a test account.
2. Confirm the user must re-authenticate after the session expires or is revoked.

**Expected result:**
- Session policy behaves as configured for the environment.

## 8. Federal or CAC Validation

For CAC-enabled federal deployments, also validate:

- The client certificate is accepted through the ingress path.
- The mapped user is correctly identified by the identity provider.
- Certificate-related failures produce clear deny behavior.

Use:
- [CAC Overview](https://docs.kamiwaza.ai/0.13.0/federal/cac-overview).

## Success Criteria

Mark the environment validated when all of the following are true:

- Sign-in works for intended users.
- Authorized actions succeed.
- Unauthorized actions are denied.
- Tenant boundaries behave as expected.
- Security-relevant logs are visible through the approved operations path.

Capture the evidence your organization requires, such as screenshots, log excerpts, or ticket references, as part of deployment sign-off.