Support for ABAC and Virtual Server Packaging

[mohab4]

Hi team,

I’m exploring this tool and would like to know:
1. Does it support Attribute-Based Access Control (ABAC), or is there a way to implement fine-grained attribute policies? where the admins of the MCP server can control which attributes in the API response for example can be accessed with the MCP clients.
2. Does it provide features for packaging virtual servers?

Appreciate any clarification.

Thanks!

[crivetimihai]

Hi,

1. Yes, RBAC and ABAC are supported, including fine-grained policies via OPA (Open-Policy Agent) using our plugins/
2. Yes, you can configure virtual servers from multiple upstream MCP servers, REST APIs or A2A Agents, and expose them as STDIO (via wrapper), SSE or Streamable HTTP (or custom transports) using the virtual server feature.

[mohab4]

Hi @crivetimihai,

1. I have one question regarding the second point, Is it possible to pack the tools on a virtual server and export them to be hosted or deployed on an another gateway or host.
2. Secondly, is it possible to use the ibm context forge to transform mTLS based APIs into MCP servers where the certificate is consumed along with the client ID and client secret.

[crivetimihai]

Hi @mohab4, thanks for the follow-up.

1. Can you export/package tools from a virtual server and deploy on another gateway?

Yes, via the export/import API:

• Export: GET /export returns all configuration (tools, servers, gateways) as JSON
• Import: POST /import accepts that JSON on the target gateway

Note: There's a known bug (#2960) where the import endpoint silently ignores CLI parameters and rejects raw export data. PR #3166 fixes this — make sure you're on the latest version.

Better option — federation:

Instead of export/import, register Gateway A as an upstream MCP server on Gateway B:

1. On Gateway B: POST /gateways with url pointing to Gateway A's virtual server endpoint
2. Gateway B discovers and proxies tools from Gateway A automatically
3. Changes on Gateway A are reflected without manual re-export

2. Can ContextForge transform mTLS-based APIs into MCP servers?

Yes, with these options:

• Per-gateway CA certificates: When registering an upstream gateway, provide a ca_certificate field with the custom CA cert. The gateway creates a custom SSL context for that connection.
• Global SSL bypass: Set SKIP_SSL_VERIFY=true for development with self-signed certs (not recommended for production).
• mTLS support: Implemented in PR feat: plugin client server mtls support #1196 (issue [FEATURE][SECURITY]: mTLS support for gateway, plugins, and MCP servers #568, now closed). Supports mutual TLS for plugin communication and upstream connections.
• Per-tool SSL: Not yet supported — tracked as [FEATURE][API]: Per-tool SSL certificate configuration for REST API endpoints #3527. Currently, SSL settings are per-gateway or global, not per-tool.

For client_id/client_secret, configure the gateway entry with auth_type: "oauth2" and provide the OAuth credentials — the gateway handles token acquisition automatically.