4

API で偽装 ("act as") を許可する必要があります。したがって、適切な権限を持つユーザーは、別のユーザーとして API を実行できます。この分野で採用されている特定の戦略があるかどうか疑問に思っていますか?

偽装を開始および終了するエンドポイントを作成できます。偽装を開始するには、ユーザーとそのアクセス許可を取得し、現在の要求のためにそれらをメモリにロードする必要がありますが、これは簡単なことです。その後のリクエストはどうなりますか？「Impersonated-User」を示す HTTP ヘッダーを追加するのは悪い習慣ですか? そのヘッダーが存在する場合、それを使用して後続のリクエストで認証を行いますか? その UserId で Cookie を使用するのはどうですか? それとも追加情報？

偽装されたユーザーを Thread.CurrentPrincipal に割り当てることには、(.NET impl を想定して) 追加の利点がありますか? 現在のパーミッションとロールの実装はカスタムであり、基本的にはビット配列を使用しています (ただし、これは将来変更される予定です)。

4

1 に答える 1

6

HTTP には、委任資格情報/偽装のネイティブ サポートが含まれていないため、HTTP 基本認証と、クライアントがどの他のユーザーとして行動しようとしているかを示すカスタム ヘッダーを組み合わせても問題ありません。

ただし、「なりすましの開始と終了」という考えで API を汚染することは避けたいと思います。これは、API 呼び出し間で維持する必要があるステートフル セッションの知識を意味し、サーバー側での管理がより困難になります。

クライアントに必要なすべての情報 (資格情報と偽装プリンシパル) を呼び出しごとに渡し、呼び出されるリソースに対して毎回検証するだけです。

于 2012-10-04T05:34:33.987 に答える