汎用認証サイトのファーストステップガイド (1)

「Open棟梁 wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る
  • ファーストステップ (1)
  • ファーストステップ (2)
  • ファーストステップ (3)
  • ファーストステップ (4)
  • ファーストステップ (5)
  • ファーストステップ (6)
  • ファーストステップ (7)

目次 †

概要 †

汎用認証サイト（Multi-purpose Authentication Site）
の導入前の評価を行うためのファーストステップガイド。

(1) 前提 †

ターゲット＆ポジション †

v01-95時点の前提環境 †

• Visual Studio 2019

• ランタイム
  • .NET Framework 4.8
  • .NET Core 3.0

• データ・ストア

• メモリストア
  検証ではストレージは不要

• RDBMS
  • SQL Server
  • Oracle
  • PostgreSQL

• NoSQL、LDAP
  未実装だが、基本的にSTS専用モードで使用することを想定。

(2) 一式のダウンロードとセットアップ †

コチラを参照。

(3) app.configファイルを設定する。 †

以下の項目を設定する。

Administrator（システム管理者のアカウント） †

システム管理者のアカウントを入力する（以下のアカウント要件を満たす必要がある）。

• UserNameがEmailかどうか

• ユーザ名検証（既定のユーザ名は、E-mail

• パスワード検証（8文字以上の大文字・小文字、数値、記号

登録されるテストユーザのpassword †

• テスト用に登録される下記テストユーザのパスワードを入力する。

• 以下のテストユーザのパスワードとして利用される。
  https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/Controllers/AccountController.cs#L4055
  • super_tanaka@gmail.com
  • tanaka@gmail.com
  • super_sato@gmail.com
  • sato@gmail.com

• 前述と同様に、アカウント要件を満たす必要がある。

外部ログインの追加時に XSRF の防止 †

適当なランダム文字列を設定する（下記のようなサイトを使用する）。

• パスワード自動生成 (Automated Password Generator)
  http://www.graviness.com/temp/pw_creator/

JWTの署名に使用する X.509 証明書（テスト用） †

• デプロイした先に合わせX.509 証明書（テスト用）のパスを変更する。

• ココでは、Cドライブ直下ということなので、以下のようにパスを設定する。
  • C:\root\files\resource\X509\SHA256RSA_Server.pfx
  • C:\root\files\resource\X509\SHA256ECDSA_Server.pfx
  • C:\root\files\resource\MultiPurposeAuthSite?\JwkSet?.json"

必要であれば、Sessionタイムアウト検出機能を無効にする。 †

• 既定値では、Sessionタイムアウト発生時、
  Open棟梁のSessionタイムアウト検出機能が発生する。

• 必要であれば、Sessionタイムアウト検出機能を無効化する。

(4) 疎通確認を行う。 †

• この設定状態ではメモリストアを使用しているため、デバッグを停止する度にユーザが初期化されるため注意する。

• 毎回、サインアップを繰り返すのが面倒な場合は、テストユーザのアカウントを使用すると良い。

国際化対応を確認する。 †

• ブラウザの既定の言語を変更すると（以下は、IEでの設定例）

• 日英の国際化対応がされていることを確認できる。

• 国際化対応の動作を変更するには、以下のweb.configの設定を見直す。
  

  <globalization culture="ja-jp" uiCulture="auto"/>

レスポンシブデザインを確認する。 †

• 多用途 認証サイトの画面は、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のアドレスを入力して送信ボタンを押下する。

• 後は、前述のE-mailアドレスの確認（E-mail confirmation）のように、確認用リンクが送信されるので、
  ソレを使用してパスワード・リセットのプロセスを完了させることでパスワード失念時もセルフのリカバリができる。

• パスワード・リセットのプロセスの完了後、確認のためサインインが成功することを確認する。

アカウントのロックアウトを確認する。 †

• 次に、アカウントのロックアウトの確認を行うので、ヘッダに表示されているSignoutボタンを押下して一度サインアウトを行う。

• 初期状態では、5回間違えると5分間、アカウントのロックアウトが行われる（指定の回数、サインインに失敗すると以下の画面が表示される）。

• アカウントのロックアウト中はサインインが失敗することを確認し、
  指定時間経過後にアカウントのロックアウトが解除され、サインインが成功することを確認する。

(6) OAuth2の機能確認を行う。 †

Authorization Codeグラント種別 †

以下は未サインイン時のシーケンス。
サインイン済みの場合は、ログイン画面がショートカットされる。

フローを開始する。 †

スターターのリンクをクリックする。

権限を認可する。 †

• ログイン画面が表示され、サインイン後に、以下の権限認可画面が表示される。
• 権限とはスターターのリンクに設定されているscopeというクエリ文字列

  

• なお、異なるscopeでのテストを行いたい場合、この画面が表示されている状態で、
  アドレスバーのscope値を書き換えてEnterボタンを押下すればイケル。

確認画面(テスト用)で確認する。 †

• 以下の画面が表示され、Bearer Tokenを確認できる。
  ※注意 : この画面はテスト用。本来ココに表示されている情報は画面上に露見させない。
  

• 以下は確認画面(テスト用)の項目値の説明

• State
  • CSRF(XSRF)を防止するための値
  • 上段エンドポイントで取得したQuery値
  • 下段がスターターのリンクに格納したQuery値（テスト用にSessionで取得）

• Code
  Authorization CodeのCodeの値（Bearer Tokenに変換する前のコード）

• Access Token
  • 設定によって、JWT形式とASP.NET Identity形式を選択可能。
    JWTアサーションに関する詳細はコチラを参照のこと。

• 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 Token
  • Access Tokenのリフレッシュ処理に使用するRefresh Token
  • Refresh Tokenの機能は、設定によってロックダウン可能。

• ボタン
  • 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の署名・検証の処理を確認する。 †

• 画面下部のリンクから「https://jwt.io/」にアクセスして、

• 「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グラント種別 †

こちらの手順に従ってテストを行う。