janhoy commented on PR #160: URL: https://github.com/apache/solr-mcp/pull/160#issuecomment-5111442898
Hi, I am not deeply familiar withe the low-level code in mcp-server, but I get the design decision of a fixed solr credential, and that the http-mode is secured with oauth2 by default. This should likely be elevated to a dev-list discussion, but IMO it will be a can of worms to try to do fine-grained auth/authz on the mcp-server level and support true multi-tenant users. I'm tempted to document in the project and threat model that the only supported and recommended mode for using solr-mcp is for each user to have their own instance of solr-mcp with their own designated personal SOLR_USER/SOLR_PASSWORD pair - which maps to a user/roles on the solr-backend side that decides what that user is allowed to do. Such a clarification would make a 1:1 connection to the user writing the prompt and the permission that user is given in solr backend. This means that one person might need to setup two instances of solr-mcp, one for normal work and an elevated instance of admin work. If we document such a constraint, we can effectively forward any permission vulnerability report to the solr server itself, since the mcp user is just using solr-mcp as any other solr client that acts on her behalf. I.e. if a vuln. report comes in that user Y can do destructive action Z, that will always be due to mis-configured solr-server. In a later version of solr-mcp we can try to aim for multi tenancy or forwarding credentials. WDYT @epugh - are we ready to decide here or should we bring it up as a topic on the dev list first? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
