「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
汎用認証サイト(Multi-purpose Authentication Site)の導入前の評価を行うためのファーストステップガイド。
(1) 前提 †
v00-50時点の前提環境 †
- Visual Studio 2015
- .NET Framework 4.6
- SQL Server (Express) (メモリストアの検証ではRDBは不要)
(2) 一式のダウンロードとセットアップ †
[Download ZIP]する。 †
以下から、[Download ZIP]する。
https://github.com/OpenTouryoProject/MultiPurposeAuthSite/
- branchを選択してください。
- 現時点では、develop branchを選択(master branchにプッシュしていない)。
- 上級者は[Download ZIP]ではなく、git cloneでも可能。
localのFileSystem?に解凍する。 †
どこでもイイですが、ココではCドライブ直下に解凍した前提で説明を続けます。
一式のビルドする。 †
ビルド †
以下のバッチを実行して、汎用認証サイトをビルドします。
- 1_DeleteDir?.bat
- 2_DeleteFile?.bat
- 3_Build_Framework.bat
- 4_Build_Framework_Tool.bat
- 10_MultiPurposeAuthSite?.bat
プロキシ認証 †
- 若しくはVisual Studioから開いてビルドして下さい。
Visual Studioがプロキシ認証のCredential入力を要求してきます。
以下の項目を設定する。
Administrator(システム管理者のアカウント) †
https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/app.config#L93
システム管理者のアカウントを入力する(以下の要件を満たす必要がある)。
登録されるテストユーザのpassword †
https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/app.config#L109
外部ログインの追加時に XSRF の防止 †
https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/app.config#L140
適当なランダム文字列を設定する(下記のようなサイトを使用する)。
JWTの署名に使用する X.509 証明書 †
https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/app.config#L173
- ココでは、Cドライブ直下ということなので、以下のようにパスを設定する。
- C:\MultiPurposeAuthSite?\root\programs\MultiPurposeAuthSite?\CreateClientsIdentity?\CreateClientsIdentity_RS256.pfx
- C:\MultiPurposeAuthSite?\root\programs\MultiPurposeAuthSite?\CreateClientsIdentity?\CreateClientsIdentity_RS256.cer"
(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?機能が有効になっている。
この場合、編集後、幾らか時間が経過した後に自動的にサインアウトするので注意する。
パスワードを変更する。 †
- [パスワードの変更]リンクを押下して、[パスワードの変更]画面に遷移し、パスワード変更を行う。
- この設定状態では、SecurityStamp?機能が有効になっている。
この場合、編集後、幾らか時間が経過した後に自動的にサインアウトする。
- 再度サインインする際、変更後のパスワードでサインインできることを確認する。
電話番号を設定する。 †
- [電話番号の設定]リンクを押下して、[電話番号の設定]画面に遷移し、電話番号設定を行う。
- [電話番号の設定]を行うと、電話番号の確認(TelNum? confirmation)が行われる。
- この設定状態はデバッグモードなのでVisual Studioのデバッグ画面に確認コードが表示される。
※ 本番時は、携帯電話(スマホ)に本コードを含んだSMSが送信される。
- 確認コードを入力して実行すると以下の画面が表示される。
- 必要に応じて、[電話番号の削除]リンクを押下して、電話番号の削除をテストする。
2要素認証をオンにする。 †
- 2要素認証の[有効にする]リンクを押下して、2要素認証をオンにする。
- この状態で別のブラウザ(Chrome ---> Internet Explorer)を立ち上げてサインインを試みる。
- すると、以下のような画面が表示されるので、好みの通知プロバイダを選択して送信を押下する。
(電子メールコードと電話コードから選択可能だが、電話コードは電話番号を入力しておかないと表示されない)
- 後は、前述の電話番号の設定のように、確認コードが送信されるので、
ソレを使用して2要素認証のプロセスを完了することで、別ブラウザでもサインインできるようになる。
パスワードをリセットする。 †
- 次に、パスワード・リセットを行うので、ヘッダに表示されているSignoutボタンを押下して一度サインアウトを行う。
- ヘッダに表示されているSignupボタンを押下してサインアップ画面に遷移する。
- このサインアップ画面で、「パスワードを忘れた場合。」リンクを押下する。
- すると、以下の「パスワードを忘れましか?」画面に遷移するため、
自分のアカウントのE-mailのアドレスを入力して送信ボタンを押下する。
- パスワード・リセットのプロセスの完了後、確認のためサインインが成功することを確認する。
アカウントのロックアウトを確認する。 †
- 次に、アカウントのロックアウトの確認を行うので、ヘッダに表示されているSignoutボタンを押下して一度サインアウトを行う。
- アカウントのロックアウト中はサインインが失敗することを確認し、
指定時間経過後にアカウントのロックアウトが解除され、サインインが成功することを確認する。
(6) OAuth2の機能確認を行う。 †
Authorization Codeグラント種別 †
以下は未サインイン時のシーケンス。
サインイン済みの場合は、ログイン画面がショートカットされる。
フローを開始する。 †
スターターのリンクをクリックする。
権限を認可する。 †
- ログイン画面が表示され、サインイン後に、以下の権限認可画面が表示される。
- 権限とはスターターのリンクに設定されているscopeというクエリ文字列
確認画面(テスト用)で確認する。 †
- 以下の画面が表示され、Bearer Tokenを確認できる。
※注意 : この画面はテスト用。本来ココに表示されている情報は画面上に露見させない。
- State
- CSRF(XSRF)を防止するための値
- 上段エンドポイントで取得したQuery値
- 下段がスターターのリンクに格納したQuery値(テスト用にSessionで取得)
- Code
Authorization CodeのCodeの値(Bearer Tokenに変換する前のコード)
- Access Token
- Jwt
JWT形式のAccess Token(JWTに関する詳細はコチラを参照のこと)
- Json
JWTのペイロード部分をBase64UrlデコードしたJSON文字列。
IDトークンと同じ形式。これに、roles、scopesを追加してある。
{
"roles":["xxxx","yyyy"],
"scopes":["username","email","telno","aaa","bbb"],
"iss":"http://jwtssoauth.opentouryo.com",
"aud":"xxxx",
"sub":"xxxx@gmail.com",
"iat":"nnnn",
"exp":"nnnn",
"nonce":"nnnn",
"email":"xxxx@gmail.com"
}
- Refresh Token
Access Tokenのリフレッシュ処理に使用するRefresh Token
- ボタン
- Refresh
Refresh Tokenを用いてAccess Tokenのリフレッシュする Tokenエンドポイントを呼び出す。
- Get user claim
Access Tokenを使用してユーザーのクレーム情報を取得するResources ServerのWeb APIを呼び出す。
- 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グラント種別 †
こちらの手順に従ってテストを行う。