私のGoogle fooは確かに弱かった。答えは私の質問のリンクのすぐ後ろにあります。したがって、誰かが最終的に同じ質問をする場合に備えて、このブログへのリンクをいくつか示します。
まず、「そのクレーム セットのもの」を理解しようとする必要があります。
次に、クレーム セットがどこから来たのかを知る必要があります。
この知識があれば、実際には非常に簡単になります。
私の理解が正しければ、基本的なワークフローは次のようになります。
- クライアントは を
SecurityToken
使用して を作成しますSecurityTokenProvider
- クライアントは
SecurityToken
、SecurityTokenSerializer
- サーバーは
SecurityToken
、SecurityTokenSerializer
- サーバーは
IAuthorizationPolicy
を使用して を作成しますSecurityTokenAuthenticator
- サーバーは から作成
AuthorizationContext
しIAuthorizationPolicy
ます
- 終わり
例:
// Create the SecurityTokenProvider
var p = new UserNameSecurityTokenProvider("username", "password");
// Get the SecurityToken from the SecurityTokenProvider
var t = p.GetToken(TimeSpan.FromSeconds(1.0)) as UserNameSecurityToken;
// ... transmit SecurityToken to server ...
// Create the SecurityTokenAuthenticator
var a = new CustomUserNameSecurityTokenAuthenticator(
UserNamePasswordValidator.None);
// Create IAuthorizationPolicies from SecurityToken
var i = a.ValidateToken(t);
// Create AuthorizationContext from IAuthorizationPolicies
var c = AuthorizationContext.CreateDefaultAuthorizationContext(i);
ShowClaims(c.ClaimSets);
X509SecurityToken
s には / を使用しX509SecurityTokenProvider
ますAuthenticator
。WindowsSecurityToken
s にはWindowsSecurityTokenAuthenticator
プロバイダーはありますが、プロバイダーはありません。代わりに、WindowsSecurityToken
コンストラクターを使用します。
var t = new WindowsSecurityToken(WindowsIdentity.GetCurrent());
これは非常にうまく機能します。上記で省略したのは、トークンのシリアル化だけです。SecurityTokenSerializer
.NET フレームワークに 1 つの実装を持つクラスがあります。WSSecurityTokenSerializer
それは、WCF に付属するクラスです。
UserNameSecurityToken
s とs のシリアルX509SecurityToken
化は魅力的ですが (逆シリアル化は試していません)、WindowsSecurityToken
s は明らかにシリアライザーでサポートされていません。これにより、既に持っている 2 つの認証方法 (証明書とユーザー名/パスワード) が残りますが、とにかくそれを望まなかったのでAuthorizationContext
、私が持っているものを使い続けます :)