0

Thinktecture IdentityServer の上に wsfederation プラグインを使用して wsfed 認証を実装しています。以下のように、AuthenticateLocalAsync メソッドで独自の UserService を実装しました。

public async Task<AuthenticateResult> AuthenticateLocalAsync(string username, string password, SignInMessage message)
        {
            var requestViewModel = new SignInRequestViewModel
                              {
                                  EmailAddress = username,
                                  Password = password
                              };

            var result = await signInApplicationService.SignInAsync(requestViewModel);

            var responseViewModel = result.ViewModel;

            var claims = claimBuilder.GetClaims(responseViewModel);

            return new AuthenticateResult(
                responseViewModel.CustomerId.ToString(),
                string.Format("{0} {1}", responseViewModel.FirstName, responseViewModel.LastName),
                claims);
        }

このメソッドは、ログイン イベントがトリガーされたときに呼び出されます。ご覧のとおり、自分のデータベース リポジトリに対してユーザーを認証し、その結果から、オブジェクトで参照されAuthenticateResultて返されるクレーム オブジェクトを構築しました。

したがって、クレームはクライアントで利用できるようになったはずなので、それ以上要求する必要はないと思いましたが、実際には、GetProfileDataAsyncメソッドが呼び出される 2 番目の要求をそれ自体に作成し、ドキュメントに基づいています。

このメソッドは、ユーザーに関するクレームが要求されるたびに呼び出されます (たとえば、トークンの作成中または userinfo エンドポイント経由)。

どのような意味がありますが、データベースを再度呼び出して顧客データを再度取得し、AuthenticateLocalAsyncメソッドで行ったのと同じようにクレームを再構築する必要があるということですか?

もしそうなら、最初の認証メソッドでクレームを返すポイントは何ですか?

誰か説明してくれませんか？

ありがとう

明

4

1 に答える 1

0

GetProfileDataAsync の呼び出しには ClaimsPrincipal があります。認証段階でそこに置くクレームは、そのプリンシパルにある必要があります。したがって、db 往復は必要ありません。

そこにクレームが見つからない場合、これはバグであり、Issue Tracker で問題を開く必要があります。

于 2015-04-02T07:05:45.740 に答える