與多租戶數據庫REST API的客戶端

分開後，我有複合鍵與多租戶數據庫REST API的客戶端

clientId - docId

路由看起來是這樣的

/api/controller/clientId/docId

爲了驗證我使用了「全球多租戶數據庫「用戶名，例如電子郵件+密碼，通過https在每個請求的http-header中發送。用戶名顯式映射到客戶端，並在後端可用。

什麼是與休息，做正確，並有最佳的安全的方式嗎？

路線等上方和正驗證根據用戶名的的clientId比在路由

或

更改，如下所述路由相同，並從的clientId保存記錄之前的數據庫？

/api/controller/docId

這可能是一個很明顯的問題，但我很擔心潛在的安全問題。或者只是簡單的路由選擇而已？

謝謝！

來源

2012-12-07 Benjamin E.

我覺得/api/controller/docId可能是最好的辦法還是使用單一的代理鍵來代表客戶端Id和的docId（我的偏好）。

除非您需要允許客戶端查看其他客戶端資源，否則我會將其從URI方案中隱藏起來，在最壞的情況下，它可能被認爲是信息泄漏，因爲您已驗證客戶端並知道他們是誰。這也是一個開銷，即你仍然必須檢查在URL中的客戶端ID映射到請求的用戶名和密碼，所以你需要反正檢索每個請求的客戶端ID。

如果你看如何等多租戶環境中工作，例如銷售隊伍的你可以看到他們必須通過安全機制來推斷客戶，或者有幸爲每個對象/資源擁有一個唯一的ID。

我見過的一種方法是在URL的根把客戶標識符（通常somekind的的代理鍵，避免讓其他用戶數據庫的ID！）如/ API/{的clientId} /控制器/的docId。在多租戶環境中，每個資源可能/根據定義，該客戶端是唯一的。

有時這種方法給的理由是，有每個客戶助攻唯一的URL與緩存.../API/{}的clientId /控制器/的docId或/ API /控制器/ {}的clientId /的docId

關於基本身份驗證的簡要說明

您的方法沒有任何問題，但請考慮......您可以在驗證密碼和用戶名時檢索客戶端ID，並將其添加爲原則上的聲明。至少可以在代碼中使用，而無需進一步查找數據庫（在請求的生命週期內）。

更進一步...考慮一個兩步認證機制，其中令牌作爲聲明在令牌中發放（遵循正確的用戶名和密碼），而客戶端ID實際上在令牌中。這樣，使用令牌的後續請求意味着您將不需要爲每個請求回撥數據庫來驗證和檢索信息。看看OAuth承載令牌http://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html（一定要簽名）或其他一些方法...

來源

2012-12-07 11:39:47

馬克的方法是完全有效的，但是，我碰巧使用/tenant/docid，因爲每個租戶都有不同的數據庫。如果您不在URI中包含租戶，那麼試圖確定要連接哪個數據庫並搜索該文檔將會是一個真正的痛苦。

來源

2012-12-07 13:55:31

我也有類似的情況。您是否考慮將租戶ID存儲爲用戶聲明（或訪問令牌/憑證上的類似內容）？我認爲將租戶作爲URI的一部分是理想的，但在應用於現有軟件時需要更多的工作。 – bjornhol

@bjornhol如果租戶ID不包含在URL中，那麼它會使本地緩存變得困難，因爲我使用整數而不是標識符的guid，因此租戶之間可能會發生衝突。 –

與多租戶數據庫REST API的客戶端

回答

相關問題