「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
汎用認証サイト(Multi-purpose Authentication Site)
の導入前の評価を行うためのファーストステップガイド。
(1) 前提 †
v01-95時点の前提環境 †
- ランタイム
- .NET Framework 4.8
- .NET Core 3.0
- NoSQL、LDAP
未実装だが、基本的にSTS専用モードで使用することを想定。
(2) 一式のダウンロードとセットアップ †
コチラを参照。
以下の項目を設定する。
Administrator(システム管理者のアカウント) †
システム管理者のアカウントを入力する(以下のアカウント要件を満たす必要がある)。
登録されるテストユーザのpassword †
外部ログインの追加時に XSRF の防止 †
適当なランダム文字列を設定する(下記のようなサイトを使用する)。
JWTの署名に使用する X.509 証明書(テスト用) †
- ココでは、Cドライブ直下ということなので、以下のようにパスを設定する。
- C:\MultiPurposeAuthSite?\root\programs\MultiPurposeAuthSite?\CreateClientsIdentity?\CreateClientsIdentity_RS256.pfx
- C:\MultiPurposeAuthSite?\root\programs\MultiPurposeAuthSite?\CreateClientsIdentity?\CreateClientsIdentity_RS256.cer"
なお、EnableCustomTokenFormatをOFFにすると、JWT形式のアクセストークンを発行しなくなるため、X.509証明書も不要になる。
(4) テスト用の証明書をインストールする。 †
必要に応じて、以下の位置にあるテスト用のJWT署名・検証用の証明書をインストールする。
- C:\MultiPurposeAuthSite?\root\programs\MultiPurposeAuthSite?\CreateClientsIdentity?
*.cer †
CreateClientsIdentity_RS256.cer をダブルクリックし、
「信頼されたルート証明機関」にインストール
*.pfx †
CreateClientsIdentity_RS256.pfx をダブルクリックし、
証明書のインポートウィザードを使用してインストール(パスワードは "test")
(5) 疎通確認を行う。 †
- この設定状態ではメモリストアを使用しているため、デバッグを停止する度にユーザが初期化されるため注意する。
- 毎回、サインアップを繰り返すのが面倒な場合は、テストユーザのアカウントを使用すると良い。
国際化対応を確認する。 †
- ブラウザの既定の言語を変更すると(以下は、IEでの設定例)
レスポンシブデザインを確認する。 †
- 多用途 認証サイトの画面は、Open棟梁2.0テンプレートを使用しており、レスポンシブデザインに対応している。
- レスポンシブデザインの確認のため、画面サイズを小さくすると、
以下のようにメニューがハンバーガーメニューに変更されることを確認する。
サインアップする。 †
ヘッダに表示されているSignupボタンを押下してサインアップ画面に遷移してサインアップを行う。
E-mail confirmationを確認する。 †
E-mailアドレスの確認(E-mail confirmation)を行う。
確認用リンクを取得する。 †
この設定状態はデバッグモードなのでVisual Studioのデバッグ画面に確認用リンクが表示される。
※ 本番時は、E-mailに本、確認用リンクを含んだE-mailが送信される。
確認用リンクを貼り付けてアクティベーションする。 †
確認用リンクをブラウザのアドレスバーに貼り付けてEnter押下で
アカウントがアクティベーションされ、以下の画面が表示される。
「ログインするにはここをクリックしてください。」を押下してログイン画面に遷移する。
サインインを確認する。 †
ログイン画面でサインインする。
アカウントを編集する。 †
- サインインした後、ヘッダに表示されている「こんにちは[メールアドレス]さん!」をクリックし、アカウント編集を行う。
- この設定状態では、SecurityStamp?機能が有効になっている。
この場合、編集後、幾らか時間が経過した後に自動的にサインアウトするので注意する。
ユーザ名を変更する †
- UserName?=メアド
メアド変更なので、E-mail confirmationが実行される。
- UserName?=メアド以外
メアドではないので、E-mail confirmationが実行されない。
設定によっては、パスワード入力が求められる。
メアドを追加・削除する †
- UserName?≒メアド以外の場合は、こちらになる。
- E-mail confirmationが実行される。
パスワードを変更する。 †
- [パスワードの変更]リンクを押下して、[パスワードの変更]画面に遷移し、パスワード変更を行う。
- 再度サインインする際、変更後のパスワードでサインインできることを確認する。
電話番号を設定する。 †
- [電話番号の設定]リンクを押下して、[電話番号の設定]画面に遷移し、電話番号設定を行う。
- [電話番号の設定]を行うと、電話番号の確認(TelNum? confirmation)が行われる。
- この設定状態はデバッグモードなのでVisual Studioのデバッグ画面に確認コードが表示される。
※ 本番時は、携帯電話(スマホ)に本コードを含んだSMSが送信される。
- 確認コードを入力して実行すると以下の画面が表示される。
- 必要に応じて、[電話番号の削除]リンクを押下して、電話番号の削除をテストする。
2要素認証をオンにする。 †
- 2要素認証の[有効にする]リンクを押下して、2要素認証をオンにする。
- この状態で別のブラウザ(Chrome ---> Internet Explorer)を立ち上げてサインインを試みる。
- すると、以下のような画面が表示されるので、好みの通知プロバイダを選択して送信を押下する。
(電子メールコードと電話コードから選択可能だが、電話コードは電話番号を入力しておかないと表示されない)
- 後は、前述の電話番号の設定のように、確認コードが送信されるので、
ソレを使用して2要素認証のプロセスを完了することで、別ブラウザでもサインインできるようになる。
属性データ(非定型データ)の管理(編集) †
- [属性データの設定]リンクを押下して、属性データの追加画面を表示する。
- [属性データの変更]・[属性データの削除]リンクで、属性データの変更が可能。
OAuth2データの管理(編集とToken取得) †
- [OAuth2データの設定]リンクを押下して、OAuth2データの追加画面を表示する。
- [OAuth2アクセストークンの取得]リンクを押下すると、
サインイン・ユーザに向けたOAuth2アクセストークンを取得できる。
パスワードをリセットする。 †
- 次に、パスワード・リセットを行うので、ヘッダに表示されているSignoutボタンを押下して一度サインアウトを行う。
- ヘッダに表示されているSignupボタンを押下してサインアップ画面に遷移する。
- このサインアップ画面で、「パスワードを忘れた場合。」リンクを押下する。
- すると、以下の「パスワードを忘れましか?」画面に遷移するため、
自分のアカウントのE-mailのアドレスを入力して送信ボタンを押下する。
- パスワード・リセットのプロセスの完了後、確認のためサインインが成功することを確認する。
アカウントのロックアウトを確認する。 †
- 次に、アカウントのロックアウトの確認を行うので、ヘッダに表示されているSignoutボタンを押下して一度サインアウトを行う。
- アカウントのロックアウト中はサインインが失敗することを確認し、
指定時間経過後にアカウントのロックアウトが解除され、サインインが成功することを確認する。
(6) OAuth2の機能確認を行う。 †
Authorization Codeグラント種別 †
以下は未サインイン時のシーケンス。
サインイン済みの場合は、ログイン画面がショートカットされる。
フローを開始する。 †
スターターのリンクをクリックする。
権限を認可する。 †
- ログイン画面が表示され、サインイン後に、以下の権限認可画面が表示される。
- 権限とはスターターのリンクに設定されているscopeというクエリ文字列
- なお、異なるscopeでのテストを行いたい場合、この画面が表示されている状態で、
アドレスバーのscope値を書き換えてEnterボタンを押下すればイケル。
確認画面(テスト用)で確認する。 †
- 以下の画面が表示され、Bearer Tokenを確認できる。
※注意 : この画面はテスト用。本来ココに表示されている情報は画面上に露見させない。
- State
- CSRF(XSRF)を防止するための値
- 上段エンドポイントで取得したQuery値
- 下段がスターターのリンクに格納したQuery値(テスト用にSessionで取得)
- Code
Authorization CodeのCodeの値(Bearer Tokenに変換する前のコード)
- Json
JWT形式の場合、ペイロード部分をBase64UrlデコードしたJSON文字列。
これは、IDトークンとホボ同じ形式。これに、roles、scopesを追加してある。
{
"iss": "http://jwtssoauth.opentouryo.com",
"aud": "xxxx",
"nonce": "xxxx",
"sub": "xxxx@gmail.com",
"iat": "nnnnnnnnnn",
"exp": "nnnnnnnnnn",
"email": "xxxx@gmail.com",
"email_verified": "True",
"phone_number": "",
"phone_number_verified": "False",
"scopes": [
"profile",
"email",
"phone",
"address",
・・・
],
"roles": [・・・]
}
- ボタン
- Refresh
Refresh Tokenを用いてAccess Tokenのリフレッシュする Tokenエンドポイントを呼び出す。
- Get user claim
Access Tokenを使用してユーザーのクレーム情報を取得するResources ServerのWeb APIを呼び出す。
ココでは、以下のようなJSONが返る。
{
"sub": "xxxx@gmail.com",
"email": "xxxx@gmail.com",
"email_verified": "True",
"phone_number": "",
"phone_number_verified": "False"
}
- Response
サーバーで行ったHTTPClientを使用したRESTのレスポンスを表示する。
JWTの署名・検証の処理を確認する。 †
- 「Encoded PASTE A TOKEN HERE」欄に前述の「Access Token(Jwt)」を貼り付ける。
- すると、JWTのヘッダーとペイロードがBase64UrlデコードされJSONが表示される。
- 次に、「ALGORITHM」欄のドロップダウンリストを「RS256」に切替える。
- この状態で、以下のpublicKey.key中の公開鍵を「VERIFY SIGNATURE」欄のPublic Keyに貼り付けると、
C:\MultiPurposeAuthSite??\root\programs\MultiPurposeAuthSite??\CreateClientsIdentity??\publicKey.key
- [Invalid Signature](赤)→[Signature Verified](青)に表示が切り替わり、JWTの署名が検証されたことを確認できる。
Implicitグラント種別 †
以下は未サインイン時のシーケンス。
サインイン済みの場合は、サインイン画面がショートカットされる。
フローを開始する。 †
スターターのリンクをクリックする。
確認画面(テスト用)で確認する。 †
- [Get user claim]ボタンを押下するとAccess Tokenを使用してユーザーの
クレーム情報を取得するResources ServerのWeb APIを呼び出すことができる。
- 以下のようにWeb API呼出の結果が表示される。
Resource Owner Password Credentialsグラント種別 †
こちらの手順に従ってテストを行う。
Client Credentialsグラント種別 †
こちらの手順に従ってテストを行う。