バックエンドサービスにユーザーを認証するためにSAMLベアラトークンを使用するのは悪い考えですか？

Question

バックエンドサービスからデータを取得するフロントエンドアプリケーションがあるとします。サービスは、エンドユーザーが認証されていること、サービスを使用する権限があること、および場合によってはユーザーの特権に基づいて返されたデータをフィルタリングすることを確認する必要があります。私の場合は、フロントエンド・アプリケーションとバックエンド・サービスの両方が認証のためにAzure ACSに依存しています。

理想的にはフロントエンドがに（WS-トラストに指定されている）ActAsトークンを使用するための良いフィットのように聞こえる認証されたユーザーに代わって行為をしたいと思います。しかし、それはACS does not currently support ActAsであることが分かります。

には、実際のベアラートークン（フロントエンドアプリケーションのブートストラップトークン）を使用して、バックエンドサービスを認証することができます。 It's not hard to do、しかしそれは何らかの理由で悪い考えですか？

Answer 1

フロントエンドのアプリケーションから、トークンをそのまま送信するか、そこから属性を送信することで、エンドユーザーのIDデータを確実に渡すことができます。どちらにも問題はあります。前者の場合、暗号化されていれば、フロントエンドとバックエンドは復号化に必要な秘密鍵を共有する必要があります。バックエンドがそれに対して有効なトークンを考慮するために、視聴者の制限などを共有しなければならない。言い換えれば、フロントエンドとバックエンドは2つではなく、1つの信頼パーティになります。問題ではないかもしれませんが、注意してください。後者の場合、独自の方法でユーザーデータを送信することになり、時間の経過とともに統合コストと保守コストが増加する可能性があります。どちらの場合でも、転送レベルで使用される証明書などの他の種類の資格情報を使用してバックエンドへのフロントエンドアプリケーションを認証することができます。

OAuth 2をお勧めします。this blog postから、ACSはそれをサポートしているようですが（最初の手の経験はありませんが） OAuth 2の本当に素晴らしいことは、委任を呼び出すことであり、WS-TrustのActAsほど複雑ではありません。正味の結果は同じです。つまり、バックエンドサービスには呼び出し元のサービスとエンドユーザーに関する情報がありますが、それを比類のないものにするための努力があります。トークンは引き続きベアラトークンになりますが、SSLを使用することである程度軽減することができます。 SSL以外にもいくつかの対策を加えることができますが、MicrosoftがACSで何かしたのは、GoogleがPKIに連鎖する非対称キーを使用するサービスアカウント用のアクセストークンを使ったようなものです。 （BTW、私が知っているすべてのために、マイクロソフトは既にそのようなことをしているかもしれません;もしそうなら、あなたは設定されています）。

とにかく、HTH！