10

単一の実稼働環境で発生する、頭を悩ませる問題があります。

A と B の 2 人のユーザーがいます。ユーザー A がログインすると、すべて正常に動作します。ユーザー B がログインし、ユーザー B がログインした後、ユーザー A はユーザー B と同じセキュリティ トークンを持っています。

私たちの WIF セットアップはかなり標準的で、トークンにいくつかのカスタム クレームを挿入しますが、トークンの作成方法と保存方法 (WIF によって処理される) に関する限り、他のすべては標準に見えます。

私がよく知らないWIFで奇妙なエッジケースに遭遇したように感じます

更新: A と B の両方を別のマシンに配置することも、同じマシン上の別のブラウザーに配置することもできます。

サービスをリクエストするときにトークンを取得する場所

if (HttpContext.Current == null)
    return null;

if (HttpContext.Current.Cache == null)
    return null;

if (FederatedAuthentication.SessionAuthenticationModule == null)
    return null;

if (FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken == null)
    return null;

var sessionToken = FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken;
if (sessionToken.ClaimsPrincipal == null)
    throw new InvalidOperationException("The ClaimsPrincipal property of the FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken object is null");
if (sessionToken.ClaimsPrincipal.Identities == null)
    throw new InvalidOperationException("The ClaimsPrincipal.Identities sub-property of the FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken object is null");
if (sessionToken.ClaimsPrincipal.Identities.Count == 0)
    throw new InvalidOperationException("The ClaimsPrincipal.Identities sub-property of the FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken object has no identities");
if (sessionToken.ClaimsPrincipal.Identities[0] == null)
    throw new InvalidOperationException("The first identity in the ClaimsPrincipal.Identities sub-property of the FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken object is null");
if (sessionToken.ClaimsPrincipal.Identities[0].Claims == null)
    throw new InvalidOperationException("The first identity in the ClaimsPrincipal.Identities sub-property of the FederatedAuthentication.SessionAuthenticationModule.ContextSessionSecurityToken object as a null Claims property");

return TokenUtility.GetDelegatedToken(IssuedTokenTypes.UserProfile | IssuedTokenTypes.AccountPermissions, sessionToken);

sessionToken.ClaimsPrincipal.Identity.Nameここにロギングを追加すると、この時点で想定されている名前とは異なることがわかります。

4

3 に答える 3

1

証明書利用者と STS(WIF) サーバーは、同じアプリケーション プールを使用して同じ IIS でホストされていますか? はいの場合は、別のアプリケーション プールを使用してみてください。これは、ワーカー プロセスが混乱させるために使用することがあります。これがあなたを助けることを願っています。

于 2014-01-26T09:02:03.893 に答える
0

私は同様の問題を見てきました。IIS とコード内のキャッシュを変更することで解決しました。キャッシングによりセキュリティが台無しになっているように見えましたが、サーバーは生成されたhtmlの最後の結果を保存しているだけで、ユーザーBではなくユーザーAがログインしているように見えました.

于 2013-04-01T17:29:31.260 に答える