2024年3月19日火曜日

Entra IDの新しい条件付きアクセスを試す(デバイスコードフロー編)

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

そういえばEntra IDの条件付きアクセスに新しい条件が追加されましたね。
今回追加されたのは認証フローという条件で、
  • デバイスコードフロー
  • 認証の転送
の2つの条件をサポートしています。


関連するドキュメントはこちらにあります。

デバイスコードフローはともかく「認証の転送」とは??という疑問はもっともですが、簡単にいうとPCブラウザ等でログインを求められる際にQRコードなどでモバイルデバイスを呼び出してモバイルデバイス側で認証する、という構成を想定した条件です。(Outlookとかであるはず)

当該する条件に合致するときにブロックしたり多要素認証を要求したりすることができるのがこの条件付きアクセスという機能なので、きっとそのようなシナリオがどこかであったんだと思います。(ちなみにこの機能を使うにはAzure Active Directory Premium P1が必要です)

ということでポリシーを作ってみます。
今回はデバイスコードフローをブロックするシナリオで試してみましょう。
条件としては、
  • 全てのユーザが
  • デバイスコードフロー用のテストアプリにアクセスしようとした場合
  • 認証フローが「デバイスコードフロー」だったら
  • アクセスをブロックする
というポリシーを作ってみました。
(上記のスクリーンショットのもの)

ということでアクセスしてみます。
デバイスコードフローなので
https://login.microsoftonline.com/{テナントID}/oauth2/v2.0/devicecode
に対してclient_idとscopeをx-www-form-urlencodedでPOSTしてあげるだけですね。

こんな感じでPostmanでリクエストをしてみます。

あとはレスポンスの中にあるverification_uriにアクセスしてuser_codeを入れてあげれば認証完了です。(通常はこのレスポンスをQRコードにして表示してスマホで読み込んだりさせます)
今回はそのままverification_uriを開いてみます。

そしてuser_codeを入れるとログインが求められます。

今回はデバイスコードフローをブロックするのでポリシーが正常に動いていればアクセスがブロックされます。



条件付きアクセスは色々と新しい条件がついていてかなりきめ細かいアクセス制御ができるようになってきています。
アプリケーションの利用シーン(環境など)をベースにいろいろなポリシーを構成してみてください。





2024年3月18日月曜日

外部IdP利用時にRP側"でも"多要素認証を行うべきか

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

今回は多要素認証の話です。
ソーシャルIDなどの外部IdPと連携をする際、外部IdP側がパスキーに対応している場合もあり、基本的にRP側はIdPの認証結果を信じて何もしないという文字通り「Relying」な感じで構成されることが多いと思います。

しかしながら、本当にそれでいいの?とうケースも存在すると思うので、少し深掘りしてみましょう。
中々難しい話だと思いますが、IdP側(例えばGoogle)で認証を強化するか、RP側(例えばECサイト)で認証を強化するか、もしくは両方か、についてユーザ体験の妥当性を含めて考えていかないといけないところです。
IdPもRPもそれぞれ責任範囲が異なるので基本的に自分の責任範囲を守る目的で多要素認証を要求していますが、ユーザから見るとなぜ別々に、、という形に見えてしまうことも事実です。

この問題を根本的なところは先に書いた通り責任範囲の話を理解する必要があるのですが、ツール(技術面)とルール(契約を含め責任論)を合わせてみていかないといけません。この辺りをトラストフレームワークと言われるもので表現をしていくことになります。

まずは技術的な話

まずは簡単な話として、技術の話をしていきましょう。(本来はルールの話をした上で技術の話をするのが良いのですが、読者層を考えるとまずは目に見えるところから入るのが良いと思っています)

本来はIdPがacrやamrで認証手段(例えばパスキーで認証したよ)という情報を渡してあげればRP側はその結果を見て追加でパスキーを要求するべきかどうかの判断をしていくのが良いと思います。ただRPを作ったことがある方はわかると思いますが、
  • IdPによって返すacr/amrが異なる
  • IdPによっては返ってこないこともある
などの事情があるので、特に複数のIdPとのID連携を行う場合は中々面倒臭いことになります。

例えば、GoogleのOpenID Connectのサポート状況を見るとドキュメントを見る限りacr/amrに関する記載はありません。


Entra IDは一応amrの値を返しますが"pwd", "mfa"の2種類しか返せないのでパスキーで認証されても、OTPで認証されても"mfa"になると思います。

Oktaの例は56さんが試してくれていますがEntraよりは少しマシな程度っぽいですね。

ということで外部IdPの認証手段までを厳密かつ標準的に取得して利用するのは現時点では結構ハードルが高そうです。
この辺りは学術認証フェデレーションでは議論が進んでいるのですが、ある程度閉じたコミュニティの中だからできる議論でもあるので、パブリックなIdPだと難しいと思います。


そもそも論として、なぜ外部IdPと連携するのか?

また、そもそも論として各IdPをどこまで信じるのか?というか何のために外部IdPを使うのか?というところに遡ってしまいます。
単に、利便性(プロフィール入力の手間の削減、パスワード登録をさせない)を提供することでドロップ率を下げましょう、という場合もありますし、本気で外部IdPの認証結果に依拠しましょう、という場合もあります。

登録時にプロフィール入力を自動化してドロップ率を下げましょう、という話だけなら認証まで外部に依存する必要は本来ないと思います。パスワード登録をRP側でさせることでドロップ率が〜〜〜という話であればパスキーを使うなりなんなりしてパスワードに依存しない認証手段を用意すれば良いと思います。
(認証まで外部IdPに依存することでログインの都度外部IdPにリダイレクトされるとなると外部IdPが落ちていた場合に発生する機会損失などのリスクもありますし)

認証手段をRPが自前で持つことがリスクという考え方をする方もいるのは事実なので、その場合は外部IdPに頼ってしまうこととのリスクとの天秤で考えるしかないと思います。
(外部IdP側でアカウント侵害が起きたらどうするの?とか)


というあたりで外部IdPとの責任問題の話になってきたところで今回は終わりです。
ある程度答えは見えていると思いますが、次回以降で主要なIdPがどこまで責任を取ってくれるつもりなのか?について少しずつ調べてメモしていこうと思います。

2024年3月17日日曜日

Auth0の管理画面へのログインにパスキーを使うと少しハマる件

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

そういえばAuth0(Okta CIC)の管理画面へのログインにパスキーなどが使えるので使ってみたいと思います。

ちなみにちょっとだけ癖があります。簡単に書くと、

  • パスキー追加をメニューから実施する場合はplatform認証器は選べない
  • USBキーやOTPなど多要素認証を追加し利用すると「このデバイスでのログインの高速化」を目的としてplatform認証器の登録を促される
  • リカバリはリカバリーコードを利用する
  • どうやらパスキーとしてはUSBなど外部キーを前提に設計されている
  • デバイス登録を目的にplatform認証器登録も使えるが同期される前提はなさそう

という感じです。最初からplatform認証器が登録できればいいのに。ちょっと実装が古いのかな。


さて、始める前に基本的な話を。IDaaSを使ってID基盤を構築するときに忘れてはいけないのはIDaaS自体の認証強化とアクセス制限です。

最低限やっておくべきことは、
  • 管理者アカウントの分離(共有ユーザの排除)
  • 管理権限の適正化
  • 認証強化(多要素認証)
  • ※API実行ユーザも忘れずに!
くらいでしょうか。
特にヘルプデスクやオペレータのアカウントも作る必要もあると思うので適切に権限分離は重要だと思います。
また、日本企業に多いと思いますが、上記に加えてアクセス元の環境の制限(IP制限など)も行いたい、という話も出てくることもあります。(これは働き方改革なのか、ネットワークペリメーター神話がまだまだ生きているだけなのかはケースバイケースです)

ということでAuth0でも管理画面へのログイン時の認証を強化できますのでやっておきましょう。
ちなみに、ご存知の通りAuth0の管理画面へログインするためにはローカルログインに加えてLinkedInやMicrosoft Account、Githubアカウント、Googleアカウントが使えます。
当然、それらのIDシステムもパスキーに対応していたりと認証強化を行うことは可能ですが、今回のテーマはAuth0側でさらに認証強化をする、という話です。

IdP側の認証強化の結果をこのケースおけるRPとなるAuth0の管理画面はどこまで信じることができるのか?と言う話とUI/UXの関係については別途書こうと思いますが、ざっくり言うと外部IdP(ここで言うとGoogleなど)は認証結果に対する責任は取ってくれない、かつどのような認証手段で認証したのかは教えてくれないので、重要な顧客IDを預かるIDaaSは自前でも多要素認証を実装しておくことが重要です。

ログインしてプロファイルページを開くと認証手段の追加ができます。
ちなみに設定が行われいていないテナントでは順次ログイン時に強制的に多要素認証設定を行うように促されるため最近のテナントを持っている方は設定済みかもしれません。

ということで追加してみます。WebAuthn with FIDO Security Keysをクリックしてみましょう。(なお、ポップアップがブロックされているとエラーになりますので、許可してください)

登録画面が出てきますね。初めに書いた通りplatform認証器ではなくUSBセキュリティキーが前提となっています。
登録が終わるとリカバリーコードが発行されるのでコピーしておきます。ちなみにダッシュボードからリカバリーコードは再生成できますので、こちらのスクリーンショットのコードはすでに無効です。

これで登録が完了しました。

一旦ログアウトしてログインし直してみます。USBキーが求められます。

すると、「このデバイスでのログインを高速化」と言われます。

そしてTouch IDが求められます。

USBキーとデバイスの両方が登録された状態になります。

USBキーを使う場面は少なくともSyncされたデバイスでは出番はなさそうです。
どうもplatform認証器はあくまでデバイス登録を目的としたものとして整理されているようですね。

しかし、iCloudで同期されているのかと思いつつiPhoneでダッシュボードにログインしてみるとplatform認証器は使えません。
USBキーが求められるので、仕方なく先ほど登録したUSBキーを使ってログインします。(先ほどYubikey NFCを使ったのでNFCで読み込ませました)

するときました。先ほどMacで登録したのと同じようにログインの高速化。
FaceIDを使ってデバイス登録を求められます。

しかし、すでにデバイス登録をMacでしているのでエラーが出ます。。。


iCloudで同期されているので登録済みって言われてます。

やはりパスキーが同期されている想定はなく、あくまでplatform認証器はデバイス登録に特化して利用、あくまで認証は外部キーを使うという整理になっていそうですね。






2024年3月16日土曜日

Identiverse 2024のアジェンダが公開されています

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

先日はEIC(European Identity & Cloud Conference)のアジェンダが発表された件を書きましたが、今回はEICの前の週にラスベガスで開催されるIdentiverseの件です。
今回は2週連続でイベントなのでラスベガス経由のベルリンの長丁場になりそうです。(そういえば前回のIdentiverseでMicrosoftのAnkur Patelが今で言うEntra Verified IDの発表をしたんだったなぁ、、と遠い目。セッションの後で彼を捕まえてPreviewプログラムに参加させてもらったところからVC人生?が始まっている気がします)

まずはIdentiverseとは?からです。
こちらのポストでも書きましたが、世界四大アイデンティティイベント(4は適当)の一つで、もともとPing IdentityのAndreが始めた旧Cloud Identity Summitと言われていたカンファレンスですね。ラスベガス開催になってからは参加できていませんでしたが、今年は参加しようと思います。

そして、いよいよセッション一覧が公開されました。

セッション数も多いので、気になったものを。

Data Sharing Using Verifiable Credentials in the Agricultural Sector

初日から気になるセッションです。農業とVCをどう繋げたのか是非聴いてみたいセッションですね。

Global Trends & 2024 Strategy: OpenID Foundation Board Insights

OIDFのボードの方々による2024年のグローバルトレンドの話です。これは必聴です。


Enabling a Trusted Ecosystem for the US Pharmacy Supply Chain

薬局かどうかは置いておいてサプライチェーンにおけるトラストの話題は日本でも大切な話なので、こちらは是非聴いてみたいネタです。


Untangling the Tangled Web of Digital Identity Online Presentation

オンラインでのデジタルIDの提示に関する課題をmDLやVC、Walletなどを中心に議論するパネルです。標準化の中心人物が集まって議論するのを生で見ることができるのもこのようなグローバルイベントの醍醐味です。


Digital Identity, the G20, and the SIDI Hub Survey

ちょっとチョイスするセッションのGail率が高い気がしてきましたが、SIDI Hubです。G20に向けて着々と進んでいますね。



Lessons Learned: Nationwide eID Recovery With Remote Identity Proofing

ノルウェイのBankIDの方によるeIDのリカバリーをリモートIdentity Proofingでやった事例の話ですね。日本でもマイナンバーカードのスマホ搭載など国民IDのデジタル化が進むとリカバリの問題はついて回るので先行事例を勉強しておくのは大切だと思います。



Counselors in the Modern Era: Advancing Identity Management

イアンのセッションなので、無条件で参加です。


Securing the Foundations of Verifiable Credential Ecosystems

先日紹介したOID4VCxのFormal Security AnalysisをやっていたDanielのセッションです。今後社会実装をしていく上では必須になると思います。






その他もたくさん面白そうなセッションがありますが、全体感としてEICに比べてCIAMやパスキーのセッションがバランスよく配置されているな〜という感想です。先端事例も良いですが今目の前にあるビジネスもバランスよく、という感じなんでしょうね。




2024年3月15日金曜日

SIDI Hubの2024の戦略が発表されました

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

先日のOpenID Summit Tokyoやその前日に開催されたOpenID Foundation Hybrid WorkshopでOIDF Executive DirectoryのGail Hodgesのキーノートで触れられたSIDI Hub(Sustainable & Interoperable Digital Identity Hub)の今後のプランと今年のアクションアイテムが公開され、2024/3/31までフィードバックを募集しています。


SIDI HubのWebページのトップからダウンロードできるようになっています。


ちょっと中身をみていきましょう。

SIDI Hubが解決を目指す課題とは?


SIDI Hubの名前の通り、デジタルアイデンティティって全然相互運用できないよね、ということを最大の課題として設定しています。

以下、Deeplでの機械翻訳です。

人と企業は国境を越える。将来、人々は、通貨交換を期待するのと同様に、国境を越えて日常生活でデジタル・ アイデンティティを使用したいと思うようになるだろう。残念ながら、多くの問題が国境を越えた相互運用性の障害となっている:

  • 数十のデジタル・アイデンティティ・エコシステムがその管轄区域内でサイロ化されている。
  • OECD のデジタル ID 勧告には、国境を越えた利用を可能にすることが盛り込まれているが、 38 カ国の加盟国がどのように実現できるかについての技術的または政策的なロードマップはない。
  • どの国、地域、標準化団体、非営利団体、民間団体、多国間に も国境を越えた相互運用性を実現する権限がない。
  • 単一の標準が「すべてを支配」する可能性は低いため、技術スタック間のデジタル ID 相互運用性は技術的には可能であるが、達成および維持は非常に困難である。 
  • 悪質な行為者が脆弱なインフラ(AIディープフェイク、サイバー犯罪、COVID-19)を利用するため、不作為による機会費用が発生し、人々やビジネスは高いレベルの摩擦に直面する。
  • ポリシーを解釈し、製品や実装で簡単に実施する仕組みがなければ、ビジネス・コンプライアンス・コストは増大し続ける。
  • デジタル・アイデンティティが果たすであろう重大な役割を理解している人は、アイデンティティ・コミュニティ以外にはほとんどいないため、明確で透明性の高いコミュニケーションが重要である(誤った情報を避けることも同様)。

ということでSIDI Hubの目的は?

クロスボーダーで使えるデジタルアイデンティティを実現するために必要なものを定義しましょう、ということです。

なぜSIDI Hubがこんなことをやるの?


なぜなら、SIDI Hubは、

(1) デジタル ID インフラ、標準、および政策に責任を持つ (2) SIDI ハブに価値を見出す、グローバルなエコシステム全体 からの利害関係者のコミュニティ 

ワークストリームおよびワークショップにおける SIDI ハブの参加者は、共有されたロードマップ、 解決すべきギャップ、および改善策を含む、国境を越えた相互運用性の「良い姿」を具体 化するのに役立つ。

我々は、この課題に対する共通のコミットメント、国内主権と国内法および国際法の尊重、参加組織の活動の尊重、そして共通の文化(コンセンサス、包括的、透明性、健全な議論など)を持っている。 

SIDIの協力は、組織がその使命に照らしてインパクトをもたらすための「泳ぐ車線」を明確にする助けにもなる。

であり、逆にいうと、
法人
統治機関 
標準化団体
オープンソースコードプロバイダ
市民権団体
NGO 
多国間組織
コンサルティング団体
ベンダー

ではなく、 

SIDI Hubは、政府やその他のエコシステム参加者が何をしなければならないかを指示することはできません。
ということです。

他国間連携をする際のアプローチは非常に難しいですね。どうしても政治色や経済安全保障などの視点が入ってきてしまうので、国際標準化機関でやってしまうと国力が小さい国々の意見などが反映されにくくなったりする、というのも背景なのかもしれません。(かといってこのアプローチが成功するとも限りませんが)

何をして、何をしないのか?

やること:
  • ギャップ分析
  • SIDI Hunの目的に向かって推進するための活動
    • チャンピオンユースケースの選定
    • 標準化団体へのアプローチ
      • 各団体が策定している標準への働きかけ
    • デプロイメント
      • オープンな相互運用性試験の実施の働きかけ
      • 条件を満たすオープンソースにフォーカスを当てる
    • ポリシー
      • トラストフレームワーク間のマッピングを行う
    • オペレーション
      • 会合の開催
      • フィードバックの反映
      • 他の動きとの整合性をとる

やらないこと:

  • 以下のような口出しはしない、ということです
    • 政府に対してどのような法律を策定しなければならないか
    • 非営利団体がどのような決定を下さなければならないか
    • 標準化団体がどのように仕様を変更しなければならないか

誰が参加するの?

色々な方達が関わっていますね。
  • 国連やワールドバンクのような多国間組織
  • EUや個々の国々の政府機関
  • 非営利団体
  • 標準化団体
  • 学術機関
そしてそれを下支えするための企業や市民団体、メディア、エキスパートたちももちろん参加者となります。
実際昨年の11月にパリで開催されたイベントにはOpenID Foundationはもちろん、日本政府からも参加しています。他にもおなじみの団体がありますね。

結局何をやるの?

先に触れたパリの会合の参加者からSIDI Hubを実現するためには何をすべきなのか?を募ったところ、以下に集約されたとのこと。

  • チャンピオンユースケースを定義する
  • デジタルアイデンティティの最低限の要求事項をまとめる
  • トラストフレームワークのマッピングを行う
  • 成功の指標を定義する
  • SIDIのガバナンスを定義する
どれも重要ですね。
想像するに、例えばトラストフレームワークのマッピングができると、日本における犯罪収益移転防止法の元で運営されている事業者で本人確認されたデジタルアイデンティティは国外でも確認済みとして通用するかどうか?という視点は非常に大事だと思います。逆にここでちゃんとマッピングをしておかないと他国において日本の本人確認は役に立たない、といった事態になってしまうのかもしれません。

ということで、先ほど触れた様々な参加組織から上記のトピックスに対応するためのワーキンググループを組成しましょう、という提案がなされています。


みたような人たちがCo-Chairとして手を挙げています。


今後どのような活動をするの?

各個別の活動は置いておいて、全体としてのロードマップが示されています。

一番大きいのは次のリオデジャネイロでのG20に向けたインプットをどう作っていくか、というところでしょうね。


色々とイベントの企画も進みつつあります。
Q4(10月)には東京かシンガポールでもイベントの開催が計画されています。
楽しみですね!


こういう国際連携モノは時間もかかるしコンセンサスを取ることも難しいと思います。さらにいうと最終的に各国が社会実装するかどうかが肝になると思いますが、そのあたりはSIDI Hubでは口出しをしない体裁になっているあたりも不安要素ではあります。
とはいえ、ちゃんと解かないといけない課題ではあるので日本からもこのような取り組みにちゃんと向き合うようにできると良いのではないでしょうか?


2024年3月14日木曜日

OpenID for Verifiable Credential IssuanceのImplementer's Draftの投票が開始されています

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

先日ポストした、OpenID for Verifiable Credential IssuanceのImplementer's Draftの投票が始まっています。

Notice of Vote for Proposed Implementer’s Draft of OpenID for Verifiable Credential Issuance

https://openid.net/notice-of-vote-for-proposed-implementers-draft-of-openid-for-verifiable-credential-issuance/


個人でもOpenID Foundationのメンバになれますので(50ドルかかりますが)、ぜひ登録して投票してください。

2024年3月13日水曜日

OpenID Foundatioon Hybrid Workshop@Googleオフィス(マウンテンビュー)

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

次回のIIW(Internet Identity Workshop)の前日(4月15日)に開催されるOpenID Foundation Hybrid Workshopのレジストレーションが始まっているので忘れずに登録しましょう。(2月後半にレジストサイトがオープンしたので速攻申し込みました)

先日日本でもOpenID Summitの前日に開催されたワークショップですね。
その時の様子はこちらです。

今回はマウンテンビューにあるGoogleのオフィスで開催されます。

こちらは2022年の4月に同じくIIWの前にOIDF WorkshopがGoogleで開催された際の写真です。このチャリ欲しいなぁ。。と思った記憶があります。

今回は私も現地参加の予定なので様子をリポートしたいと思います。