docs(security): document single-tenant deployment model (#169) - #170
Merged
Conversation
Add docs/security/deployment-model.md as the single authoritative statement that the server is single-tenant and does not support multi-tenancy: each user runs their own instance with their own Solr credentials, and every action the configured Solr identity is permitted is reachable via the MCP tools by design. Authorization is delegated to Solr, not re-implemented in the MCP layer. Reference the new doc (pointer links only) from the README security list and the STDIO/HTTP transport security docs. THREAT_MODEL is intentionally left untouched; it is handled separately. Closes apache#169
Contributor
|
ping @adityamparikh |
epugh
approved these changes
Jul 30, 2026
epugh
left a comment
epugh
left a comment
Contributor
There was a problem hiding this comment.
LGTM. I asked Adi to weigh in as well as he is a core driver of this effort. We can reevaluate this post 1.0 as a new feature ;-).
adityamparikh
approved these changes
Jul 31, 2026
adityamparikh
left a comment
adityamparikh
left a comment
Contributor
There was a problem hiding this comment.
Agreed — single-tenant is the right stance for 1.0 for both modes:
- STDIO: an instance is spawned per user per client application anyway, so the 1:1 model is inherent to the transport.
- HTTP: secure by default, and the OAuth2 flow authenticates callers — but it's only an access gate; every authenticated caller still acts as the single Solr identity configured at startup.
In both modes the server holds one outbound Solr credential (optionally Basic Auth via SOLR_USERNAME/SOLR_PASSWORD), so what the tools may do is scoped in Solr, not in the MCP layer at the moment.
+1 to revisiting multi-tenancy (per-request credentials / token exchange) post-1.0.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resolves #169.
Formally documents that the Solr MCP server is single-tenant and does not support multi-tenancy: the intended deployment is one instance per user, configured with that user's own Solr credentials, and every action the configured Solr identity is permitted is reachable through the MCP tools by design. Authorization is delegated to Solr, not re-implemented in the MCP layer. Setting this expectation up front avoids "too permissive / insecure for multi-tenant use" reports for behavior that is intentional under this model.
Changes
docs/security/deployment-model.md— the single authoritative statement of the tenancy model. Concise: states the limitation, that Solr owns authorization, that HTTP-mode OAuth2 is an access gate rather than a tenant boundary, and that sharing one instance across users is unsupported (operator owns the isolation risk). Multi-tenancy noted as possible future work.THREAT_MODELis intentionally left untouched — it is handled separately in #160.