セカンドHPKI証明書の覚書きWiki

ユーザ用ツール

サイト用ツール

トレース:
idトークン獲得の流れ

差分

このページの2つのバージョン間の差分を表示します。

この比較画面へのリンク

両方とも前のリビジョン前のリビジョン
次のリビジョン		前のリビジョン
idトークン獲得の流れ [2025/02/17 08:44] – [「管理サーバーに何を渡しているのか」の考察] adminidトークン獲得の流れ [2025/03/05 12:11] (現在) – [IDトークン獲得までの流れ] admin
行 1: 行 1:
 +~~stoggle_buttons~~
 +
 ====== IDトークン獲得までの流れ ====== ====== IDトークン獲得までの流れ ======
 ===== 全フローチャート ===== ===== 全フローチャート =====
行 40: 行 42:
   * response_type=code ← 「認可コードグラント」ということ。ExamplePublisherClient.exe は、ネイティブアプリケーションでパブリッククライアントである。パブリッククライアント向けのグラントタイプとして推奨されている「認可コードグラント+PKCE」が採用されている。   * response_type=code ← 「認可コードグラント」ということ。ExamplePublisherClient.exe は、ネイティブアプリケーションでパブリッククライアントである。パブリッククライアント向けのグラントタイプとして推奨されている「認可コードグラント+PKCE」が採用されている。
   * scope=openid ← [[https://zenn.dev/mryhryki/articles/2021-01-30-openid-connect|「scopeに openid を指定する、というのが OAuth2.0 と OpenID Connect の違いです」]]   * scope=openid ← [[https://zenn.dev/mryhryki/articles/2021-01-30-openid-connect|「scopeに openid を指定する、というのが OAuth2.0 と OpenID Connect の違いです」]]
-  * redirect_uri=http://hpkicardless-clientadapter-server:3000/authfido/callback 8番で認可コード(Access Token)をもらった後コールバックで呼び出されるurl。__自由にリダイレクトURLが設定できてしまうと、外部に認可コード(Access Token)が漏れてしまうため、事前設定されたURLのみコールバックされる。__　そのため、クライアントアダプタのFQDNの統一化「サーバ名称 hpkicardless-clientadapter-server」が図られている。+  * redirect_uri=http://hpkicardless-clientadapter-server:3000/authfido/callback 8番で認可コード(Access Token)をもらった後コールバックで呼び出されるurl。__自由にリダイレクトURLが設定できてしまうと、外部に認可コード(Access Token)が漏れてしまうため、事前設定されたURLのみコールバックされる。__　そのため、クライアントアダプタのFQDNの統一化「サーバ名称=hpkicardless-clientadapter-server」が図られている。
   * state=e3f1b42c0b5b4f5f9d7b3c9c3c8c3a9e   * state=e3f1b42c0b5b4f5f9d7b3c9c3c8c3a9e
   * code_challenge=XyZAbCdEfGHiJkLmNoPqRsTuVwXyZ1234567890= (Base64 encoded SHA-256 hash of code_verifier)   * code_challenge=XyZAbCdEfGHiJkLmNoPqRsTuVwXyZ1234567890= (Base64 encoded SHA-256 hash of code_verifier)
行 69: 行 71:
 ==== 5.2.FIDO生体認証 ==== ==== 5.2.FIDO生体認証 ====
   * Keycloakでチャレンジ・レスポンス認証が行われる。   * Keycloakでチャレンジ・レスポンス認証が行われる。
-  * 秘密鍵は、スマートフォン内のセキュアストレージに保管されており指紋認証しないとアクセスできない。 cf.https://tarumi.co.jp/Resources/doku.php?id=ジェネリック薬品:電子処方箋#セカンド証明書+  * 秘密鍵は、スマートフォン内のセキュアストレージに保管されており指紋認証しないとアクセスできない。 cf.[[https://tarumi.co.jp/Resources/doku.php?id=ジェネリック薬品:電子処方箋#セカンド証明書|セカンド証明書]]
   * 秘密鍵は、最初に{{:firstqrcode.jpg?200|}} を読み込んでパスワード入力したときに、「HPKIセカンド電子証明書」の秘密鍵がスマートフォンのセキュア領域に格納される。指紋認証できるスマホしか受け付けないのはこのため。   * 秘密鍵は、最初に{{:firstqrcode.jpg?200|}} を読み込んでパスワード入力したときに、「HPKIセカンド電子証明書」の秘密鍵がスマートフォンのセキュア領域に格納される。指紋認証できるスマホしか受け付けないのはこのため。
  
行 75: 行 77:
  
 ==== 9.1.カスタムスキーム ==== ==== 9.1.カスタムスキーム ====
-  * 通常の認可コードグラントでは [[https://tarumi.co.jp/Resources2/doku.php?id=idトークン獲得の流れ#到達urlのクエリパラメータ解説|到達urlのクエリパラメータ解説]] 中で示したリダイレクトurl http:<nowiki>//</nowiki>hpkicardless-clientadapter-server:3000/authfido/callback=xxxx がブラウザーに提示される。しかし、認可コードグラント+PKCEでは、カスタムスキーム myapp:<nowiki>//</nowiki> が呼ばれ、OSは登録されたNatie application=ExamplePublischerClient.exeをブラウザーの代わりに起動し、認可コードを受け取る。「雰囲気」77頁+  * 通常の認可コードグラントでは [[https://tarumi.co.jp/Resources2/doku.php?id=idトークン獲得の流れ#到達urlのクエリパラメータ解説|到達urlのクエリパラメータ解説]] 中で示したリダイレクトurl http:<nowiki>//</nowiki>hpkicardless-clientadapter-server:3000/authfido/callback=xxxx がブラウザーに提示される。しかし、認可コードグラント+PKCEでは、カスタムスキーム myapp:<nowiki>//</nowiki> が呼ばれ、OSは登録されたNative application=ExamplePublischerClient.exeをブラウザーの代わりに起動し、認可コードを受け取る。「雰囲気」77頁
   * ↑ により、登録されたアプリのみがコールバックを処理し、Browserの挙動も隠蔽できるため安全性が増す。   * ↑ により、登録されたアプリのみがコールバックを処理し、Browserの挙動も隠蔽できるため安全性が増す。
   * カスタムスキーム myapp:<nowiki>//</nowiki>は、Windows: Registers via the registry (HKEY_CLASSES_ROOT\myapp\shell\open\command) に登録されるとあるが見当たらない。RemoteSignatureClientAdapter.exeとExamplePublisherClient.exeの間で他の手段でやり取りされているのであろう、と推察する。なぜならIDトークンもPC上には残らず、管理サーバーからとってくる仕組みになっていることから、非常にSecuritySensitiveに作っているのだろう、と推測する。   * カスタムスキーム myapp:<nowiki>//</nowiki>は、Windows: Registers via the registry (HKEY_CLASSES_ROOT\myapp\shell\open\command) に登録されるとあるが見当たらない。RemoteSignatureClientAdapter.exeとExamplePublisherClient.exeの間で他の手段でやり取りされているのであろう、と推察する。なぜならIDトークンもPC上には残らず、管理サーバーからとってくる仕組みになっていることから、非常にSecuritySensitiveに作っているのだろう、と推測する。
  
 ===== 10.トークンリクエスト ===== ===== 10.トークンリクエスト =====
-  * ここで (OAtuh2.0の)client_id=FIDO,__client_secret=xxxxxxxxxxxxxxxx__ が送られる。+  * ここで (OAuth2.0の)client_id=FIDO,__client_secret=xxxxxxxxxxxxxxxx__ が送られる。
   * All requests are sent over HTTPS (TLS encryption) to prevent interception   * All requests are sent over HTTPS (TLS encryption) to prevent interception
  
行 170: 行 172:
   * 起動するとnode.jsが走る。   * 起動するとnode.jsが走る。
   * node.jsのWebSever上ポート番号:3000をリスニングする。   * node.jsのWebSever上ポート番号:3000をリスニングする。
-  * config.json(含、OAtuh2.0のsecret)を受け持つ。 {{ :config.json.zip |}}+  * config.json(含、OAuth2.0のsecret)を受け持つ。 {{ :config.json.zip |}}
   * IDトークンを受け取る。   * IDトークンを受け取る。
  
行 178: 行 180:
   * 署名付き電子処方箋xmlを受け取る。   * 署名付き電子処方箋xmlを受け取る。
  
-====== ExamplePublisherClientのWebAPIとライブラリ ======+====== ExamplePublisherClientのライブラリとWebAPI ======
  
  
行 254: 行 256:
  
 ==== WebAPI ==== ==== WebAPI ====
-  * ポート番号:5000で待ち受けしているRemoteSignatureClientServiceにポストする。+  * 署名APIUrlのポート番号:5000で待ち受けしているRemoteSignatureClientServiceにポストする。
   * コアの部分   * コアの部分
 <code csharp> <code csharp>
行 282: 行 284:
  
 ==== 「管理サーバーに何を渡しているのか」の考察 ==== ==== 「管理サーバーに何を渡しているのか」の考察 ====
-=== 処方箋csvの扱い ===+=== 処方箋情報の扱い ===
  
   * ライブラリを選んだ場合   * ライブラリを選んだ場合
行 301: 行 303:
 return xml; return xml;
 </code> </code>
-をみると、IDトークンとPrescriptionDocumentのHash値のみを渡しているようである。__PrescriptionDocument要素のハッシュ値のみ管理サーバーに渡し、残りのKeyinfo要素とSignedProtpery要素は、管理サーバーがもっているので、これらをセカンドHPKI証明書の秘密鍵で署名したSignatureValueをもつPrescriptionSign要素を返却__してきて、xml.SetPrescriptionSign(signedXml.SignedXmlData.Base64ToUtf());で両者を合体させているのだろう。+をみると、IDトークンとPrescriptionDocumentのHash値を、管理サーバーの署名APIに渡しているようである。__PrescriptionDocument要素のハッシュ値のみ管理サーバーに渡し、管理サーバーがもっているKeyinfo要素とSignedProtperties要素とあわせた3要素を、管理サーバーのセカンドHPKI証明書の秘密鍵で署名したSignatureValueをもつPrescriptionSign要素を返却__してきて、xml.SetPrescriptionSign(signedXml.SignedXmlData.Base64ToUtf());で両者を合体しているのだろう。
  
   * WbAPIを選んだ場合   * WbAPIを選んだ場合
行 311: 行 313:
 var result = client.UploadString(this.SignApiUri + "signature/prescription/sign", request.ToString()); var result = client.UploadString(this.SignApiUri + "signature/prescription/sign", request.ToString());
 </code> </code>
-をみると、IDトークンとcsvを渡しているようである。↑のライブラリのコードから推察すると、RemoteSignatueClientService.exeがローカルでcsvDataから、PrescriptionDocument要素を作る。__PrescriptionDocument要素のハッシュ値のみ管理サーバーに渡し、残りのKeyinfo要素とSignedProtpery要素は、管理サーバーがもっているので、これらをセカンドHPKI証明書の秘密鍵で署名したSignatureValueをもつPrescriptionSign要素を返却__してきて、ローカル処理したPrescriptionDocument要素と合体させているのだろう。+をみると、IDトークンと処方箋csvをRemoteSignatueClientServiceに渡しているようである。↑のライブラリのコードから推察すると、RemoteSignatueClientService.exeがローカルでcsvDataから、PrescriptionDocument要素を作る。__PrescriptionDocument要素のハッシュ値のみ管理サーバーに渡し、管理サーバーがもっているKeyinfo要素とSignedProtperties要素とあわせた3要素を、管理サーバーのセカンドHPKI証明書の秘密鍵で署名したSignatureValueをもつPrescriptionSign要素を返却__してきて、ローカルでRemoteSignatueClientService.exeが処理したPrescriptionDocument要素と合体しているのだろう。
  
 === HPKIセカンド電子証明書管理サービスクライアント証明書の扱い === === HPKIセカンド電子証明書管理サービスクライアント証明書の扱い ===
idトークン獲得の流れ.1739749465.txt.gz · 最終更新: 2025/02/17 08:44 by admin