この質問は、あなたの組織で何百万回も議論されたに違いないことを私は知っています. もう一発。
ビジネス オペレーションをサービスとして公開する LOB アプリケーションを設計する。
これらのサービスは、当社独自の Web アプリケーション (ASP.Net MVC)、スマート デスクトップ クライアント、モバイル クライアント、および当社のパートナーによって、Web アプリケーションまたは個別の呼び出しのいずれかを介してアクセスされます。
Web アプリケーションだけでなく、他のユーザーがサービスにアクセスしているため、サービスへの各呼び出しは認証および承認される必要があります。
最善かつ最適なセキュリティスキームは何ですか? Web アプリケーションからサービスへの各呼び出しで、認証されたユーザーの資格情報を渡すにはどうすればよいですか? (Windows ID 財団??)
これは Windows Identity Foundation の場合ですか? はいの場合、どのピースがどこに収まりますか? そしてどうやって？
ご協力いただきありがとうございます。
よろしく。
当たり前のことを言うリスクがありますが、認証と承認は 2 つの異なるものであり、アプリケーションの別の場所で処理する必要があります。
WCF では、 IAuthorizationPolicyおよびServiceAuthorizationManager型 (特に直感的な名前ではありません) を使用して認証を実装できます。これにより認証が処理されますが、認証されたユーザーをIPrincipalインスタンスにマップすることもできます。このプリンシパルをThread.CurrentPrincipalに割り当てて、後でアプリケーションの実装内からアクセスできるようにすることができます。
Windows Identity Foundation (WIF) は、主に認証に関連する新しい機能を提供します。これは、IClaimsPrincipal インターフェイスを定義することによって IPrincipal の上に構築されますが、概念は同じままです。
フェデレーション パートナーとのクレーム ベースのセキュリティを実装する必要がある場合は、WIF が正しい選択です。AD から内部ユーザーを認証および承認する必要があるだけなら、それは私の最初の選択肢ではありません。
ただし、Liskov Substitution Principleに従い、 IPrincipal に対してのみコードを記述した場合は、後でクレーム ベースの ID を処理する必要があることが判明した場合に、WIF を改良することができます。