Quantcast
Channel: IdM実験室
Viewing all 769 articles
Browse latest View live

SIDI Hubの活動が本格的に開始されています

$
0
0

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

これまでも何度か本ブログで取り上げてきたSIDI Hubですが、いよいよ活動が本格的に開始されています。


おさらいですが、現在、SIDI Hubのワークストリームは以下の通り定義されています。

1. Champion Use Cases for cross-border interoperability, develop a process for selecting and fleshing out 1-3 cross-border use cases.

2. Minimum Requirements for Digital Identity Interoperability for Champion Use Cases.

3. Trust Framework Mapping for Champion Use Cases, by analysing and amplifying existing trust mapping efforts, identifying gaps (including duplication), and aligning on mitigation tactics.

4. Metrics of success Define what SIDI Hub metrics of success are, and monitoring delivery.

5. SIDI Hub Governance, such as SIDI Hub internal processes & grant management, SIDI decision tracking, SIDI partner issue resolution monitoring, SIDI roadmap alignment, global ecosystem governance gap analysis & options to remediate.

このうち、2番目のチャンピオンユースケースの実現に向けたデジタルIDに関する最低限の相互運用性要件の定義、3番目のトラストフレームワークのマッピングに関する定例会議が始まりました。

それぞれ、以下の曜日・時間帯でスタートします。

  • 最低限の相互運用性要件の定義
    • 毎週月曜日の16:00-17:00(CET)
    • 4/29(UTC)から開始
    • 日本時間で言うと4/29(月)23:00-24:00(つまり今晩)※現在CESTだったので修正
  • トラストフレームワークのマッピング
    • 毎週木曜日の14:30〜15:30(UTC)
    • 5/2(UTC)から開始
    • 日本時間で言うと5/2(木)23:30-24:30

※時差計算は苦手なので間違っていたらすみません。


こちらのページで興味のあるワークストリームに登録をすると案内メールが流れてくるので、その中に参加用のTeams会議のリンクがあります。ぜひ参加しましょう。



VC-JOSE-COSEがCRに

$
0
0

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

VC-JOSE-COSEがW3CのCR(勧告候補)になっていますね。

https://www.w3.org/TR/2024/CRD-vc-jose-cose-20240425/



Mike Jonesも書いているように先日同じく勧告候補になったVCDM(Verifiable Credentials Data Model)v2.0では前のバージョンと異なりクレデンシャルフォーマットにJSON-LDだけをサポートするようになっています。

一方でこのVC-JOSE-COSEはJOSE、SD-JWT、COSEをスコープとしているのでなんだかチグハグな感じになりつつあります。

まぁ、そもそもクレデンシャルフォーマットがISOのmDoC、IETFのSD-JWTやJWP、W3CのVCDMと割れてしまっているが今後どうなっていくんだろうか・・・という話ではあるんですが。

Trusted Signing(元Azure Code Signing)がPublic Preview

$
0
0
こんにちは、富士榮です。
ちょっといつもと話題を変えてコード署名の話です。

昔から(少なくともプロダクションの)コードに署名しましょう、という話はありましたが署名するための環境を用意するのは面倒くさいという難点がありました。

ということでこの辺りをas a ServiceとしてMicrosoftが提供しようとしているのがAzure Code Signingなのですが、これが「Trusted Signing」としてPublic Previewになりました。

アナウンス

サービス内容はこちらのようです。基本的にマネージドな基盤として提供され、GithubやVisual StudioなどのCI/CDに組み込んでいくこともできるものです。
  • We manage the full certificate lifecycle – generation, renewal, issuance – and key storage that is FIPS 140-2 Level 3 HSMs. The certificates are short lived certificates, which helps reduce the impact on your customers in abuse or misuse scenarios. 
  • We have integrated into popular developer toolsets such as SignTool.exe and GitHub and Visual Studio experiences for CI/CD pipelines enabling signing to easily integrate into application build workflows. For Private Trust, there is also PowerShell cmdlets for IT Pros to sign WDAC policy and future integrations with IT endpoint management solutions. 
  • Signing is digest signing, meaning it is fast and confidential – your files never leave your endpoint. 
  • We have support for different certificate profile types including Public Trust, Private Trust, and Test with more coming soon! 
  • Trusted Signing enables easy resource management and access control for all signing resources with Azure role-based access control as an Azure native resource. 
  • To learn more about the service go to: https://learn.microsoft.com/azure/trusted-signing

まぁ、当然お金はかかるわけですが、自前でCAを立てて運用するよりは楽ですね。

  • BASICプラン
    • 基本料金:$9.99/月
    • 月間署名数上限:5,000
    • 上限超過分:$0.005/署名
    • プライベート署名、パブリック署名それぞれについて1つの証明書プロファイルポリシーの定義が可能
  • Premiumプラン
    • 基本料金:$99.99/月
    • 月間署名数上限:100,000
    • 上限超過分:$0.005/署名
    • プライベート署名、パブリック署名それぞれについて10個の証明書プロファイルポリシーの定義が可能

ちなみに使おうとするとサブスクリプションのResource ProviderにMicrosoft.CodeSigningを登録してあげる必要があります。
くわしくはこちらから。




まぁぼちぼち使ってみますかね。。。

日EUデジタルパートナーシップの目玉の一つはデジタル・アイデンティティとトラスト

$
0
0

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

4/30にベルギーで開催された2回目となる日EUデジタルパートナーシップ閣僚級会合が開かれて、共同声明が発行されましたね。

(デジタル庁のポストより)

https://www.digital.go.jp/news/955484d4-1ba4-4680-b0d8-a0e78946508c

共同声明の1番目(1番目っていうのが大事!)に「デジタル・アイデンティティに関する協力推進」が記載されています。(赤字、アンダーラインはブログ著者による)

OECDでのDFFT専門家コミュニティの設立を含むパートナーシップのための制度的アレンジメント(the Institutional Arrangement for Partnership:IAP)の始動を歓迎する。OECD閣僚理事会(2024年5月2日、3日)での連携を含め、IAPの更なる強化に関して引き続き協力する。本パートナーシップの機会を捉え、河野デジタル大臣とブルトン欧州委員との間でデジタル・アイデンティティの協力推進に関する協力覚書に署名した。日本に対するEUの十分性認定の範囲を学術研究分野及び公的部門に拡大する議論を歓迎する。

対象分野として学術研究分野についても触れられており、毎日新聞の記事を見ると「具体的には、転職や留学で用いる学歴などのデータを互いに流通させる仕組みを2024年中に先行開始できないか検討する。(以下の記事より引用)」とありますので、EUDIWのLSP(ラージスケールパイロット)の中のテーマの一つである学位・学修歴クレデンシャルを日EUで相互運用できるようになったりすることが期待されます。

https://mainichi.jp/articles/20240430/k00/00m/300/189000c

なお、この閣僚級会合に先立ち、4/17にステークホルダーを集めたワークショップがあり、私も急遽日本における学修歴クレデンシャルの状況についてお話しさせていただきました。この際もEU側からも相互運用に向けて取り組みを進めたい、というコメントもありましたので、今後に期待ですね。

こちらがワークショップのページです。ちょうどIIWで西海岸にいた日なので時差がきつかったですが・・・

https://eprd.pl/en/dpa/japan/public-private-stakeholder-workshop/agenda/



実は、このようなデジタルパートナーシップ協定はいろいろな国と締結しており、その中でもデジタル・アイデンティティはしばしばテーマの一つとして取り上げられています。ざっくりデジタル庁のホームページから探した範囲では以下の国々と取り組みについて触れられています。

広く相互運用ができるといいと思いますので、今後もウォッチしていこうと思います。






Entra External IDがGAされています

$
0
0

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

長らくPreviewだったEntra External ID(旧Azure AD B2B、およびCIAM)がGAされました。(といっても特にCIAMはまだまだPreviewの機能だらけなんですけどね・・・)

https://techcommunity.microsoft.com/t5/microsoft-entra-blog/announcing-general-availability-of-microsoft-entra-external-id/ba-p/3974961


個人的にポイントだと思っているのは、いわゆるワークフォースIDであるEntra ID(Azure AD)との機能面での統合が進んだこと、そしてEntra Verified IDとの連携ですね。

しかし、もうここまでくると単なるID基盤という枠には収まらず、他のAzureリソースとの組み合わせを意識した統合的なアイデンティティ・プラットフォームになってきていますね。いよいよインフラとしての設計も難しくなってきてますので、ちゃんとプロ(国井さんとか)の教育を受けて使うことをお勧めします。



個人的にも気になってきたAzure AD B2Cからのトランジションについてはまだまだ情報が不足していますが、現状のCIAMの機能ではとてもじゃないけどAzure AD B2Cの自由度のカバーはできないので、まだしばらくは並行してサポートされていくことになると思います。本社の開発チームの話ではマイグレーションパスなどもゆくゆくは用意していくということなので、こちらも継続ウォッチですね。

NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む(1)

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

先日紹介した通り、NIST SP800-63-3の追補版という形で同期可能なクレデンシャルの取り扱いに関する文書がリリースされました。

今回から中身を少し見ていこうと思います。

しかし、ちょうど最近iOSやmacOSの共有パスワードグループでAirDrop環境外でもパスワードに加えてパスキーまで共有ができるようになった、というアナウンスが界隈では話題に上りました。なんだか単純な同期の話だけでは済まなくなってきてしまった気もしますが、この機能がこのガイドラインにどのような影響を与えるのかは継続ウォッチということで、まずはガイドライン(追補版)を見ていきましょう。

参考)共有パスワードグループ

とりあえずイントロです。例によってDeeplで機械翻訳です。

Introduction

NIST デジタル ID ガイドラインは、ID 証明、認証、およびフェデレーションを 含む、デジタル ID のプロセスと技術要件を規定している。NIST 特別刊行物(SP)800-63B(SP 800-63-3 に関連する第 B 巻)は、認証およびライフサイクル管理 の要件を特に取り上げている。改訂 3 は、このガイドラインの最新の大幅な改訂であり、2017 年 6 月に発行された。シリーズ全体の更新が進行中であり、改訂 4 で完結する予定であるが、技術のペースは NIST の典型的な文書開発およびレビューのプロセスよりも速いため、この補足的な更新が正当化される。

SP 800-63B で扱われるこのような認証タイプは、多要素暗号認証である。通常、この認証タイプは、ハードウェアまたはソフトウェアで暗号鍵を保護し、第 2 の認証要素(記憶された秘密またはバイオメトリック特性のいずれか)による起動を必要とする。秘密鍵を不正な暴露から保護することは、多要素暗号認証機のセキュリティ・モデルの基本である。これには従来、秘密鍵がエクスポートまたはクローン可能でないことを保証することが含まれる。しかし、このパラダイムは変わり始めている。特に、新しい一連の認証プロトコルと仕様により、同期可能な認証子(一般に「パスキー」と呼ばれる)が急速に採用されるようになり、ユーザが異なるデバイス間で秘密鍵を同期(つまり、 複製)できるようになった。

SP 800-63-3 が 2017 年に発行されたとき、2 つの重要なサポート仕様である Fast Identity Online (FIDO) Client to Authenticator Protocol (CTAP) と W3C の Web Authentication(一緒に使用される場合は FIDO2 として知られる)は存在せず、実装の強固でよく理解されたエコシステムもなかった。当時利用可能であった暗号認証の種類に基づき、2017年のガイドラインは、多要素暗号認証が他のデバイスに鍵を「クローン」する能力を制限した。しかし、この2年間でエコシステムは急速に加速し、現在ではほとんどの主要なプラットフォーム・プロバイダが、スケーラブルで同期可能な認証機能を実装している。これらの認証機能は、耐フィッシング性のサポート、特定の依拠当事者にバインドする機能、パスワー ドを送信する必要性の排除、認証機能のリカバリの簡素化、保存された秘密鍵に付随する第 2 要素とし ての多様なデバイス固有の生体認証および PIN の使用など、多くの利点を提供する。また、ますますマルチデバイス、マルチプラットフォーム化する世界に適合する利便性も提供する。どのような新しい技術もそうであるように、技術革新の約束には、探求し理解しなければならない新たな脅威と課題が伴う。そのため、この補遺では、連邦機関が同期可能な認証機能を実装するかどうか、またどのように実装す るかを決定する際に、現代の脅威を含めて考慮すべき事項の概要を示す。
まぁ、先日のポストにも書いた通り、時代が変わったのでver.4を待たずに追補版で同期可能なパスキーに関してちゃんと分析して考慮をしよう、という話です。

次に文書の目的です。

Purpose

この文書の目的は、変化する認証およびクレデンシャルの市場を反映するために、現行の NIST ガイドラインを適合させることである。この補足では、SP 800-63-3 で確立された認証保証レベルと一致する方法で、同期可能な認証機能がどのように脅威を軽減するかを説明し、SP 800-63-3 認証保証レベル 2(AAL2)を達成するために活用できる同期可能な認証機能の理解を連邦機関に提供する。また、SP 800-63B の第 5.1.8 節で説明されているソフトウェア暗号化認証子の使用に関する最新情報、 特に、鍵が別のデバイスに複製(例えば、「クローン」または「同期」)された場合でも、当該認証子が AAL2 認証要件をサポートする能力についても提供する。最後に、本文書は、公衆向けアプリケーション(すなわち、OMB Memorandum M-19-17 に記 載されているように、公衆 ID と相互作用する連邦情報システム)と連邦エンタープライズ・ アプリケーション(すなわち、OMB Memorandum M19-17 に記載されているように、主に連邦エ ンタープライズ ID と相互作用する連邦情報システム)という 2 つのユースケースに基づ いて、実装に関するいくつかの考慮事項を示す。この文書は、SP 800-63-3 にある既存のガイダンスを補足するものであり、SP 800-63B-4 の最終版に取って代わられる。
記載の通りですが、同期可能であってもAAL2を達成できることを説明するための資料になっているってことですね。また、当然ですが最終的にはver.4へ統合されていく文書というわけです。

ということで、ちょっと長めのシリーズになりそうですが徐々に見ていきたいと思いますので、今回はここまでです。



DIFのClaims & Credentials WGの新しいワーキングアイテムに関するWebinarがあります

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

またまた日本時間だと辛い時間帯ではありますが、DIF(Decentralized Identity Foundation)のClaims and Credentialsワーキンググループの新しいワーキングアイテムである、
  • Reusable KYC credentials
  • Age Verification
  • Proof of Humanity
の互換性に関する取り組みのWebinarが日本時間5/15 1am-2amで開催されます。
(申込ページより)

申込ページ


KYCクレデンシャルの応用や年齢確認、(AgentやIoTデバイスなどではなく)人間が操作していることの証明など、あちこちで議論はされていますので、どこの動きを集中的にウォッチすべきか迷う部分はあると思いますし、ともすると車輪の再発明になるので注意は必要ですが、動向は追いかけておいても良いと思います。いずれ日本においても議論しなければならない話ばかりだと思いますので。


NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む(2)

$
0
0

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

引き続きNIST SP800-63-3の追補版を見ていきます。


前回はイントロ、文書の目的について読みましたが今回はAAL2の要件と同期可能な認証器の関係性について見ていきます。

では早速。

Syncable Authenticators Achieve AAL2

NIST の認証機関保証レベルは、主に、認証プロセスに対する特定の脅威から保護する認証機 関の能力を中心に構成されている。AAL2 では、ユーザが 2 つの 1 要素認証子、またはユーザ・アカウントにバインドされた多要素 認証子を所持しているという高い信頼性を提供することが意図されている。表 1 は、SP800-63-3 から要求される脅威の緩和と、適切に構成された同期可能な認証子がこれらの 脅威からどのように保護されるかを示している。

SP 800-63-3 による必要な脅威の緩和(表 4-1) 

要求事項AAL2同期可能な認証器(パスキーなど)
Man in the Middleに対する耐性必須達成
適切に構成された同期可能な認証器は、認証され保護されたチャネルによって、すべての認証デー タを交換する。
Verifierに関するなりすまし耐性必須ではない達成
適切に設定された同期可能な認証器は、一意の公開鍵または秘密鍵のペアを作成し、そのペアの使用は、作成されたドメインに限定される(つまり、鍵は特定のウェブサイトまたはRelying Partyでのみ使用できる)。これにより、改ざんされたウェブ・ページが認証子の出力をキャプチャして再利用することを防ぐことができる。
Verifierに関する侵害耐性必須ではない達成
適切に設定された同期可能な認証器は、検証者側にのみ公開鍵を保存する。これらの鍵は、ユーザ認証には使用できない。同期ファブリックによって保存される秘密鍵は、承認された暗号化技術を使用して暗号化された形でのみ保存される。アクセス制御により、認証されたユーザー以外が保存された鍵にアクセスすることはできない。
リプレイ耐性必須達成
同期可能な認証器は、各認証トランザクションに組み込まれたランダムなノンスを使用する ことで、リプレイ耐性(すなわち、将来のトランザクションでの再利用防止)を防ぐ。
認証の意図推奨達成
同期可能な認証器は、暗号化認証プロトコルを開始するために、ユーザがアクティ ベーション・シークレットを入力することを要求する。これは、ユーザの積極的な参加なしにはイベントが進行しないため、認証の意図として機能する。

セクション5では、同期可能な認証器の設定に関する追加的な考慮事項について論じる。

AAL2 要件を満たすために、同期可能な認証器は、ローカルに保存された鍵をアンロックするた めにローカル認証イベントを利用しなければならない[SHALL]。あるいは、ローカル認証の仕組みが 利用できない場合は、別の認証手段(たとえば、ユーザが選択したパスワード)と併用しなければ ならない[SHALL]。FIDO2 Web認証(WebAuthn)コンテキストでは、W3C Web認証仕様の認証子データで利用可能な User Verificationフラグの値によって示される。FIDO2 WebAuthn 認証データフラグの詳細については、セクション5を参照のこと。

ポイントは最後の一文で、やはり同期クレデンシャル「だけ」ではダメで、ちゃんとローカル認証イベント(たとえば端末アンロックの利用など)を使う必要がある、ということに触れたところでしょうか。

次回も引き続き読んでいきたいと思います。



NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む(3)

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

前回に引き続きNIST SP800-63-3の追補版を見ていきます。

だいぶ中身に入ってきました。
早速読んでいきます。

Updates on the Allowance of Cloning Authentication Keys

SP 800-63B のセクション 5.1.8.1「多要素暗号化ソフトウェア認証機能」は、認証器があるデバイスから別のデバイスへ暗号化認証鍵を「クローン」することを制限している。具体的には、以下のとおりである:

多要素暗号化ソフトウェア認証器は、複数のデバイスへの秘密鍵のクローニングを抑制すべきであり、促進してはならない(SHALL NOT)。

同期可能な認証器は、デバイスや異なるプラットフォーム・プロバイダにまたがって、以前に 登録した認証器へのアクセスをユーザに提供するため、明示的に鍵の複製を促進する。NISTがSP 800-63B-4の初期公開草案(ipd)からこの制限を削除したことで、この現実が認識された。本文書の発行時点で、5.1.8.1 項の上記の記述は、本補足により置き換えられ、本補足に規定される要件に基 づいて導入される同期可能な認証器は、AAL2 で想定される脅威から保護するのに十分であるとみなされるものとする。


そうです、元々のSP 800-63Bでは秘密鍵のクローニングを制限していたわけです。今回の更新でこの点について緩和が行われたわけです。

ただ、そのために満たすべき要件を以下の通り定義しています。

同期可能な認証器のすべての使用に関する一般要件:

  • すべての鍵は、承認された暗号技術を用いて生成されなければならない。
  • デバイスからクローンまたはエクスポートされた秘密鍵は、暗号化された形式でのみ保存されるものとする。
  • すべての認証トランザクションは、デバイス上で生成された、または同期ファブリック(クラウドストレージ など)から復元された暗号鍵を使用して、ローカル・デバイス上で秘密鍵操作を実行しなければならな い。
  • クラウドベースのアカウントに保存された秘密鍵は、認証されたユーザのみがシンクファブリック内の秘密鍵にアクセスできるよう、アクセス制御メカニズムによって保護されなければならない。
  • 同期ファブリック内の秘密鍵へのユーザ・アクセスは、同期された鍵を使用する認証プロトコルの完全性を保持するために、AAL2相当のMFAによって保護されなければならない。
  • これらの一般的要件および同期可能な認証器の使用に関するその他の機関固有の要件は、文書化し、公開ウェブサイトおよびデジタル・サービス・ポリシー(該当する場合)を含め、周知されるも のとする。

ちゃんと認定された暗号技術を使うこと、同期された鍵を使って認証に必要な操作を行う場合はローカルで操作を行うこと(要するにリモート署名なんかはNGってことですね)、秘密鍵へのアクセス制御を行うこと、具体的にはAAL2相当の認証強度で保護されていること、同期可能な認証器を使っていることをポリシーとして公開・周知すること、が記載されています。要は、同期してもいいけどちゃんと認められた方法で管理し、その旨を周知せよ、ということですね。

また、追加要件として以下のについても定義されています。 

連邦企業が同期可能な認証器を使用するための追加要件: 

  • 連邦企業の秘密鍵(すなわち、連邦鍵)は、FISMA Moderateの保護または同等の保護を達成した同期ファブリックに保管しなければならない。
  • 連邦企業の秘密鍵を含む認証器を生成、保管、同期するデバイス(携帯電話、ノート型パソコン、タブレットなど)は、モバイル・デバイス管理ソフトウェアまたはその他のデバイス・コンフィギュレーショ ン・コントロールによって保護され、権限のないデバイスまたは同期ファブリックへの鍵の同期または共有を防止しなければならない。
  • 同期ファブリックへのアクセスは、省庁が管理するアカウント(例えば、中央アイデンティティ・アクセス管理ソリューションまたはプラットフォーム・ベースの管理アカウント)によって制御され、 秘密鍵のライフ・サイクルに対する企業管理を維持するものとする。
  • 秘密鍵を生成する認証器は、認証器の能力およびソースを検証するために使用できる認証機能(例えば、エンタープライズ認証)をサポートすべきである(SHOULD)。

これらの管理は、特に同期をサポートし、FIPS 140 の検証を含む、既存の多要素ソフトウ ェア暗号認証の要件および AAL2 の要件に追加するものとみなされるものとする。

秘密鍵の同期に使うファブリック(要するにクラウドストレージやiCloudやGoogle Platformなど)の保護レベルはFISMA(米国連邦政府のセキュリティ基準)のModerate(平均レベル)もしくは同等が求められています。

また、同期ファブリックへのアクセス制御についてはIAMなどによりしっかり管理されている必要がある、ということなので共有パスワードグループはこの辺りに引っかかるんじゃないかな、、と思います。多分、企業などでiOSやmacOSを使う場合はMDMなどで共有パスワードグループを制御する(できるかどうかは知りませんが)ことが必要になりそうです。



Entra IDの外部認証プロバイダの利用機能がPreview公開されています

$
0
0


Entra IDで外部の認証手段が使えるようになったようです。

むかーし、3rdパーティの多要素認証プロバイダの設定を行う機能が一瞬出て消えていったものの後継ですね。当時はPremium P2ライセンスが必要でDuoやRSA、Trusonaなどプリセットされたものを認証プロバイダとして利用することができました。
当時の記録

まぁ、中身はid_token_hintを使ってIdPをチェインさせているだけだった気がしますが、当時はあんまり流行らなかったんですかね・・・。

今回のアナウンスとドキュメントを見ているとやはりid_token_hintを使った認証状態の引き回しとチェインであることには変わらなさそうですが、より柔軟に構成を行うことができるようになっていますね。ライセンスもPremium P1でOKっぽいですし。

ということで私のテナントでも機能が有効になったのでおいおい試してみたいと思います。


NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む(4)

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

引き続きNIST SP800-63B-3の同期可能な認証器に関する追補版についてみていきましょう。


今回は実際にインプリメンテーションを行う場合の考慮事項や要求事項についてです。

Implementation Considerations and Requirements

同期可能な認証器は、W3CのWebAuthn仕様に基づいて構築されており、共通のデータ構造、チャレンジ・レスポンス暗号プロトコル、公開鍵認証情報を活用するためのAPIを提供している。この仕様は柔軟で適応性があるため、WebAuthnクレデンシャルのすべてのデプロイが連邦政府機関の実装要件を満たすとは限らない。
この仕様には一連の「フラグ」があり、依拠当事者(RP)アプリケーションは、認証イベ ントの追加コンテキストを提供し、それが RPのアクセス・ポリシーに適合するかどうかを判断す るために、認証者に要求することができる。本節では、RPとして活動する連邦機関が、NIST AAL2 脅威緩和策に適合する同期可能な認証器の実装を構築する際に理解し、問い合わせる必要がある、WebAuthn仕様の特定のフラグについて 説明する。

表2, WebAuthn Level 3 flags
フラグ説明要求事項と推奨事項
User Present(UP)ユーザが認証器と対話したことを確認するための「プレゼンス」テストを示す(例:USBポートに挿入されたハードウェアトークンのタッピング)。連邦機関は、ユーザ提示フラグが設定されていることを確認しなければならない(SHALL)。認証意図をサポートする。
User Verified(UV)利用可能な「ユーザー検証」メソッドのいずれかを使用して、ユーザーが認証者によってローカル認証されたことを示す。連邦機関は、UV が優先されることを示さなければならず(SHALL)、すべてのアサーションは、UV フラグの値を確認するために検査されなければならない(SHALL)。これは、認証器が多要素暗号認証器として扱えるかどうかを示す。ユーザが検証されない場合、機関は、認証イベントに RP 固有の暗記秘密を追加することで、認証器を1要素暗号認証器として扱うことができる。WebAuthn レベル 3 仕様のさらなる拡張により、機関がローカル認証イベントのコンテキストを得ようとする場合、検証方法に関する追加データが提供される。
Backup Eligibility認証器を別のデバイスに同期できるかどうか(すなわち、鍵を別の場所に保存できるかどうか)を示す。同期可能だからといって、同期済みであることを意味しないことに注意。連邦機関は、同期可能な認証器の使用を制限するポリシーを確立する場合、このフラグを使用してもよい。このフラグは、デバイスにバインドされる認証子と、複数のデバイスにクローンされる 認証子を区別するために必要である。
Backup State認証器が別のデバイスに同期されたかどうかを示す。連邦機関は、他のデバイスに同期された認証器に対する制限を確立する場合、このフラグを使用してもよい。公開アプリケーションの場合、連邦政府機関は、ユーザエクスペリエンス上の懸念から、このフラグに基づいて受諾を変更すべきではない(SHOULD NOT)。企業の判断のために、このフラグは、特定のアプリケーションのために同期可能な 認証器の制限をサポートするために使用してもよい[MAY]。

以前パスキー対応の認証機能を実装した際にも出てきたフラグですね。

https://idmlab.eidentity.jp/2024/02/api.html

同期可能かどうかの判断にはBEやBSを使うわけです。アプリによってはこのフラグを見て同期可能な認証器を受け入れるかどうかを決める、と言うことです。

 

表2に示されるフラグに加えて、機関は、実装および受け入れを選択する同期可能な認証器のオリジンおよび機能について、より詳細な情報を得ることを望むかもしれない。FIDO2 WebAuthn のコンテキストにおいて、認証者の中には、特定の認証者の能力および製造者を 判断するために使用できる認証機能をサポートしているものがある。企業ユースケースの場合、各機関は、プラットフォームプロバイダが提供する機能に基づいて、認証機能を実装するべきである(SHOULD)。好ましくは、RP が認証器に関する一意の識別情報を要求するエンタープライズ認証の形をとる。

構成証明(Attestation)は、広範な公衆向けアプリケーションに使用すべきではない(SHOULD NOT)。このような要件(すなわち、構成証明に対応していない場合、一部の一般ユーザの同期可能な認証器をブロックする要件)は、ユーザをショートメッセージサービス(SMS)のワンタイムパスワード(OTP)のような、フィッシングに脆弱な安全性の低い認証オプションに誘導する可能性がある。

この視点は面白いですね。パブリック(共有端末とかのイメージかな?)なアプリケーションで同期可能な認証器を使うとってしまうまずいので同期可能なクレデンシャルをブロックすると言うポリシーを適用すると、手軽な認証手段を実装しがちになる、という話でしょうか?(@Shiroicaさんご指摘ありがとうございます)


RP がフラグおよび認証データを要求しても、認証器は要求された情報をすべて返さないかもしれないし、リソースへのアクセスに要求される期待応答と矛盾する情報を返すかもしれない。したがって、各機関は、同期可能な認証器を使用するユースケースを評価し、返された情報に基づいて適切なアクセスポリシー決定を行うことが決定的に重要である。
こちらも現実論として全ての認証器がちゃんとフラグを返してくるということは期待してはいけない、ちゃんとリスクを含め評価をしてポリシーを決めようね、ということです。これ非常に大事だと思います。


ということでまだ続きますが、今回はここまでです。

Entra IDの外部認証プロバイダの設定を試す(1)

$
0
0

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

先日当Blogにも書いたとおり、最近Previewが公開されたEntra IDの外部認証を少しずつ試していきます。

設定はこの辺りのドキュメントを見ればできそうです。

https://learn.microsoft.com/ja-jp/entra/identity/authentication/how-to-authentication-external-method-manage


ざっとやり方と条件を見ていくと、こんな感じっぽいです。

  • Entra ID上にマルチテナントアプリとして外部認証システムをクライアント登録する
  • 外部認証システムがEntra IDが発行したid_token_hintを検証できるようにEntra IDのDiscoveryエンドポイントを解釈できるように構成する
  • 外部認証システムへEntra IDをクライアント登録する
  • 外部認証システムの認証強度の要求はclaimsパラメータを利用し、amr/acrの値が要求される。そのため外部認証システムは指定された値のamr/acrを返却できるように構成する必要がある
  • 外部認証システムの認可エンドポイントへのアクセスはPOSTで行われる
  • 外部認証システムからEntra IDへのid_tokenの引渡しはform_postを使う必要がある

まだ細かいところは色々とありますが、やりながら潰していきましょう。

しかしまぁ、結構条件厳しめですね。やはり自作IdPをカスタマイズしつつ対応させていくのが良さそうです。


と言うことで徐々に試します。今回は外部認証システムへ認証要求が飛ぶところまでを見ていきます。

マルチテナントアプリの登録

まずはEntra IDに外部認証システムを登録してあげる必要があります。ログイン前に参照することが必要になる、かつ他のマルチテナントアプリに対して認証する可能性があることから、外部認証システム自体の登録もマルチテナントアプリとしてクライアント登録を行います。

この際、redirect_uriには外部認証システムの認可エンドポイントのURLを指定する必要があります。

次に、APIアクセス許可を行います。

Microsoft Graphへのアクセス許可をする(委任されたアクセス許可)必要があります。

対象の権限にはopenidとprofileを指定します。

管理者の同意を付与しておきます。


外部認証の設定を行う

いよいよ外部認証システムの登録を行います。
  • 名前は適当でも良いのですが後から変えられないので注意が必要です。
  • クライアントIDは外部認証システム側にEntra IDを登録する際に発行されるクライアントIDを指定します。(次回以降で外部認証システム側への登録の話をします)
  • 検出エンドポイントには外部認証システムのdiscoveryエンドポイントを指定します。
  • アプリIDは先ほどEntra ID上に登録したマルチテナントアプリのクライアントIDを指定します。

また、この認証方式を使うことができるユーザが所属するグループを指定し、設定を有効にして保存します。

動作を確認する

この状態でユーザでログインをする際に多要素認証が求められるように設定しておくと、認証方式として先ほど指定した方式が出てきます。(出てこない場合はMicrosoft Authenticatorが現在使えない、というリンクをクリックすると出てきます)

こちらを選択すると、外部認証システムへリダイレクトされるのですが、トレーサーでリクエストを見ると以下のように認可エンドポイントへPOSTでid_tokenやclaimsを含んだリクエストが飛んでいることがわかります。

id_token_hintを紐解くとこんな感じです。

おすすめは外部認証システム側にoid(オブジェクトID)とtid(テナントID)を紐づけた形でユーザを作成しておき、当該のユーザで認証することです。(preferred_usernameだと変わってしまう可能性があるので)

また、認証方式・強度などに関する要求はclaimsパラメータで指定がされていますので、外部認証システムはこの条件を満たす形で認証を行い、id_tokenのacr/amrに値を含めてEntra IDへ送出してあげる必要があります。 

{
"claims": {
"id_token": {
"amr": {
"essential": true,
"values": [
"face",
"fido",
"fpt",
"hwk",
"iris",
"otp",
"tel",
"pop",
"retina",
"sc",
"sms",
"swk",
"vbm"
]
},
"acr": {
"essential": true,
"values": [
"possessionorinherence"
]
}
}
}
}

次回以降は外部認証システム側の設定を調整していきたいと思います。

 



NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む(5)

$
0
0
こんにちは、富士榮です。
引き続きNIST SP 800-63B-3への追補版を見ていきましょう。



今回は同期可能な認証器に関する脅威とチャレンジについてです。

Syncable Authenticator Threats and Challenges

同期可能な認証機能には、導入または展開の前に評価すべきいくつかの明確な脅威および課題がある。表3にこれらのリスクと推奨される軽減策の概要を示す。

表3. 同期可能な認証器の脅威、課題、緩和策
脅威と課題説明緩和策
鍵の不正使用または管理の喪失同期可能な認証器の中には、鍵を悪用する可能性のある他のユーザが所有するデバ イスへの秘密鍵の共有をサポートするものもある。- 同期されたキーの共有を防止するエンタープライズ・デバイス管理機能または管理されたプロファイルを強制する。
- 利用可能なすべての通知チャネルを通じて、鍵共有イベントをユーザーに通知する。
- ユーザが鍵、鍵の状態、鍵が共有されたかどうかを確認できる仕組みを提供する。
- 既存の認識およびトレーニングの仕組みを通じて、鍵の不正使用のリスクについてユー ザーを教育する。
同期ファブリックへの侵害鍵の同期をサポートするために、ほとんどの実装は、アカウントに関連付けられた複数のデバイスに接続されたクラウドベースのサービスである「同期ファブリック」に鍵をクローンする。- 暗号化された鍵マテリアルのみを保存する。
- 認証されたユーザ以外が秘密鍵にアクセスできないように、同期ファブリックのアクセス制御を実装する。
- クラウドサービスの基本的なセキュリティ機能(FISMA Moderate 保護または同等の保護など)を評価する。
- ハードウェア・セキュリティ・モジュールを活用し、暗号化鍵を保護する。
同期ファブリックへの不正アクセスと復旧同期された鍵は、クラウドベースのアカウント回復プロセスを通じてアクセスできる。これらのプロセスは、認証者にとって潜在的な弱点となる。- SP 800-63B に準拠した認証回復プロセスを導入する。
- デバイス管理またはマネージド・アカウント機能により、連邦エンタープライズ鍵の回復機能を 制限する。
- 復旧をサポートするために、AAL2 以上の複数の認証機関をバインドする。
- 同期ファブリックへのユーザ・アクセスに新しい認証者を追加する場合は、AAL2 認証を要求する。
- 連邦政府の企業シナリオでは、派生認証としてのみ使用する。
- ユーザにリカバリ活動を通知する。
- ユーザが管理する秘密鍵(シンク・ファブリック・プロバイダが知らないもの)を利用し、鍵の暗号化と回復を行う。
取消同期可能な認証器はRP固有のキーを使用するため、そのキーに基づくアクセ スを一元的に取り消すことは困難である。たとえば、従来の PKI では、CRL を使用してアクセスを一元的に取り消すことができる。同様のプロセスは、同期可能な認証器(または FIDO WebAuthn ベースの認証器)では利用できない。- ユーザが認証情報を管理するための中央 ID 管理(IDM)アカウントを導入し、認証情報が漏 洩したり失効したりした場合は、「所属機関」アカウントから認証情報を削除する。
- SSO およびフェデレーションを活用し、インシデント発生時に失効させる必要のある RP 固 有の鍵の数を制限する。
- ユーザが鍵の有効性と最新性を確認するよう定期的に要求するポリシーとツールを確立する。

ここにありましたね。同期と共有の違い。やっぱりMDMとかでコントロールするしかなさそうですね。
ちなみに次の章は共有に関して丸々一章を割いているのでやはり課題感は大きいんだと思います。

JWTヘッダのメディアタイプの大文字・小文字問題でハマった話

$
0
0

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

id_tokenを作るときにJWTヘッダのメディアタイプ(typパラメータ)の値として'JWT'を指定すると思いますが、この値の大文字・小文字ではまった話です。

ちなみに、こんな感じでjoseのライブラリを使ってJWTを作っていたのですが、下から2行目のオプション指定のところで{ typ: 'jwt' }という形で小文字指定をしていました。

// JWSの作成
exports.generateJWS=asyncfunction(payload) {
constks=fs.readFileSync(path.resolve(__dirname, keyStoreFile));
constkeyStore=awaitjose.JWK.asKeyStore(ks.toString());
const [key] =keyStore.all({ use:'sig' });
   constopt= { compact:true, jwk:key, fields: { typ:'jwt' } };
returnjose.JWS.createSign(opt, key).update(JSON.stringify(payload)).final();
}

JWTの仕様を見る限りnot case sentisiveとあるので、その後にあるレガシー実装との互換性のために常に"JWT(大文字)"を使うことを推奨という文言を舐めていました。

If present, it is RECOMMENDED that its value be "JWT" to indicate that this object is a JWT.  While media type names are not case sensitive, it is RECOMMENDED that "JWT" always be spelled using uppercase characters for compatibility with legacy implementations.

仕様)

https://datatracker.ietf.org/doc/html/rfc7519#section-5.1


ということで、MicrosoftのRPに小文字'jwt'で作ったid_tokenを投げ込むとこんな感じで怒られます。

仕方なく、コードを修正しました。

exports.generateJWS=asyncfunction(payload) {
constks=fs.readFileSync(path.resolve(__dirname, keyStoreFile));
constkeyStore=awaitjose.JWK.asKeyStore(ks.toString());
const [key] =keyStore.all({ use:'sig' });
constopt= { compact:true, jwk:key, fields: { typ:'JWT' } };
returnjose.JWS.createSign(opt, key).update(JSON.stringify(payload)).final();
}


確かに軽く他社の実装(Microsoft以外だとAuth0とかGoogleとか)を見るとちゃんと大文字になってますね。

Entra IDの外部認証プロバイダの設定を試す(2)

$
0
0

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

前回に引き続きEntra IDの外部認証を試していきます。

こちらのドキュメントを見つつ設定をしていきますが、なかなかハマりポイントがあります。ちなみに外部認証は細かい動きを見るためにも自前のIdPを使っていきます。

ハマりポイントだけ先に書いておきます。

  • jwks_uriエンドポイントに公開するjwk(id_tokenの署名検証するための鍵)はx5cを含む必要がある
  • id_tokenのJWTヘッダのメディアタイプは大文字"JWT”を指定する必要がある(昨日のポストの通り)
  • 外部認証プロバイダのdiscoveryとjwks_uriの情報をEntra ID側がキャッシュをするので変更があっても24時間は読みにきてくれない
  • 外部認証プロバイダから返却するid_tokenの中のamrは配列で返す必要はあるが、返す値は単一である必要がある
  • response_typeはid_token、reponse_modeはform_postで認証レスポンスを返却する必要がある(まぁ、この辺はいつものMicrosoftですね)
  • 外部認証プロバイダの認可エンドポイントへ各種パラメータがPOSTされてくる(こちらは前回書いた通り)


とりあえず、こんな感じで動きます。ngrokでローカルで動かしているIdPを読みにこさせているので画面左側にtrafic inspectorを出しています。Entra IDでログインする際にリクエストが来ているのがわかります。



外部認証プロバイダの認可エンドポイントへPOSTされてくるデータなどをtrafic inspectorで確認しながら実装を進めていくのが良いと思います。

ということで、外部認証プロバイダを実装していきます。

まずは認可エンドポイントです。

こちらが認可エンドポイントへ投げ込まれてくるパラメータですので、こちらに対応する形でid_tokenを発行して返してあげれば良いはずです。

パラメータ
scopeopenid
response_modeid_token
client_id外部認証プロバイダ側にEntra IDをRPとして登録した際のclient_idの値
redirect_urihttps://login.microsoftonline.com/common/federation/externalauthprovider
claims{"id_token":{"amr":{"essential":true,"values":["face","fido","fpt","hwk","iris","otp","tel","pop","retina","sc","sms","swk","vbm"]},"acr":{"essential":true,"values":["possessionorinherence"]}}}'
nonceEntra IDが払い出すnonceの値
id_token_hintEntra ID側で認証済みのユーザに関する情報
client-request-idEntra ID側でのトラッキングに使う識別子(サポート用)
stateEntra ID側が払い出すstateの値


最終ゴールはid_tokenを生成し、リクエスト内のstateと合わせてredirect_uriへPOSTしてあげることとなります。

こんな感じでエンドポイントを作っていきましょう。

// 認可エンドポイント(POST)
router.post("/authorize", async (req, res) => {
// Todo
// - redirect_uriが登録済みでEntra IDから提供されている規定値(https://login.microsoftonline.com/common/federation/externalauthprovider)であることの検証
// - client_idがEntra IDに割り当てたものであることの検証
// - id_token_hintの署名等の検証
// - ユーザ認証(id_token_hintに含まれるoid/tidを使ってユーザとの紐付け)
// - 認証応答を行う
// - redirect_uriへPOSTする
// - id_token
// - state : リクエストに含まれるstate(存在する場合)
// - id_tokenの中身
// - iss : idpのopenid-configurationで公開されているものと一致すること
// - aud : Entra IDに割り当てたclient_id
// - exp : 有効期限
// - iat : 発行時刻
// - sub : id_token_hintのsubと一致すること
// - nonce : リクエストに含まれるnonce
// - acr : リクエストのclaimsに含まれる値の一つと一致すること
// - amr : リクエストのclaimsに含まれる値と一致すること(配列)

結構やることはありますが、今回はまずはid_tokenを発行するところにフォーカスを当てますので、ユーザの認証や各種パラメータの検証は省略します。

id_tokenに含めるべき値にリクエスト内のid_token_hintに含まれる情報があるので、まずばid_token_hintのpayloadをデコードして値を取り出せる状態にパースします。

// とりあえずpayloadだけパースする(検証は後回し)
constid_token_hint_payload=req.body.id_token_hint.split('.');
constraw_id_token_hint=base64url.decode(id_token_hint_payload[1]);
constobj_id_token_hint=JSON.parse(raw_id_token_hint);

そしてid_tokenのpayloadを生成します。今回は検証もユーザ認証もしないので、acrやamrの値も決め打ちで設定しています。ちなみにハマりポイントにも記載した通り、amrは配列で値を設定する必要がありますが、値は単一でなければなりません。(今回はfidoを設定)

constdate=newDate();

constraw_id_token= {
iss:'https://'+req.headers.host,
aud:req.body.client_id,
exp:Math.floor((date.getTime() + (1000*60*10)) /1000),
iat:Math.floor(date.getTime() /1000),
sub:obj_id_token_hint.sub,
nonce:req.body.nonce,
acr:'possessionorinherence',
amr: ['fido']
};

そして、このpayloadを署名してJWTと作ります。

constid_token=awaitutils.generateJWS(raw_id_token);

こちらも面倒だったので、opensslで作った秘密鍵をベタ打ちでコードに埋め込んでいますし、kidも生成したものをベタで指定しています。この辺はおいおい直します。

constjwt=require('jsonwebtoken');
constprivatekey=`-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQEAmbjCIt20NKwMrH78TGOA8w9LS/R6B81RNHoJ/J+7UljRUfMN
sGC+RR6bqtDxeLgLjmt4s7CccbVf380DQx4b2XtCvoP0QW4GsJm7b13XkwCD6fWT
xSX5RTqXyTrLFk0ifOhRZ09QxZnAOGgUN12HeKjWj24XLQKFOROi8BhwHxLLSd+n
-- 省略 --
52EKdTgNOrVFGV/1qACGuDgLNDss+z2f2HgO/pk5UtS0EaXltv62IV6izkZh7f9O
aPXrS0BclfaGBZ0RcQIt0lJ2UMSTd8CFKX+k5efoFthX2ddWY24A
-----END RSA PRIVATE KEY-----`

exports.sign=asyncfunction(payload){
returnjwt.sign(payload, privatekey, {
algorithm:"RS256",
keyid:"Vzy3LDbuzSrt0cQldElZp5R92etQvOCENEu5aOOppYs"
});
}

あとはid_tokenとstateをPOSTしてあげるだけですが、node+express+ejsを使っているのでres.renderで値をejsへ渡してあげます。

// form postするためのページをレンダリング
res.render("./form_post.ejs",
{
redirect_uri :req.body.redirect_uri,
id_token:id_token,
state:req.body.state
}
);

フォーム側はこんな感じです。実際は値はhiddenにして、JavaScriptで自動POSTするようにしますが、今回はステップバイステップで進めたかったので一旦フォームを表示するようにしています。

<html>
<body>
<divid="login_div">
<formname="id_token"method="POST"action="<%= redirect_uri%>">
<inputname="id_token"type="text"value="<%= id_token%>">
<inputname="state"type="text"value="<%= state%>">
<inputtype="submit"value="POST">
</form>
</div>
</body>
</html>

これでうまくいけば上記の動画のように認証が完了します。

一旦、今回はここまでです。


Entra IDの外部認証プロバイダの設定を試す(3)

$
0
0

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

引き続きEntra IDの外部認証について見ていきます。


今回は、前回のポストに記載したハマりポイントにも記載したjwksで公開する鍵の作り方を書いておきます。

ポイントはx5cを含む形でjwkを作成〜公開すること、です。要するに証明書を含め公開することでキーチェインがわかるようにする必要があるってことですね。

今回は当然自己証明証明書を使っているので、opensslで鍵ペアの作成等を行っています。

大まかには川崎さんが公開しているこちらのQiitaと類似の手順を通ればOKですが、今回はRSAでやったのでちょっと手順も異なる部分もあります。

前提)

  • MacOSを使っています
  • opensslはMacOS標準ではなくbrew install opensslをインストールした以下のバージョンを利用する必要があります(標準版だと一部新たなパラメータに対応していないため)
    • OpenSSL 3.3.0 9 Apr 2024 (Library: OpenSSL 3.3.0 9 Apr 2024)
  • pem-jwkを使いますのでnpm installしておいてください
  • jqを使いますので同じくnpm installしておいてください
ということで鍵生成をしていきます。

まずは鍵ペアの生成をします。いきなりjwk形式で作ります。

openssl genrsa -traditional 2048 | pem-jwk > keypair.jwk

次にpemに変換します。

pem-jwk keypair.jwk > keypair.pem

公開鍵を抽出します。

openssl pkey -pubout -in keypair.pem > public.pem

証明書を作ります。CNにはissuer名を指定します。 

openssl req -x509 -key keypair.pem -subj /CN=7...省略...25.ngrok-free.app -days 3650 > certificate.pem

jwkに証明書を入れます。

CERT=$(sed /-/d certificate.pem | tr -d \\n)

jq ".+{\"x5c\":[\"$CERT\"]}" keypair.jwk > key+cert.jwk


これで出来上がったjwkをjwks_uriに入れ込んで公開します。ちなみに上記ではuseのパラメータが設定されないことがあるので必要に応じて"sig"を手動でセットしておきます。

その後、こんな感じでjwksとしてセットします。


これをkeystoreとして読み込んでjwks_uriエンドポイントで公開します。

// jwks_uriエンドポイント
router.get('/jwks_uri', async (req, res) => {
constks=fs.readFileSync(path.resolve(__dirname, "../keys/keystoreSign.json"));
constkeyStore=awaitjose.JWK.asKeyStore(ks.toString());
res.json(keyStore.toJSON())
});

これでEntra IDが署名検証に使える状態で鍵を公開することができました。

こんな感じです。


まぁ、雑ですが一通りの原理はわかる状態まで持っていくことができました。

あとはちゃんと外部認証プロバイダ側を実装するだけですね。 

今年もBuildのシーズンがやってきた

$
0
0

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

今年もBuildのシーズンですね。


https://build.microsoft.com/en-US/home

今年もシアトルでの対面とオンラインのハイブリッド開催のようです。しかし昨年もそうだったんですが、今年もセキュリティやアイデンティティ系のセッションは殆どがIn person(対面)のみ、かつレコーディングもされないという悲しい感じです。

ざっくりセキュリティ、アイデンティティで絞り込むとこのくらいのセッションが出てきます。(少ないですね・・・)

codetitletypedatetimedescription
DEM764Combatting fraud with real time identity verificationin person5/233:45 AM - 4:00 AMAnyone can identify a bicycle or count stop lights. How do we know our apps are serving the right users? CAPTCHAs do not work. Introducing Face Check using Microsoft Entra Verified ID: reduce sign-up friction, the risk of fraud and account takeover. Face Check enables apps to perform real time biometric match against identity documents issued by government (e.g. driver's license or passports) or businesses and education institutions.
-On-Demand: Boost your app security with real time biometric authenticain personon-demandIntegrate simple-to-use APIs to upgrade your mobile, web or desktop apps with high-assurance identity verification to reduce friction and risk from account takeover and impersonation.
DEM760Create secure applications in minutes with VS Code and External IDin person5/223:30 AM - 3:45 AMLearn how to use the Microsoft Entra External ID extension for Visual Studio Code to create your first External ID application completely within your IDE. Bootstrap your development with pre-configured sample applications to quickly get you started.
DEM768Create pixel perfect authentication experiences for native mobile appsin person5/244:45 AM - 5:00 AMThe Authentication API and SDK in External ID allow developers to create pixel perfect UX for sign in and sign up experiences in their mobile applications. Join our product experts to explore the APIs and SDKs for Microsoft Entra External ID that give you the control and flexibility to create fully custom and secure login experiences on mobile devices.
-True zero-trust runtime security in AKSonlineon-demandNeuVector is open source, container native and can make your containerized workloads more secure… today! See first hand how to get to true zero-trust runtime security in AKS and other Kubernetes deployments with NeuVector by SUSE. We will take an application through its deployment lifecycle, from Dev/Test to Q/A to Production, and automate the 'fingerprint" of appropriate behaviors in your software stack. Join us for this real-world example of how to not just identify attacks but to actually prevent them.
DEM766Simple and secure app authentication with authentication brokersin person5/236:45 AM - 7:00 AMWe delve into the integration of Web Account Manager (WAM) on Windows through various MSAL libraries such as MSAL.NET, MSAL Python, and MSAL Java. The session will highlight the seamless authentication experiences enabled by WAM, which simplifies account management on Windows devices. We’ll explore how MSAL libraries facilitate public client authentication flows with Microsoft Entra ID, enhancing web, mobile, and desktop applications.
DEMFP867Unleash the power of network APIsin person5/247:45 AM - 8:00 AMLearn how you can leverage the advanced capabilities of telecom operator networks through APIs to enhance your applications. This session will cover GSMA Open Gateway and CAMARA, examples of how mobile operators are working with developers to open up network APIs, and how developers can engage via Microsoft’s platform and services with Azure Programmable Connectivity (APC). We will also showcase a demo mobile app using the network's APIs through APC and show the code on how to develop with it.


個人的に興味があるのは、1行目のCombatting fraud with real time identity verificationと最後の行のUnleash the power of network APIsくらいでしょうか。前者はEntra Verified IDとfacecheckの話です。後者はMicrosoftのイベントでは結構珍しくネットワークキャリアを対象としておりGSMAやCAMARAの話なんかをカバーしているっぽいので聞いてみたいですね。

レコーディングもされませんし配信もされないので聞けませんが・・・(残念)



OpenID Technight #21のスライド

$
0
0

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

以前告知した通り、本日はOpenID Technightでしたね。

https://openid.connpass.com/event/316748/





私は4月に開催されたOpenID Foundation WorkshopとInternet Identity Workshopからトピックスをお伝えしたわけですが、時間もあまりなかったので伝えきれなかったところも多々あります。スライドをこちらに置いておきます。よろしければどうぞ。

https://speakerdeck.com/fujie/openid-foundation-updates








IIWの振り返り by Phil Windley

$
0
0

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

昨日はOpenID TechnightでInternet Identity WorkshopとOpenID Foundation Workshopの振り返りをしましたが、そういえば主催者の一人のPhil Windleyも振り返りのポストをしていたなぁ、と思い紹介したいと思います。

https://www.windley.com/archives/2024/04/internet_identity_workshop_xxxviii_report.shtml

参加者の分布が分析されています。


US (241), followed by Canada (11). Germany, India, and Switzerland rounded out the top five with 9, 8, and 7 attendees respectively. Attendees from India (5), Thailand (3), and Korea (3) showed IIW's diversity with attendees from APAC. And there were 4 attendees from South America this time. Sadly, there were no attendees from Africa again.

やっぱり北米が多いですねぇ。ローケーション的に仕方ありませんが。

なお、ここには記載がありませんが日本からは5〜6名だったと思います。それなりに参加していると思います。

会場の写真も紹介されています。私も左の端の方にこそっと写っています(人の影なので顔は隠れていますが)



毎回ですがDoc SearlsがFlickrにアルバムを作っているので現地の様子が知りたい方はぜひご覧ください。


https://www.flickr.com/photos/docsearls/albums/72177720316609417/








NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む(6)

$
0
0

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

少し間が開きましたがNIST SP 800-63B-3の追補版の続きです。

今回は同期と共有は違うぞ!という話のうちの共有の部分です。1回目にも書きましたがAppleの共有パスワードグループの話などもありますので、非常に重要な部分だと思います。

サイバーセキュリティ・ガイドラインは、歴史的に、ユーザ間で認証器を共有しないよう警告してきた。このガイダンスにもかかわらず、一部のユーザ・グループやアプリケーションでは、個人がデジタル・アカウントへのアクセスを共有できるようにするために、認証器とパスワードの共有が行われている。

表 3 に示すように、一部の同期可能な認証器の実装は、このようなユーザの行動を受け入れ、 異なるユーザ間で認証キーを共有する方法を確立している。さらに、一部の実装は、一般的なサービスにおいて、パスワード共有に代わる便利で より安全な方法として、同期可能な認証器の共有を積極的に推奨している。 

言われてますよ、Appleさん。。

企業ユースケースの場合、鍵の共有に関する懸念は、鍵が承認されたデバイスや同期 ファブリックから移動されることを制限するデバイス管理技術を使用することで、効果的に緩和することができる。しかし、公衆向けのユースケースでは、同様の緩和策は現在のところ利用できないため、 リライングパーティは、同期可能な認証プロバイダが採用する共有モデルに依存することになる。公衆向けアプリケーションの所有者は、共有認証器に関連するリスクを認識する必要がある。公衆と対話する場合、機関は、ユーザがどの特定の認証器を使用しているのかについて限られ た可視性しか持たないため、すべての同期可能な認証器が共有の対象となる可能性があることを想定する必要がある。多くの共有モデルには、リスクを最小化する実質的な制御(例えば、共有を許可するためにデバイス間の近接を要求する)があるが、他の実装はそれほど制限的ではない。

やっぱり共有を制御する方法とセットになっていることが必要なんじゃないかと思いますね。この辺りの判断をリライングパーティに全部任せちゃうのは実質不可能だと思いますし。

この新しいクラスの認証者がもたらす共有のリスクは、特別なものではない。実際には、すべての AAL2 認証タイプに適用され、中には同期可能な認証タイプより弱いものもある。AAL2 のどの認証子も、それを共有しようとするユーザによって共有される可能性がある。ユーザは、パスワード、OTP、帯域外認証子、さらにはプッシュ認証イベントを積極的に共有したり、被指名人(正式か否かを問わない)がエンドユーザに代わって認証を行うことを許可したりすることができる。

各省庁は、直面する特定のリスク、脅威、およびユーザビリティの考慮事項に基づいて、アプリ ケーションにどの認証手段を受け入れるかを決定する。同期可能な認証方式は、AAL2 までの実装を求めるアプリケーションの新しいオプションとして提供されるかもしれず、他の認証方式と同様に、この技術のトレードオフは、セキュリティ、プライバシー、公平性、およびユーザビリティに対する期待される結果に基づいて、うまくバランスをとるべきである。

そろそろこのレポートもおしまいです。

というか早くSP800-63-4の次のドラフトが出て欲しいですね。

 

Viewing all 769 articles
Browse latest View live