プロファイルサービス¶
IdentityServerでは、トークンを作成するときや、ユーザー情報やイントロスペクションエンドポイントへの要求を処理するときに、ユーザーに関する識別情報が必要になることがよくあります。デフォルトでは、IdentityServerはこのIDデータを取得するための認証クッキーの主張のみを持ちます。
ユーザにとって必要なすべての可能なクレームをクッキーに入れることは実用的ではないので、IdentityServerは、クレームをユーザの必要に応じて動的にロードするための拡張ポイントを定義します。この拡張性のポイントは、IProfileService開発者がこのインターフェイスを実装して、ユーザーのIDデータを含むカスタムデータベースまたはAPIにアクセスすることが一般的です。
IProfileService APIs¶
GetProfileDataAsync- ユーザーの申し立てを読み込むAPIです。のインスタンスが渡されますProfileDataRequestContext。
IsActiveAsync- ユーザーが現在トークンを取得できるかどうかを示すことが期待されるAPI。のインスタンスが渡されますIsActiveContext。
ProfileDataRequestContext¶
ユーザーのクレームに対するリクエストをモデル化し、そのクレームを返却する手段です。これには、次のプロパティが含まれます。
Subject- ClaimsPrincipalユーザーのモデリング。
Client- Clientクレームが要求されています。
RequestedClaimTypes- 要求されているクレームタイプのコレクション。
Caller- クレームが要求されているコンテキストの識別子（例えば、アイデンティティトークン、アクセストークン、またはユーザー情報エンドポイント）。定数IdentityServerConstants.ProfileDataCallersにはさまざまな定数値が含まれています。
IssuedClaims- Claim返されるリスト。これは、カスタムIProfileService実装によって設定されると予想されます。
AddRequestedClaims- の拡張メソッドは、ProfileDataRequestContextにIssuedClaims基づいてクレームを最初にフィルターに掛けるRequestedClaimTypes。
要求されたスコープとクレームマッピング¶
クライアントによって要求されたスコープは、トークンでクライアントに返されるユーザークレームを制御します。GetProfileDataAsyncこの方法は、動的に基づいてこれらの請求項を取得する責任があるRequestedClaimTypesのコレクションProfileDataRequestContext。
RequestedClaimTypesコレクションは、上に定義されたユーザの請求に基づいて移入されたリソースのスコープをモデル化します。要求されたスコープがアイデンティティリソースである場合、そのアイデンティティのクレームは、でRequestedClaimTypes定義されたユーザークレームタイプに基づいて設定されますIdentityResource。要求されたスコープである場合、APIリソース、その後に、特許請求の範囲は、RequestedClaimTypesで定義されたユーザ要求の種類に基づいて移入されApiResource、および/またはScope。
IsActiveContext¶
決定する要求のモデルは、現在ユーザーがトークンを取得できることです。これには、次のプロパティが含まれます。
Subject- ClaimsPrincipalユーザーのモデリング。
Client- Clientクレームが要求されています。
Caller- クレームが要求されているコンテキストの識別子（例えば、アイデンティティトークン、アクセストークン、またはユーザー情報エンドポイント）。定数IdentityServerConstants.ProfileDataCallersにはさまざまな定数値が含まれています。
IsActive- ユーザーがトークンを取得できるかどうかを示すフラグ。これは、カスタムIProfileService実装によって割り当てられることが期待されます。