2024年3月28日木曜日

Microsoft Identity Manager向けコミュニティ製のPowerShell MAが更新されています

こんにちは、富士榮です。

このブログを始めたことはMicrosoft Identity Manager(その頃はIdentity Lifecycle Managerでした。その後、Forefront Identity Manager〜Microsoft Identity Managerにリブランドされました。今でいうEntra ID Connectのベースになっているモジュールです)に関する記事をたくさん書いていたのですが、最近はめっきり触ることもなくなってきていました。

ただ、当時このプロダクトのMicrosoft MVPだったこともあり、当時の開発コミュニティの方々とはそれなりに繋がりが残っていたりします。今回のPowerShell MA(Management Agent)も当時のMVP仲間のSoren Granfeldtの作です。


今でこそ公式にPowerShell MAがありますが、当時は存在しておらず、イベント単位で自由にPowerShellのモジュールを呼び出せる彼のツールは衝撃的でした。なにしろそれまではC#で全部ロジックを書かなければならなかったので。。。

なお、ノンサポートですが工夫をすればEntra ID Connectにもこのモジュールは適用できるはずです(何年か前はできていた。最近は不明)。ロジックの自由度が格段に増すので魔改造派の方は試してみてください。

2024年3月27日水曜日

TBDのVerifiable Credentialsの説明資料が面白い

こんにちは、富士榮です。

みなさん、TBDってご存知ですか?

https://www.tbd.website/

Twitterの共同創業者のジャック・ドーシーが創設したBlockの暗号資産部門からスタートしたプロジェクトでweb5(web2+3でweb5とのこと)を提唱しているチームです。

https://www.itmedia.co.jp/news/articles/2206/13/news071.html


DIDやVCをやっている人たちが一時期集まったチームでもあり、先日周南公立大学のデジタル学生証プロジェクトでも採用されたプラットフォームを提供していることでも話題になりました。

https://www.shunan-u.ac.jp/news/information/20240228-13942/

 

今日は、web5の細かい話をするわけではなく、このチームが書いている初学者向けのVerifiable Credentialsの解説記事が結構面白かったので紹介します。

https://dev.to/tbdevs/the-illustrated-beginners-guide-to-cryptographic-identity-verification-51f0

※実は、web5のイントロなどもしているシリーズ(全3回)の第2回なので、興味があれば第1回から読んでみると良いと思います。(改めて紹介するかもしれませんが、某X社がネタにされていて面白いです)


ではみていきます。最初からアメリカンな感じです。




第1回を読むとわかるのですが、主人公は某SNSの名称変更に伴い自分のユーザ名を奪われてしまったことからプライバシーとデータのポータビリティについて制御ができることの重要性に気がついてしまいます。

アプリの名前を変えるからあなたのユーザ名を変えるよ!との非情な通知

ポップコーンを食べながら彼氏に愚痴る主人公


そして彼らは旅行に行くわけですが、この辺りからVCが出てきます。


そして、なぜか身分証の話題になりますが、彼はスマホに入ってるから大丈夫!と宣言します。

携帯電話にWalletが入っているから大丈夫!TSAにこれを見せると通過できるよ!


でも、彼女は「ふーん」と塩対応です。

彼女は物理パスポートを使うので長蛇の列へ並びます。


でも主人公以外の3人(彼氏+友人カップル)はそんな彼女を置いてデジタル身分証明書が使えるレーンでスイスイと通過します。付き添ってあげるなり待ってあげるなりすればいいのに・・・



でも主人公も馬鹿ではないので、CLEARレーンに並んで少しでも早く追いつけるようにしようとします。

しかしそこでも事件が起きます。

「奥様、あなたはランダムな本人確認の対象に選ばれました。」

と言われてしまうのです。

そして彼女がパスポートを係員に渡すと、「ああ、私たちは誕生日が同じなんですね!」とか「出身地は美しい島ですよね〜」とか言われてしまいます。(こんな係員いるのかな?)


そして彼女はVCについて飛行機の中で調べ始めます。



調べた結果VCは「過剰な個人データを明らかにせずに、法定飲酒年齢に達していることを証明する必要があるとします。完全な ID を提示する代わりに、ベンダーに VC を提示することもできます。販売者は資格情報を年齢証明として認識し、引き換えにアルコールを提供します。」などのユースケースが出てくるわけです。


とここでこの記事は終わるわけですが、こんなシチュエーションある?と思いつつもデジタル身分証明書としての使い方、選択的開示によるプロイバシー保護についてなど簡易に説明してくれていて面白かったです。

日本でもこういうシナリオで解説書を書くともうちょっと広がるのかもしれませんね。




2024年3月26日火曜日

OAuth2.0 Security Best Current Practiceを読んでみる(8)

こんにちは、富士榮です。

ようやくこのシリーズも終わりです。

引き続き攻撃パターンと緩和策です。最後の3つを読んでいきます。


攻撃パターンと緩和策

  • クリックジャック
    • 認可エンドポイントにアクセスした時に表示する画面に透明なiFrameを仕込むなどのクリックジャックの話です
    • 認可エンドポイントはMUSTとしてクリックジャック対策をしなければなりません
    • W3CのContent Security Policy Level2以上を適用すべきです
    • こんな風にする感じですね
    • HTTP/1.1 200 OK
    • Content-Security-Policy: frame-ancestors https://ext.example.org:8000
    • Content-Security-Policy: script-src 'self'
    • X-Frame-Options: ALLOW-FROM https://ext.example.org:8000
  • 認可サーバがフィッシングサイトにリダイレクトする
    • 前も出てきたかもしれませんが、正しくredirect_uriが設定されていたとしても攻撃者によってフィッシングサイトに誘導されてしまう可能性はあります。
    • 例えば、無効なスコープの値を指定することでフィッシングサイトへ誘導するケースや、有効出会っても攻撃者によってコントロールされたclient_id、redirect_uriを使った誘導(同意拒否をしても誘導される。他にもprompt=noneで誘導する)ケースがあげられています
    • 認可サーバでこれらを防ぐためにはprompt=noneのケースをのぞき、必要に応じてユーザ認証を行う必要があります
    • また、リスクに応じて追加のアクションを講じるのも一つの手段です
    • 基本的にredirect_uriが信頼できない状況ではリダイレクトするべきではありませんが、信頼できない場合にユーザがリダイレクトするかしないかの判断をするような実装を行なっても良い(MAY)ということです
  • ブラウザ内の通信フローに対する攻撃
    • 認証応答がリダイレクトではなくpostMessageなどで送信されるケースにおいて悪意のある通信先に対して通信が行われるケースがあります
    • 例えば、送信先の制限が不十分な実装をするケースなどが挙げられています。ワイルドカードで送信先が設定されていますね
    • window.opener.postMessage(
    •   {
    •     code: "ABC",
    •     state: "123"
    •   },
    •   "*" // any website in the opener window can receive the message
    • )
    • 他にも送信先のURIの検証が不十分で攻撃者の設定した値になってしまったり、送信元の検証が不十分なケースも想定されるのでURI検証やCSRF対策はしっかりとしておく必要があります
    • その意味で推奨される実装としては、
      • 明確なクライアントオリジンを示す
      • window.opener.postMessage(
      •   {
      •     code: "ABC",
      •     state: "123"
      •   },
      •   "https://client.example" // use explicit client origin
      • )
      • メッセージのバリデーションを行う
      • window.addEventListener("message", (e) => {
      •   // validate exact authorization server origin
      •   if (e.origin === "https://honest.as.example") {
      •     // process e.data.code and e.data.state
      •   }
      • })
    • といった実装が必要となります

ということで、ようやくこれで最後まで読みました。
実装する暇がなかなか取れませんが、徐々にやっていきたいと思います。

2024年3月25日月曜日

送金ユースケースでのVerifiable Credentialの利用

こんにちは、富士榮です。

単体のVerifiable Credentialsって基本的に単なる検証可能なデータ構造でしかないので、どうやって使うのか?言い換えると検証可能性があることは世界をどう変えていくのか?ということについて色々な人たちががんが得ているわけです。
最近目にして面白いなぁ、と思ったのがDSGV(ドイツ貯蓄銀行協会)の人がドラフトを書いている送金に関するプロファイルです。
Payment Presentation Profile - draft 0

どんなものなのかAbstractを見てみましょう。

The Payment Presentation Profile defines a set of requirements against existing specifications to enable the interoperable presentation of payment data between a payment initiator, wallets and a bank.

This document is not a specification, but a profile. It outlines existing specifications required for implementations to interoperate among each other. It also clarifies mandatory to implement features for the optionalities mentioned in the referenced specifications.

The profile uses OpenID for Verifiable Presentations as the base protocol for the request and verification of W3C JWT VCs as W3C Verifiable Presentations. A full list of the open standards used in this profile can be found in Overview of the Open Standards Requirements.

ペイメント・プレゼンテーション・プロファイルは、ペイメント・イニシエータ、ウォレット、銀行間でペイメント・データの相互運用可能なプレゼンテーションを可能にするために、既存の仕様に対する一連の要件を定義するものである。

この文書は仕様ではなくプロファイルである。実装同士が相互運用するために必要な既存の仕様の概要を示している。また、参照されている仕様で言及されているオプショナリティのために実装が必須である機能も明確にしている。

このプロファイルは,W3C JWT VCをW3C Verifiable Presentationsとして要求及び検証するための基本プロトコルとして,OpenID for Verifiable Presentations を使用する。このプロファイルで使用されるオープンスタンダードの完全なリストは,Overview of the Open Standards Requirementsで見ることができる。

(Deeplで機械翻訳)


デビットカードみたいな感じですね。

支払い要求があったらWalletが銀行の口座に送金指示をかける、みたいな仕組みっぽいです。


支払い先からWalletへ支払いクレデンシャルの発行を依頼するところがOpenID for Verifiable Presentationsなんですね。ユーザは要求に従いクレデンシャルを銀行に対して提示、銀行がVPとVCの検証をして問題なければ実際に支払いが実行される、という仕組みっぽいです。

なんだか車輪の再発明っぽくもありますし、口座間送金のためのネットワークは結局いるんじゃない?と思いますが、送金の意思確認という意味ではまぁ、、という感じです。

いずれにしても色々と考える人たちがいるのは面白いですね。




2024年3月24日日曜日

Entra IDの条件付きアクセス+パスキー(特定のベンダのキーのみを許可する)

こんにちは、富士榮です。

先日、Entra IDの条件付きアクセスでパスキーの利用を強制する方法を書きました。

https://idmlab.eidentity.jp/2024/03/entra-id_20.html


今回はさらに一歩進めて、特定のベンダの認証器だけを使えるようにしてみたいと思います。

やるべきこととしては認証方法の登録時に認証器のAAGUID(Authenticator Attestation Global Unique Identifier)を合わせて登録することです。このことにより特定の認証器以外は受け付けないように設定を行うことができます。

ちなみにこのAAGUIDですが、えーじさんがBlogに書いていた通り、ボランティアベースでリストが作成されgithubで公開されています。

手動で確認する場合は、このレポジトリのREADMEに書かれているPasskeys Authenticator AAGUID Explorerを使うのが便利だと思います。このリストに記載されているものに加えてFIDOアライアンスのMeta Data Service(MDS)に登録されているものもあるので、両方合わせて表示するにはExplorerの左上にある「Include MDS Authenticators」をクリックすると世の中の認証器はほぼほぼ網羅できると思います。

例えば手元にあったeWBM eFA310 FIDO2 AuthenticatorのAAGUIDは95442b2e-f15e-4def-b270-efb106facb4eということがわかります。


なお、Entra IDに登録済みのセキュリティキーであればアカウントのセキュリティ情報のページからAAGUIDを確認することもできます。


ということで認証方法の絞り込みをしていきましょう。先日のポストの中で認証方法の設定でパスキーのみを設定する方法を記載しましたが、その中で詳細オプションがあることを書きました。この詳細オプションを開くとAAGUIDの許可リストを記載することができるので、許可したい認証器のAAGUIDを先ほどのExplorerやセキュリティ情報のページから取得して登録してあげればOkです。

これで完了です。

未登録のAAGUIDの認証器を使ってログインしようとすると条件付きアクセスポリシーが働き、認証には成功するもののアクセス制限がかかりました。

ということで、認証器の強度評価をして許可リストを作って運用するような環境においてはこの設定を使うことで例えばYubikeyのこのモデルはOKだけど、eWBMのキーはダメ、などの制御を行うことができるようになります。

環境統制レベルが低いパブリックに近い環境で組織内のアプリを使わせたいケースなどにおいてはこのような制御が有効なケースもあると思うので活用してみると良いと思います。

2024年3月23日土曜日

OAuth2.0 Security Best Current Practiceを読んでみる(7)

こんにちは、富士榮です。

すこし空きましたがこちらも続けていきます。

引き続き攻撃パターンと緩和策です。前回は307リダイレクトまで行きましたので続き13個目/18個のTLSを終端するリバースプロキシから行きたいと思います。


攻撃パターンと緩和策

  • TLSを終端するリバースプロキシ
    • 一般的なWebサーバの構成だとリバースプロキシ(と言うよりもロードバランサーでやることが多いかと)でTLSの終端処理をした上で実際のWebサーバへリクエストをディスパッチすることが多いと思います
    • その際にhttpヘッダーにIPアドレスや証明書とのバインディングの情報などさまざまな情報を付与することがありますが、不正にヘッダを改竄することが攻撃につながる可能性があります(典型的にはX-Forwarded-Forなど)
    • と言うことでちゃんとhttpヘッダのサニタイズをしましょう(MUST)ということです
    • また、リバースプロキシと実際のWebサーバの間のネットワークに攻撃者がアクセスできてしまった場合を仮定して内部ネットワークにおいてもアクセス制御をちゃんとしましょう
  • リフレッシュトークンの保護
    • リフレッシュトークンを使うとアクセストークンが発行できるので、攻撃者にとってはリフレッシュトークンは確かに魅力的な攻撃対象です
    • RFC6749でも転送中や保存中の保護やクライアント認証の実施などの対策を示していますが、ここでは更に高度な保護の方法について考えます
    • クライアントのリスク評価を行った上でリフレッシュトークンの発行の可否を判断する必要があります(MUST)。リフレッシュトークンを発行しない場合は認可コードフローなどでアクセストークンを発行するように構成することができます
    • リフレッシュトークンを発行する際はユーザの同意に基づき、特定のスコープ・リソースサーバへ紐付けられる必要があります(MUST)
    • コンフィデンシャルクライアントの場合はクライアント認証を必須としていますが、パブリッククライアントの場合はmTLS(RFC8705)やDPoP(RFC9449)を使ってリフレッシュトークンとクライアントのインスタンスを紐づける必要があります
    • ローテーションを行って無効にされたリフレッシュトークンも認可サーバは保持しておき、万一不正なクライアントが古いリフレッシュトークンを使おうと試みた場合は古いリフレッシュトークンだけでなく、アクティブなリフレッシュトークンについても無効化するなど予防措置を講じることもできます
    • リフレッシュトークンに紐づくスコープの情報をトークンに埋め込むことで認可サーバは取消対象となるリフレッシュトークンの判別をしやすくなる可能性もあります
    • その場合はデジタル署名を施すなどトークン自体の改竄を防ぐメカニズムも導入する必要があります(MUST)
    • また、パスワード変更やログアウトなどのイベントをトリガーにリフレッシュトークンを無効化することも検討しても良いと思います
    • 通常リフレッシュトークンには有効期限をつけますが、一律で設定しても良いですし、リスクレベルに応じて変更するなどの工夫をしても良いと思います
  • リソースオーナーになりすましたクライアント
    • 認可サーバがclient_credentialsフローをサポートする場合、アクセストークンの発行対象がユーザなのかクライアントなのかを判別することが難しくなるケースがあります
    • 具体的にはクライアント登録を行う際にクライアントIDを任意に決定できる場合、ユーザの識別子(sub)と同じ値をクライアントIDとして登録することで、リソースサーバが当該のアクセストークンがユーザに対して発行されたのかクライアントに対して発行されたのかを混同してしまい、望まぬクライアントがユーザのリソースにアクセスできてしまう可能性があります
    • このことを避けるためにはユーザの識別子とクライアントIDの名前空間を分離して識別可能にしたり、他のプロパティを使ってトークンの発行対象がユーザなのかクライアントなのかを判別できるようにしないといけません

ということで今回はここまでです。
しかし読めば読むほど本当にそんな実装してる認可サーバあるの??って思いますが、こういう形でちゃんと文章として出すことが大切なんだろうなぁ、、と思っています。

2024年3月22日金曜日

IETF 119で発表されたJOSE、COSE、OAuth関連のスペック

こんにちは、富士榮です。

IETF 119がブリスベンで本日まで開催されています。

実は私はIETFは参加したことがない(昨年の横浜も忙しくて行けなかった・・・)のですが、参加している人たちから色々と情報が流れてきています。

Mike Jonesさんが以下のポストをしています。

Eight Specifications Published in Preparation for IETF 119

https://self-issued.info/?p=2503

ポストによると主にMikeが絡んでいるスペック中心ではありますが、以下のスペックに関するUpdateがあったとのことです。

実装を追いかけている人は必読ですね。