12

複合キーを使用したマルチテナントデータベースがあります

clientId - docId

ルーティングは次のようになります

/api/controller/clientId/docId

認証には、https経由ですべてのリクエストのhttpヘッダーで送信される電子メール+パスワードなどの「グローバル」ユーザー名を使用します。ユーザー名はクライアントに明示的にマップされ、バックエンドで使用できます。

休息をとって適切にそれを行い、最高のセキュリティを確保する方法は何ですか？

  1. 上記のようにルーティングし、ユーザー名に従ったclientIdがルーティングと同じであることを確認します

また

  1. 以下のようにルーティングを変更し、レコードを保存する前にデータベースからclientIdを取得しますか？

    /api/controller/docId

これは明らかな質問かもしれませんが、潜在的なセキュリティの問題が心配です。それとも、より短いルーティングを使用するのは簡単ですか？

ありがとう！

4

2 に答える 2

8

おそらく最良のアイデアだと思います。/api/controller/docIdまたは、単一の代理キーを使用して ClientId と docId (私の好み) を表します。

クライアントが他のクライアント リソースを表示できるようにする必要がない限り、私はそれを URI スキームから非表示にします。最悪の場合、クライアントを認証し、クライアントが誰であるかを知っているので、せいぜい情報漏洩と見なされる可能性があります。これはオーバーヘッドでもあります。つまり、URL のクライアント ID がリクエストのユーザー名とパスワードにマップされていることを確認する必要があるため、とにかく各リクエストでクライアント ID を取得する必要があります。

Sales Force などの他のマルチテナント環境がどのように機能するかを見ると、セキュリティ メカニズムを介してクライアントを推測する必要があるか、幸運にもすべてのオブジェクト/リソースに一意の ID を持っていることがわかります。

私が見たアプローチは、/api/{clientId}/controller/docId. マルチテナント環境では、すべてのリソースはおそらく/定義上、そのクライアントに固有です。

このアプローチの理由として、顧客ごとに一意の URL を使用するとキャッシングが容易になるということがあります... /api/{clientId}/controller/docId または /api/controller/{clientId}/docId

基本認証に関する簡単な注意事項

あなたのアプローチに問題はありませんが、考慮してください...パスワードとユーザー名を検証しながらクライアントIDを取得し、それをIPrincipleのクレームとして追加できます。少なくとも、それを見つけるためにさらにデータベースを検索することなく、コードで利用できます（そのリクエストの有効期間内）。

さらに一歩進んで...実際にトークンに含まれるクライアントIDをクレームとしてトークンが発行される（正しいユーザー名とパスワードに従って）2段階認証メカニズムを検討してください。このように、トークンを使用した後続のリクエストは、情報を認証して取得するためにリクエストごとにデータベースをコールバックする必要がないことを意味します。OAuthベアラートークンhttp://self-issued.info/docs/draft-ietf-oauth-v2-bearer.html（必ず署名してください）または他のアプローチのいくつかを見てください...

于 2012-12-07T11:39:47.573 に答える
7

/tenant/docidマークのアプローチは完全に有効ですが、テナントごとにデータベースが異なるため、たまたま使用しています。URIにテナントを含めない場合、接続するデータベースを決定してドキュメントを探すのは非常に困難です。

于 2012-12-07T13:55:31.633 に答える