You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Title: Enhanced IAM Pre-Tool Plugin with Rich Context Authorization
Goal: Extend the IAM pre-tool plugin to support rich context authorization (ABAC), human-in-the-loop approval workflows, and non-MCP server tools (REST endpoints).
Why now:
Current plugin framework supports basic RBAC but lacks fine-grained attribute-based access control (ABAC)
Enterprise deployments need human approval for sensitive operations (financial transfers, data deletion)
REST tools (non-MCP) need the same authorization controls as MCP tools
Compliance requirements (SOX, SOC2) mandate approval workflows for certain operations
I want: Authorization decisions to consider rich context (user attributes, resource attributes, environmental factors)
So that: I can implement fine-grained access control beyond simple role-based permissions
Acceptance Criteria:
Scenario: Authorize based on user departmentGiven the IAM plugin is configured with ABAC rules
And user "alice" has department="engineering"When alice invokes tool "deploy_to_production"And the tool requires department="devops" OR department="sre"Then the tool invocation should be denied
And an audit log entry should be created
Scenario: Authorize based on resource sensitivityGiven the IAM plugin is configured with data classification rules
And resource "customer_database" has classification="confidential"When user "bob" with clearance="public" invokes tool "query_database"Then the tool invocation should be denied
And the denial reason should indicate clearance mismatch
Scenario: Authorize based on time windowGiven the IAM plugin is configured with time-based rules
And tool "batch_delete" is only allowed during maintenance windows
When user invokes "batch_delete" outside the maintenance window
Then the tool invocation should be denied
And the response should include next allowed time window
Technical Requirements:
Extend GlobalContext to include user attributes from identity provider
I want: Certain tool invocations to require human approval before execution
So that: Sensitive operations have explicit authorization from designated approvers
Acceptance Criteria:
Scenario: Tool requires approval before executionGiven the IAM plugin is configured to require approval for "wire_transfer"When user invokes "wire_transfer" with amount > $10,000
Then the tool invocation should be paused
And an approval request should be created
And the user should receive a pending status
Scenario: Approver approves the requestGiven a pending approval request for "wire_transfer"And user "manager" is designated approver
When "manager" approves the request
Then the tool invocation should proceed
And the approval should be recorded in audit trail
Scenario: Approval timeoutGiven a pending approval request
And the approval timeout is 1 hour
When 1 hour passes without approval
Then the request should be automatically denied
And the user should be notified of timeout
Technical Requirements:
Integrate with MCP elicitation for approval prompts
Support configurable approval workflows
Store pending approvals with timeout
Notify approvers via webhook or UI
US-3: Developer - Authorize Non-MCP Tools
As a: Developer using REST tools alongside MCP tools
I want: The IAM plugin to authorize REST tool invocations
So that: All tools (MCP and REST) have consistent authorization
Acceptance Criteria:
Scenario: REST tool invocation authorizedGiven a REST tool "api/v1/users" is registered
And the IAM plugin is configured with REST tool policies
When user invokes the REST tool via gateway
Then the IAM plugin should evaluate authorization
And authorized requests should proceed to the REST endpoint
Scenario: REST tool invocation deniedGiven a REST tool "api/v1/admin/delete" requires admin role
And user "viewer" has role="viewer"When "viewer" invokes the REST tool
Then the request should be denied with 403 status
And the denial should be logged
Scenario: Mixed MCP and REST authorizationGiven a virtual server with both MCP and REST tools
When the IAM plugin evaluates authorization
Then the same policy engine should be used for both
And audit logs should capture both tool types
🧭 Epic
Title: Enhanced IAM Pre-Tool Plugin with Rich Context Authorization
Goal: Extend the IAM pre-tool plugin to support rich context authorization (ABAC), human-in-the-loop approval workflows, and non-MCP server tools (REST endpoints).
Why now:
📖 User Stories
US-1: Security Admin - Rich Context Authorization (ABAC)
As a: Security Administrator
I want: Authorization decisions to consider rich context (user attributes, resource attributes, environmental factors)
So that: I can implement fine-grained access control beyond simple role-based permissions
Acceptance Criteria:
Technical Requirements:
GlobalContextto include user attributes from identity providerUS-2: Compliance Officer - Human-in-the-Loop Approval
As a: Compliance Officer
I want: Certain tool invocations to require human approval before execution
So that: Sensitive operations have explicit authorization from designated approvers
Acceptance Criteria:
Technical Requirements:
US-3: Developer - Authorize Non-MCP Tools
As a: Developer using REST tools alongside MCP tools
I want: The IAM plugin to authorize REST tool invocations
So that: All tools (MCP and REST) have consistent authorization
Acceptance Criteria:
Technical Requirements:
🏗 Architecture
Rich Context Authorization Flow
sequenceDiagram participant Client participant Gateway participant IAMPlugin participant PolicyEngine participant ToolService Client->>Gateway: tools/call (wire_transfer, amount=50000) Gateway->>IAMPlugin: tool_pre_invoke hook IAMPlugin->>IAMPlugin: Extract user attributes IAMPlugin->>IAMPlugin: Extract resource attributes IAMPlugin->>IAMPlugin: Get environmental context IAMPlugin->>PolicyEngine: Evaluate ABAC policy PolicyEngine-->>IAMPlugin: Decision + obligations alt Requires Approval IAMPlugin->>IAMPlugin: Create approval request IAMPlugin-->>Gateway: Pending (elicitation) Gateway-->>Client: Approval required else Authorized IAMPlugin-->>Gateway: Continue Gateway->>ToolService: Execute tool else Denied IAMPlugin-->>Gateway: Deny with reason Gateway-->>Client: 403 Forbidden endABAC Context Model
classDiagram class AuthorizationContext { +subject: SubjectAttributes +resource: ResourceAttributes +action: ActionAttributes +environment: EnvironmentAttributes } class SubjectAttributes { +user_id: str +roles: list[str] +department: str +clearance_level: str +groups: list[str] } class ResourceAttributes { +tool_name: str +classification: str +owner: str +tags: list[str] } class ActionAttributes { +operation: str +parameters: dict } class EnvironmentAttributes { +timestamp: datetime +ip_address: str +is_maintenance_window: bool } AuthorizationContext --> SubjectAttributes AuthorizationContext --> ResourceAttributes AuthorizationContext --> ActionAttributes AuthorizationContext --> EnvironmentAttributes📋 Implementation Tasks
Phase 1: Rich Context Foundation
GlobalContextwith user attributes (department, groups, clearance)AuthorizationContextmodel for ABAC evaluationPhase 2: ABAC Policy Integration
Phase 3: Human-in-the-Loop Approval
Phase 4: REST Tool Support
Phase 5: Admin UI
Phase 6: Testing
⚙️ Configuration Examples
ABAC Policy (Cedar format)
Approval Workflow Configuration
✅ Success Criteria
🏁 Definition of Done
GlobalContextextended with user attributesAuthorizationContextmodel implementedmake verify🔗 Related Issues
📓 Additional Context
Compliance Requirements Addressed