バックエンド サービスからデータをフェッチするフロントエンド アプリケーションがあるとします。(私はそうします。) サービスは、エンドユーザーが認証されていること、サービスを使用する権限があること、および場合によってはユーザーの権限に基づいて返されたデータをフィルター処理することを検証する必要があります。私の場合、フロントエンド アプリとバックエンド サービスの両方が認証のために Azure ACS に依存しています。
理想的には、フロントエンドが認証されたユーザーに代わって動作するActAsことを望みます。これは、 (WS-Trust で指定されているように) トークンを使用するのに適しているように思えます。ただし、 ACS は現在 ActAs をサポートしていないことが判明しました。
回避策として、実際のベアラー トークン(フロントエンド アプリのブートストラップ トークン) を使用してバックエンド サービスへの認証を行うことができます。難しいことではありませんが、何らかの理由で悪い考えでしょうか?
フロントエンド アプリから、トークンをそのまま送信するか、トークンから属性を送信することで、エンド ユーザーの ID データを確実に渡すことができます。どちらにも問題があります。前者の場合、それも暗号化されている場合、フロントエンドとバックエンドは復号化に必要な秘密鍵を共有する必要があります。また、バックエンドがトークンを有効と見なすために、オーディエンスの制限などを共有する必要があります。つまり、フロントエンドとバックエンドは 2 つではなく 1 つの証明書利用者になります。問題ないかもしれませんが、ご了承ください。後者の場合、独自の方法でユーザー データを送信することになり、時間の経過とともに統合とメンテナンスのコストが増加する可能性があります。どちらの場合も、他のタイプの資格情報 (トランスポート レベルで使用される証明書など) を使用して、バックエンドに対してフロントエンド アプリを認証できます。
代わりに検討することをお勧めすることの 1 つは、OAuth 2 です。このブログ投稿から、ACS がそれをサポートしているように思えます (ただし、直接の経験はありません)。OAuth 2 の本当に素晴らしい点は、委任を組み込み、WS-Trust の ActAs ほど複雑ではないことです。最終的な結果は同じです。つまり、バックエンド サービスには、呼び出し元のサービスとエンド ユーザーに関する情報が含まれますが、設定にかかる労力は比類のないものになります。トークンはベアラー トークンのままですが、SSL を使用することである程度軽減できます。SSLを超えて、いくつかの追加の対策を講じることができますが、IMOでは、GoogleがPKIにチェーンされた非対称キーを使用するサービスアカウントに対してアクセストークンを使用して行ったように、MicrosoftがACSで何かを行った場合が最善です. （ところで、私が知っている限りでは、マイクロソフトはすでにそのようなことをしているかもしれません。もしそうなら、あなたは準備ができています。）
とにかくHTH！