「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
汎用認証サイト（Multi-purpose Authentication Site）
の導入前の評価を行うためのファーストステップガイド。
(12) オプションを変更してテストする †
UserName?＝メアド以外 †
app.configファイルを設定する。 †
https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/app.config#L121
- RequireUniqueEmail? : false
サインアップ・サインインを確認する。 †
メアド以外のUserName?でサインアップ・サインインできることを確認する。
E-mailアドレスを登録する。 †
サインインした後、ヘッダに表示されている「こんにちは[メールアドレス]さん！」をクリックし、アカウント編集画面へ遷移する。
このオプションを設定した場合、[E-mailの設定]リンクが表示され、これからE-mailアドレスを登録可能。
この際、カスタムのE-mailアドレスの確認（E-mail confirmation）プロセスが実行される。
アカウント管理画面から追加・更新する。 †
アカウント管理画面からUserName?＝メアド以外のユーザーを追加・更新できることを確認する。
- UserName?＝メアド以外のユーザーが追加・更新されたことを確認する。
その他のテストケースを確認する。 †
マルチテナント †
- マルチテナントである場合と、ない場合とで、アカウント・ロールの管理画面での動作が異なる。
- アカウント・ロールの管理画面には、権限のあるアカウントでアクセスする必要がある。
app.configファイルを設定する。 †
https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/app.config#L91
マルチテナントの場合 †
- サインアップしたユーザがテナント管理者になる。
- テナント管理者のみアカウント・ロールの管理画面にアクセスできる。
- 後のユーザのアカウントは、テナント管理者が登録する。
- ロール管理画面
- システム共通のロールを参照可能。
- 自分のテナントのロールを管理（CRUD）可能。
マルチテナントでない場合 †
- システム管理者のみアカウント・ロールの管理画面にアクセスできる。
- 管理画面で可能な操作。
- ユーザ管理画面
全ユーザの管理（CRUD）が可能。
- ロール管理画面
全ロールの管理（CRUD）が可能。
(13) OAuth2の3分割テストを行う。 †
汎用認証サイトをOAuth2で登場する3つのサーバー機能に分割して動作検証をする。
- Authorization Server
- Resource Server
- Client
サイトを3分割する。 †
以下のような感じで、サイトを3分割する。
・MultiPurposeAuthSiteフォルダ
├ CreateClientsIdentityフォルダ
├ packagesフォルダ
├ MultiPurposeAuthSiteフォルダ
├ MultiPurposeAuthSiteRフォルダ
├ MultiPurposeAuthSiteCフォルダ
├ MultiPurposeAuthSite.slnファイル
├ MultiPurposeAuthSiteR.slnファイル
└ MultiPurposeAuthSiteC.slnファイル
MultiPurposeAuthSite?フォルダを3分割する。 †
- 以下のフォルダをコピーして複製し、
- C:\MultiPurposeAuthSite?\root\programs\MultiPurposeAuthSite?\MultiPurposeAuthSite?
- MultiPurposeAuthSite?
Authorization Serverの役割
- MultiPurposeAuthSiteR
Resource Serverの役割なので末尾に「R」を付与。
- MultiPurposeAuthSiteC
Clientの役割なので末尾に「C」を付与。
MultiPurposeAuthSite?.slnファイルを3分割する。 †
- 以下のファイルをコピーして複製し、
C:\MultiPurposeAuthSite?\root\programs\MultiPurposeAuthSite?\MultiPurposeAuthSite?.sln
- 以下のようにリネームする。
- MultiPurposeAuthSite?.sln
- MultiPurposeAuthSiteR.sln
- MultiPurposeAuthSiteC.sln
- それぞれ*.slnファイルをTextEditor?などで開いて、
内部で指しているMultiPurposeAuthSite?.csprojへのパスを変更する。
MultiPurposeAuthSite?.csprojのポート番号を変更する。 †
3サイト同時起動のためMultiPurposeAuthSite?.csprojのポート番号を変更する。
- 以下のファイルのポート番号部分と重複しないようにする。
- ここでは、それぞれ、以下のようにポート番号を変更した。
それぞれのapp.config設定を行う。 †
以下のファイルの設定を変更する。
C:\MultiPurposeAuthSite?\root\programs\MultiPurposeAuthSite?\MultiPurposeAuthSite?\app.config
ユーザストアをDBMSストアに変更する。 †
コチラを参考にして、ユーザストアをDBMSストアに変更する。
ResourceServer?エンドポイントの設定 †
https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/app.config#L193
Clientエンドポイントの設定 †
https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/app.config#L200
設定したapp.configを複製する。 †
- C:\MultiPurposeAuthSite?\root\programs\MultiPurposeAuthSite?\MultiPurposeAuthSite?\app.config
- C:\MultiPurposeAuthSite?\root\programs\MultiPurposeAuthSiteR\MultiPurposeAuthSite?\app.config
- C:\MultiPurposeAuthSite?\root\programs\MultiPurposeAuthSiteC\MultiPurposeAuthSite?\app.config
3つのサイトをデバッグ実行をする。 †
3つのサイトを*.slnファイルから開いてデバッグ実行をする。
*.slnファイルからWebサイトを開く †
- Authorization Serverの役割
C:\MultiPurposeAuthSite??\root\programs\MultiPurposeAuthSite?.sln
- Resource Serverの役割
C:\MultiPurposeAuthSite??\root\programs\MultiPurposeAuthSiteR.sln
- Clientの役割
C:\MultiPurposeAuthSite??\root\programs\MultiPurposeAuthSiteC.sln
それぞれ、F5を押下してデバッグ実行を開始する。 †
- ここで、[Authorization Codeグラント(client_id, response_type, scope, state)]リンクを押下する。
- すると、Authorization Serverのサインイン画面に遷移するのでログインを行う。
- サインイン後、Authorization Serverの[リソース・アクセスの認可]画面に遷移するので、権限付与の認可を行う。
- すると、Clientに戻ってきて、ここでCodeがBearer Tokenに変換される。
- そして、ClientのOAuthAuthorizationCodeGrantClient?（テスト用）画面が表示される。
- ここで、[GetUserClaim?]ボタンを押下すると、ClientからResource ServerにWebAPI呼出が行われ結果が返る。
処理フローの説明 †
(1) スターターの位置 †
ClientからAuthorization Serverへ遷移。
(2) スターターの飛び先 †
Authorization Serverでは、以下のルートで、[リソース・アクセスの認可]画面を表示。
(3) 権限付与の認可を行う。 †
Authorization Serverの[リソース・アクセスの認可]画面でポストバックすると、ClientのRedirectエンドポイントへRedirectされる。
(4) Bearer Tokenを取得する。 †
ClientのRedirectエンドポイントでBearer Tokenを取得してResourcesにアクセスする。
- ここで、仲介コードを使用してTokenエンドポイントにアクセスする。
- Access Token・Refresh Tokenのレスポンスが返る。
(5) 以下はテスト用の処理フロー †
通常、仲介コードやAccess Token・Refresh Tokenは露見させないが、
ここではテスト用に、[Authorization Code Grant]画面にこれらを表示する。
その後、以下のRefresh処理、Get user claim処理を実行することができる。
- ClientからResource ServerにWebAPI呼出が行われ結果が返る。
なお、認可処理は、WebAPI内部でscopeを確認して行う。
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
