Administer CAAB

Before you start

CAAB Admin authenticates requests with a Cognito token. Browser API calls send the ID token when available and fall back to the access token in an Authorization: Bearer <token> header.

1. Provision a partner and subjects

Create the partner record first. CAAB asks Crittora's User Identity Service to create the partner and uses the returned organization ID; it does not manufacture an organization ID locally. The partner is the ownership boundary for imported APIs, users, policies, auth profiles, branding, experience configuration, metering, and billing.

1. Open Partners, create the organization, and confirm the generated partner record.

2. Add a user with a unique username and email. Use partner administrator only for users who must change tenant configuration; use runtime member for end users and agents.

3. For a legacy portal subject, CAAB preserves the existing subject credential bundle used by v1 policy crypto. An external OIDC subject is a credential-free CAAB record; v2 policy crypto uses the CAAB environment service identity instead.

4. Generate or rotate the subject's MCP URL when the runtime connection is needed. Treat the URL as a credential and distribute it through a secure channel.

2. Import and review an API capability

From CAAB APIs, import an OpenAPI document as JSON or from a public HTTPS source. Preview before saving. CAAB resolves local schema references and converts the document into a common data model containing base URL, authentication metadata, parameters, request and response schemas, and operations.

Deleting an imported API removes the partner catalog entry. Review dependent boundaries and auth profiles before deletion so subjects do not retain references to a capability that no longer exists.

3. Configure an auth profile

An auth profile separates the authority decision from the secret used to execute it. Give profiles environment-specific names such as production-readonly or sandbox, and rotate their secret material without changing permission IDs.

4. Assign a least-privilege permission boundary

Select one subject, one or more partner capabilities, and only the operations required for the subject's job. Each API policy must reference an existing auth profile. CAAB rejects unknown permission IDs and deduplicates the allowlist before compiling the policy.

1{
2  "capability_id": "acme-orders-a1b2c3d4",
3  "allowed_permission_ids": [
4    "acme-orders-a1b2c3d4:get:/orders/{orderId}",
5    "acme-orders-a1b2c3d4:post:/orders/{orderId}/refund"
6  ],
7  "auth_profile_ref": "auth-profile:acme-orders-a1b2c3d4:production",
8  "response_redactions": {
9    "acme-orders-a1b2c3d4:get:/orders/{orderId}": [
10      { "path": "/customer/email", "mode": "mask", "keep_last": 4 },
11      { "path": "/payment/card_token", "mode": "remove" }
12    ]
13  }
14}

Response rules use JSON Pointer paths. remove deletes a field. mask replaces its value while optionally preserving the final characters. Use /* to apply the next path segment to every member of an array. Rules may only target operations already present in allowed_permission_ids.

You can also apply signed parameter constraints to REST path, query, header, and body values or to MCP tool arguments. Author rules through the boundary workflow; CAAB embeds their normalized effective form in the signed operation snapshot. At call time, schema validation and parameter constraints run before CAAB loads an auth-profile secret or makes a downstream request. Constraint denials are value-free audit decisions, not permission-boundary bypasses.

Task reference

5. Verify, monitor, and maintain

Update a boundary whenever responsibilities change. Revoke or expire policy before removing a subject. Use the supported lifecycle so legacy credential bundles or external identity mappings are cleaned up according to their identity mode.

Next: understand the runtime decision path, policy protection, and audit model