具有由客户端分隔的多租户数据库的 Rest API答案

【问题标题】：Rest API with multi-tenant database separated by client具有由客户端分隔的多租户数据库的 Rest API
【发布时间】：2012-12-07 21:55:31
【问题描述】：

我有一个带有复合键的多租户数据库

clientId - docId

路由是这样的

/api/controller/clientId/docId

对于身份验证，我使用“全局”用户名，例如电子邮件 + 密码，通过 https 在每个请求的 http-header 中发送。用户名显式映射到客户端并在后端可用。

有什么方法可以在休息时正确地做到这一点并获得最佳安全性？

如上路由，只需根据用户名验证clientId与路由中的相同

或

如下更改路由并在保存记录之前从数据库中获取clientId？

/api/controller/docId

这可能是一个显而易见的问题，但我担心潜在的安全问题。还是直接选择较短的路线？

谢谢！

【问题讨论】：

标签： rest asp.net-web-api

【解决方案1】：

我认为/api/controller/docId 可能是最好的主意，或者使用单个代理键来表示 ClientId 和 docId（我的偏好）。

除非您需要允许客户端查看其他客户端资源，否则我会将其隐藏在 URI 方案中，最坏的情况是它可能被认为是信息泄漏，充其量是多余的，因为您已经验证了客户端并且知道他们是谁。这也是一种开销，即您仍然必须检查 url 中的客户端 ID 是否映射到请求的用户名和密码，因此无论如何您都需要检索每个请求的客户端 ID。

如果您查看了其他多租户环境的工作方式，例如销售人员可以看到他们必须通过安全机制推断客户，或者很幸运能够为每个对象/资源拥有一个唯一的 ID。

我见过的一种方法是将客户端标识符（通常是某种代理键，避免暴露其他用户的 db id！）在 URL 的根目录，例如/api/{clientId}/controller/docId。在多租户环境中，每个资源都可能/根据定义对于该客户来说是唯一的。

这种方法有时给出的一个原因是每个客户都有一个唯一的 url 有助于缓存... /api/{clientId}/controller/docId 或 /api/controller/{clientId}/docId

关于基本身份验证的简要说明

您的方法没有问题，但请考虑...您可以在验证密码和用户名的同时检索客户端 ID，并将其添加为 IPrinciple 的声明。至少在代码中没有任何进一步的数据库查找来找到它（在该请求的生命周期内）。

更进一步...考虑一个两步身份验证机制，其中颁发令牌（遵循正确的用户名和密码），客户端 ID 实际上在令牌中作为声明。这样，带有令牌的后续请求意味着您不需要为每个请求回调数据库来验证和检索信息。看看 OAuth 不记名令牌 http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html（一定要签名）或其他一些方法......

【讨论】：

【解决方案2】：

Mark 的方法完全有效，但是，我碰巧使用了/tenant/docid，因为每个租户都有不同的数据库。如果您在 URI 中不包含租户，那么尝试决定要连接到哪个数据库并寻找文档将是一件非常痛苦的事情。

【讨论】：

我也有类似的情况。您是否考虑将租户 ID 存储为用户声明（或访问令牌/凭据上的类似内容）？我认为将租户作为 URI 的一部分是理想的，但在应用于现有软件时需要更多工作。
@bjornhol 如果租户 ID 不包含在 URL 中，那么它会使本地缓存变得困难，因为我使用整数而不是 guid 作为标识符，因此租户之间可能会发生冲突。
@DarrelMiller 您如何看待在 http 标头中传递tenantid(guid) 以构建连接字符串和承载令牌（grant-type 'password'）来验证用户以访问控制器？我需要你的建议。谢谢。
@IshworKhanal 您可以这样做，但请记住，如果您希望 HTTP 缓存正常工作，您需要在可变标头中引用标头。
@DarrelMiller 感谢您的回复，我使用 WebApi 2 OData v3 作为表示层，使用 EF Codefirst 作为数据库层来构建水平扩展多租户 SAAS（分片基础数据库，即每个租户的 db）。我决定构建以 api 为中心的 saas，因为我不需要在每次登录时存储在会话中的任何用户凭据，但他们需要获得他们所属的租户令牌以及他们自己的不记名令牌才能访问服务的授权。当我正在构建架构 atm 时，这是否有意义和任何进一步的建议。谢谢。