スタートアップ¶
IdentityServerは、ミドルウェアとサービスの組み合わせです。すべての設定はスタートアップクラスで行われます。
サービスの設定¶
IdentityServerサービスをDIシステムに追加するには、次の関数を呼び出します。:
public void ConfigureServices(IServiceCollection services)
{
var builder = services.AddIdentityServer();
}
オプションで、この呼び出しにオプションを渡すことができます。オプションの詳細については ここを 参照してください。
これはビルダーオブジェクトを返します。ビルダーオブジェクトには、追加のサービスを結ぶ便利なメソッドが多数あります。
Key material¶
AddSigningCredential- 指定された鍵素材をさまざまなトークン作成/検証サービスに提供する署名鍵サービスを追加します。
X509Certificate2、SigningCredentialまたは証明書ストアからの証明書への参照を渡すことができます。
AddDeveloperSigningCredential- 起動時に一時的なキーマテリアルを作成します。これは、開発者が使用する証明書を持っていない場合のみのシナリオです。生成された鍵はファイルシステムに永続化され、サーバの再起動の間に安定した状態になります(渡すことで無効にすることができます
false)。これは、開発中にクライアント/ apiメタデータキャッシュが同期しなくなった場合の問題を解決します。
AddValidationKey- トークンを検証するためのキーを追加します。それらは内部トークンバリデーターによって使用され、ディスカバリー文書に表示されます。
X509Certificate2、SigningCredentialまたは証明書ストアからの証明書への参照を渡すことができます。これは、重要なロールオーバーシナリオに役立ちます。
In-Memory configuration stores¶
さまざまな「メモリー内」構成APIを使用すると、構成オブジェクトのメモリー内リストからIdentityServerを構成できます。これらの「インメモリ」コレクションは、ホスティングアプリケーションでハードコーディングすることも、構成ファイルやデータベースから動的にロードすることもできます。ただし、設計上、これらのコレクションはホスティングアプリケーションの起動時にのみ作成されます。
これらの構成APIの使用は、実行時に構成データをデータベースに動的に照会する必要がないプロトタイピング、開発、および/またはテストの際に使用するために設計されています。この構成のスタイルは、構成がほとんど変更されない場合や、値を変更する必要がある場合にアプリケーションを再起動する必要がある場合には、実動シナリオにも適しています。
AddInMemoryClients- Registers
IClientStoreandICorsPolicyServiceimplementations based on the in-memory collection ofClientconfiguration objects.
AddInMemoryIdentityResources- Registers
IResourceStoreimplementation based on the in-memory collection ofIdentityResourceconfiguration objects.
AddInMemoryApiResources- Registers
IResourceStoreimplementation based on the in-memory collection ofApiResourceconfiguration objects.
Test stores¶
The TestUser class models a user, their credentials, and claims in IdentityServer.
Use of TestUser is simiar to the use of the "in-memory" stores in that it is intended for when prototyping, developing, and/or testing.
The use of TestUser is not recommended in production.
AddTestUsers- Registers
TestUserStorebased on a collection ofTestUserobjects.TestUserStoreis used by the default quickstart UI. Also registers implementations ofIProfileServiceandIResourceOwnerPasswordValidator.
Additional services¶
AddExtensionGrantValidator- Adds
IExtensionGrantValidatorimplementation for use with extension grants.
AddSecretParser- Adds
ISecretParserimplementation for parsing client or API resource credentials.
AddSecretValidator- Adds
ISecretValidatorimplementation for validating client or API resource credentials against a credential store.
AddResourceOwnerValidator- Adds
IResourceOwnerPasswordValidatorimplementation for validating user credentials for the resource owner password credentials grant type.
AddProfileService- Adds
IProfileServiceimplementation for connecting to your custom user profile store. TheDefaultProfileServiceclass provides the default implementation which relies upon the authentication cookie as the only source of claims for issuing in tokens.
AddAuthorizeInteractionResponseGenerator- Adds
IAuthorizeInteractionResponseGeneratorimplementation to customize logic at authorization endpoint for when a user must be shown a UI for error, login, consent, or any other custom page. TheAuthorizeInteractionResponseGeneratorclass provides a default implementation, so consider deriving from this existing class if you need to augment the existing behavior.
AddCustomAuthorizeRequestValidator- Adds
ICustomAuthorizeRequestValidatorimplementation to customize request parameter validation at the authorization endpoint.
AddCustomTokenRequestValidator- Adds
ICustomTokenRequestValidatorimplementation to customize request parameter validation at the token endpoint.
AddRedirectUriValidator- Adds
IRedirectUriValidatorimplementation to customize redirect URI validation.
AddAppAuthRedirectUriValidator- Adds a an "AppAuth" (OAuth 2.0 for Native Apps) compliant redirect URI validator (does strict validation but also allows http://127.0.0.1 with random port).
AddJwtBearerClientAuthentication- Adds support for client authentication using JWT bearer assertions.
Caching¶
Client and resource configuration data is used frequently by IdentityServer. If this data is being loaded from a database or other external store, then it might be expensive to frequently re-load the same data.
AddInMemoryCaching- To use any of the caches described below, an implementation of
ICache<T>must be registered in DI. This API registers a default in-memory implementation ofICache<T>that's based on ASP.NET Core'sMemoryCache.
AddClientStoreCache- Registers a
IClientStoredecorator implementation which will maintain an in-memory cache ofClientconfiguration objects. The cache duration is configurable on theCachingconfiguration options on theIdentityServerOptions.
AddResourceStoreCache- Registers a
IResourceStoredecorator implementation which will maintain an in-memory cache ofIdentityResourceandApiResourceconfiguration objects. The cache duration is configurable on theCachingconfiguration options on theIdentityServerOptions.
AddCorsPolicyCache- Registers a
ICorsPolicyServicedecorator implementation which will maintain an in-memory cache of the results of the CORS policy service evaluation. The cache duration is configurable on theCachingconfiguration options on theIdentityServerOptions.
Further customization of the cache is possible:
The default caching relies upon the ICache<T> implementation.
If you wish to customize the caching behavior for the specific configuration objects, you can replace this implementation in the dependency injection system.
The default implementation of the ICache<T> itself relies upon the IMemoryCache interface (and MemoryCache implementation) provided by .NET.
If you wish to customize the in-memory caching behavior, you can replace the IMemoryCache implementation in the dependency injection system.
Configuring the pipeline¶
You need to add IdentityServer to the pipeline by calling:
public void Configure(IApplicationBuilder app)
{
app.UseIdentityServer();
}
注釈
UseIdentityServer includes a call to UseAuthentication, so it's not necessary to have both.
There is no additional configuration for the middleware.
Be aware that order matters in the pipeline. For example, you will want to add IdentitySever before the UI framework that implements the login screen.