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

[LINE Login]どうやってユーザが認証されたのかを判別する

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

LINE Loginの最新の更新によりid_tokenにamr(Authentication Method References)が含まれるようになりました。このパラメータはユーザがどのような方式で認証されて来たのか?を判別するためのパラメータで、例えば多要素認証をしたのかどうかをアプリケーション側が把握して追加のセキュリティ対策をするかどうか判断したい、という場合に使われます。

LINEのニュース
https://developers.line.biz/ja/news/2019/06/

詳しくはこちらを、とあるので早速見てみると確かにid_tokenの構成の中にamrの記述が追加されています。

確かに最近LINEは様々なログイン方法をサポートしているのでアプリケーション側でどんな方式でログインして来たのかを把握したいケースも増えてくると思います。
※現状LINEは多要素認証などはサポートしていないので、例えばシングルサインオンでログインして来たら強制的に追加認証を要求する、などのシナリオくらいの使いみちだとは思いますが。今後FIDOのサポートなどが実現してくればもう少し使えると思います。

と、いうことでログインしてみました。
以下はQRを使った場合ですが、確かにamrにログイン方法が出て来ます。便利です!


先に書いた通り、まだまだ使いみちは限定的ですが、今後の多要素認証やFIDOのサポートに期待ですね。


Identiverse 2019参加メモ(Day2)

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

昨日に引き続きワシントンDCで開かれているIdentiverse 2019への参加メモです。
※Identiverseとはなんぞや?という方は昨日のポストをご覧下さい。

2日目となる本日はKeynoteから始まるある意味本格的にイベントがスタートする日でした。しかしイベントをホストしているPing IdentityのCEOのAndre Durandさんのパワーはすごいですね。10年間この規模になるまでイベントを続けている気力もそうですし、毎回どこからともなく物凄いゲストを連れて来ているのが驚きです。以前はレオナルド・ディカプリオ主演の映画「キャッチ・ミー・イフ・ユー・キャン」の主人公のモデルとなったフランク・アバグネイル氏が出て来て金融詐欺(まさにID盗難)についてKeynoteで語ってくれたりしましたし、今回の目玉はもちろんSteve Wozniak氏ですが、さらにKeynoteスピーカーとしてイリノイ州議員のBill Foster氏が登場してデジタル・アイデンティティについて語る、という豪華なKeynoteから始まりました。

と言うことで2日目のおさらい+αをお届けしたいと思います。

◆キーノート

  • Weathering the Storm: Future Proofing with Identity by Andre Durand
    • Internetとmobilityの発達により、いたるところにアプリケーションが組み込まれる時代となった結果、脅威もいたるところに存在する、と言う状態となっている
    • このようなDisruptionに対して効果的に適応して生き延びていくには重大かつ予測可能な領域を見据えて効率的に投資をしていく必要がある
    • 例えば、自然現象を整理すると以下のように分類可能である
      • メキシコに落下した隕石による破壊は重大だが予測不可能だった
      • 竜巻による破壊の重大性はそれほど大きくなく、かつ予測も難しい
      • 嵐の重大性はそれほど大きくないが、予測はある程度可能である
      • 大型台風による破壊の重大性は大きく、予測も可能である
    • 我々はこの中の重大性が高く、予測可能な領域(大型台風)へ投資を集中しなければならない
    • 例えばこの領域としてあげられるのが、以下の項目である
      • イノベーションの速度
      • カスタマー体験
      • プライバシーとコンプライアンス
      • スマートなアイデンティティ(AI)
      • 境界の消滅
    • それぞれに対する対応は以下の通りである
      • イノベーションの速度
        • 基本方針はAgilityを持つこと
        • 標準に対応する
          • 使うもの;SAML、OAuth、OpenID Connect
          • 投資するもの:SCIM、PSD2、OpenBanking
          • 新しく出て来たもの:WebAuthn、Secevent
        • APIを有効活用する
        • クラウドを活用する
      • カスタマー体験
        • UXの質により顧客が支払う額は変わってくる
          • 86%の顧客がより良いカスタマー体験に対して支払う
          • 82%の顧客が貧弱なカスタマー体験により去る
        • アイデンティティに関する良いカスタマー体験とは、フリクションレスでパーソナライズされた世界のことである
        • より良い体験とは体験していることに気が付かないことである
          • パスワードレス:QR、NFC、BLE
          • 標準:WebAuthn、OpenID Connect
          • ウェアラブル:AppleWatch
      • プライバシーとコンプライアンス
        • FacebookやMicrosoftなど事故もあったけどコンプライアンスが重要って言っている
        • 同意の管理が主なキーワードとなる
      • スマートなアイデンティティ(AI)
        • 過去4年間で270%の成長を見せた
        • センサーとシグナルをスマートなアイデンティティ(Intelligent Identity)により機会と脅威に分類、パーソナライズした世界を実現することができる
      • 境界の消滅
        • クラウドの台頭、デバイスの普及によりネットワーク境界は消滅、アイデンティティが境界となっている
        • アイデンティティによりゼロトラストセキュリティを実現することができる
    • 結局のところ、勝者となるには以下のことが必要
      • ディスラプションを予測・理解する
      • 何が起きるかを予測する
      • プロアクティブにディスラプションを乗りこなす
    • 波を乗りこなしましょう!

  • Aspiring the Future by Bill Foster
    • 元々は科学者で議員
    • 議員の出身を科学者、法律家、政治家の3つに分けると、
      • US議会には科学者がほとんどいない
      • 中国の議会には科学者出身者が多い
      • EUはバランスが良い
    • 科学者の頃は陽子の減衰の研究をやったり、加速器を開発して衝突の観測をしたりしていた
    • 両親がキャピトルヒルで出会った、という過去もあり政治の道へ(科学と政治がUNIONIZED)
    • 2006年に秘書としてキャリアをスタートし、2008年に初当選した
    • セキュアなデジタルアイデンティティは重要である
      • オンラインセキュリティの要であると考えている
      • Fintechなどのテクノロジーに必要である
      • USはエストニアや韓国に対して後塵を拝している
    • 先般、大きな勝利を収めた
      • 電子健康レコードからユニーク識別子を消す、ことを廃止できた
      • 過去21年間にわたり、連邦はユニーク識別子を消して来た
      • このことにより毎年数千人が亡くなっていた
      • また、医者が麻薬を購入することが可能となっていた
    • 米国政府はデジタルアイデンティティの重要性を理解して来ている
      • 誰もJUNKやSPAMを望まず
      • 政府は個人の識別子を付与する役割を持つ
    • これからはAIが搭載されたスマートフォンが普及してくる
      • 多要素認証デバイスとしても利用できる
      • PIIを持ち運ぶこともできる
      • 選択的開示がもっと浸透してくる



  • Next Generation IDM: managing identities for people by Andrew Nash
    • おなじみAndrew Nashのセッション
    • アイデンティティ管理の歴史を振り返りつつ未来を語る
      • LDAP、X.400・・・
      • Identrus、Federal CA・・・
      • MS Passport、SAML、Liberty、Hailstorm・・・
      • OpenID、Infocard、7 Laws of Identity、PayPal・・・
      • OIX、OpenID Connect、NSTIC・・・
    • アイデンティティ情報は新しいユーザ体験の時代へ
      • CapitalOneのアカウントで他のサービスへサインアップ
      • 免許証で他のサービスへサインアップ
    • 新しいアイデンティティの姿とは
      • 自分の情報を
      • 自分のデバイスで
      • 同意に基づき、最低限の共有を行うことにより
      • KYCコストを削減したり、Identity Verificationの最適化を行う
    • Identity Providerが中心の世界からユーザが中心となる世界へ


  • Building Identity Professionals by Sarah Squire
    • IDPro枠ですね
    • 基本的な考え方として希少価値の高いものは高価である
    • アイデンティティオタクも同様である
    • みんなアイデンティティオタクになろう!そして市場価値を高めよう
    • IDProのメンバにサーベイしたところ、41%がIdentityのプロになるには5年から10年はかかると回答した
    • 学校では教えてくれない領域なのでどうすれば良いのか??
    • プロジェクトマネージャーも同じような状況なので、調べてみると、1996年にPMBOKが出てからPM人口が一気に増加したことがわかった
    • そこで、IDPro Body of Knowledgeの作成に取り掛かった
      • 基本的な考え方は、対象の領域について自分よりも知っている人間は誰か?というアプローチ
      • 40のセクションと88のサブセクションで構成
    • 今ではたくさんの企業会員、個人会員に支えられている。Come an Join us!

◆ブレークアウトセッション

ここからはブレークアウトセッションです。
  • A Modern Architecture for Customer Identity Services by GM
    • GMのIdentityアーキテクトによるGMの顧客ID管理のアーキテクチャの解説
    • サービスと顧客を接続するためにアイデンティティを整備する必要性があった
    • しかし、アイデンティティは見えないくらいがちょうどよく、シームレスな顧客体験が重要であると考えている(Invisible Identity)
    • その考えのもと、CIAMを以下の4つのコンポーネントに分離してデザインした
      • Identity
      • Profile
      • Preference
      • Intelligence
    • IDaaSにするかOnpremにするか悩んだけどアタックへの対応などはIDaaSに一日の長があるのでIDaaS(Azure AD?)を選んだ
    • OIDCなどの標準に対応するのはもうすでにオプションではなく必須である
    • 結局大事なのは、
      • 標準を乗りこなす
      • 統制の効いたアーキテクチャをデザイン・実行する
      • 戦略と同期する


  • Bring Your Own Identity: A Skeptical look at Social Login and Single SignOn by Gerry Gebel
    • 元Burtonグループの人でBYOI(今でいうBYOID)のコンセプトを2008年に発表した人
    • モチベーションとしては、
      • 多くのクレデンシャルがサービス提供者によって管理されている状況がいやだ
      • 登録プロセスが面倒だ
      • UXの改善が必要だ
    • プライバシーに関する再考も必要
      • モダンなテクノロジー(スマホなど)
      • Techジャイアント(MSやUberなど)
    • Identity/Credentialの集中化により容易になってしまうこと
      • トラッキング
      • 紐付け
      • データコントロールの弱さ
      • 透明性の欠如
      • 監視
    • 実際、US連邦政府による電話のモニタリングとかあったよね
    • 最近は進歩したのか?
      • VerizonやAT&Tは顧客データを売るのをやめた
      • Apple login?
      • UMA、SSI
    • 今、できることは?
      • アイデンティティとCredentialを分離する
      • Techジャイアントからログオフする


ここから午後のセッションはお休みしてスミソニアン博物館へ出かけました!

◆(おまけ)スミソニアン博物館(航空宇宙博物館)

スミソニアン博物館ってライト兄弟のイメージしかなかったんですが、一つの博物館を指しているのではなく、博物館群を指しているそうです。知りませんでした。今回は時間もなかったので航空宇宙博物館へ行ってきました。

入り口

入り口を入った瞬間にスタートレックがあるのはご愛嬌

月面着陸艇のレプリカ

ライト兄弟のフライヤー号!

他にも色々ありましたが、この辺りで。
しかし日差しが強く、外はものすごく暑かったです。。

◆夕方からのブレークアウトセッション

夕方になり、セッションへ復帰しました。
  • Microsoft Presents: Designing for Decentralized identity and claim-based identity management by Ankur Patel
    • IONの話です。デモもあり面白かったです。
    • 感じている課題感としては、アプリケーション毎にUsernameとパスワードを保持していることによる不便さや結果発生する漏洩、監査が困難になることによる余計なコストの発生など
    • カスタマーのニーズを追っていくとそれぞれ以下のテーマがある
      • 個人
        • プライバシー
        • 個人でデータをコントロールしたい
        • 情報漏洩から保護してほしい
      • 組織
        • 信頼できVerifyできるアイデンティティ
        • コラボレーション(B2BのID管理は大変)
        • GDPR、KYC、AMLのコストを削減したい
      • 政府
        • クロスボーダー、クロスエージェンシーのID
        • 難民向けのID付与
        • 社会的、経済的なインクルージョン
    • IONを使ったデモ
      • シナリオは、
        • 学位の付与(学生証)
        • 学割で本が購入できる
    • IONの設計思想
      • ユーザは一つ以上のDIDを持つことができる
      • DIDはDLTの系をまたいで解決できる必要がある
      • DIDのパーミションはユーザだけがアクセスできる鍵により管理される
      • 属性情報はオフチェインに保存される
      • ユーザは複数のIdentityHubを持つ
    • 次のステップ
      • 簡単に使えるようにする:エコシステムの構築
      • 性能とスケーラビリティ:IONがまさに目指すところ
      • DIFへの参加とコラボレーション・コントリビューション




ここまでです。

この後、OpenID Foundation x Financial Data Exchangeの会食があり参加させてもらいましたが、みなさんAPI保護、KYCなどについて熱く議論をしていて非常に面白かったです。この辺は書けませんが。

後、会食からの帰り道にホワイトハウスも眺めてきました。
G20でトランプ大統領は大阪にいるはずなので、入れ替わりだな・・・とか思ったりしつつw
夜なので、あんまり綺麗に写りませんでしたが。


ということでまた明日。



Identiverse 2019参加メモ(Day3)

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

いよいよ3日目です。そろそろ疲れてきました。
これまでの日記はこちらから。



ということで今日もはじめて行きます。
まずはキーノートから。

◆キーノート

  • Digital Identity for the People by Richard Bird
    • Chief Customer Information Officerの人
    • 人々が自分のアイデンティティをデジタル社会に持つ時代になってきた
    • シートベルトなどと同じく、Consumer保護の考え方はデジタル社会が始まった当時は存在せず、後からポリシーがついてきた
    • GDPR、CCPAは果たしてConsumerの保護になっているのか?
      • 現実問題、施行後にも4億以上のアカウント漏洩が発生している
    • では何が足りないのか?
      • データ保護≠アイデンティティ保護
    • 結局のところ、アイデンティティの保護は人を守ること
      • いくらそのリンクをクリックしてはいけないと言ってもクリックする
      • 現実の数字として、
        • US国民の20%が家に鍵をかけない
        • 63%の強盗は押しいらなくても犯行ができてしまっている
    • デジタル社会で自分を守るということは?
      • データ保護とアイデンティティ保護は同一ではないことを認識する
      • MFAなどでアイデンティティを守ることが必要


  • Digital Identity - A Strategic Imperative by Grant Schneider
    • US FederalのCISOの人
    • 資料なしのプレゼンだったのであんまり拾えてないです
    • アイデンティティ管理はセキュリティのために非常に重要なものであると考えている
    • US連邦のサイバーセキュリティ戦略目標はデジタル社会におけるナショナルセキュリティと経済的なセキュリティを高めること、つまり「いかにして国家と国民の資産を保護するか」が命題
    • そのために、色々と守らなきゃダメ
      • Federal Cyber Security(税金や年金など)
      • 重大インフラのセキュリティ(金融システムや交通システムなど)
    • CEOやCIOがリスクマネージメントをできるように教育することも大事
    • もちろんプライバシーも大事なので、ペルソナの使い分けなども意識しないとだめ
    • アイデンティティ保証も大事だよ
  • The next wave of Identity Standard by Alex Simons
    • アイデンティティに関する標準の3つの波
      • オンプレミス
      • クラウドとモバイル
      • 分権とプライバシー by デザイン
    • オンプレミスにおける相互運用性と利便性の向上
      • 全てがFirewallの内側にある前提
      • ESSO、LDAPの組み合わせによるPasswordインジェクション
      • KerberosによるトークンベースのSSO
      • このころの攻撃はSlammerなどサーバの脆弱性を狙ったものが多かった
    • クラウドとモバイルの世界のためのアイデンティティ
      • SAML:広く使われるようになった最初の標準技術
      • OAuth1.0:実装が難しかったよね
      • OAuth2.0、OpenID Connect:現在のマイクロソフトのソフトウェアはPowerPointからAzureまでこの標準に従っている
        • 2019年6月のデータではAzure ADに接続されているアプリケーションの95%がOAuthもしくはOpenID Connectを使っている
      • このころになると攻撃手段が変わってきて、パスワード盗難がメインとなってきた
        • 81%のデータ漏洩の原因がパスワード盗難に起因している
      • こうなると多要素認証が必要となる
        • FIDO2。すでにWindows10やAndroidは準拠している
      • 次はパスワードレスの時代へ向かっている
        • Azure ADのパスワードレスのデモ(YubikeyでOffice365ポータルへログオンしてます)
        • 2019年7月にようやくAzure AD+FIDOのパブリックプレビューがリリースされる
        • 現状8億のユーザがパスワードレスを有効化している
        • 月間8500万ユーザがパスワードレスでログインしている
      • Token Binding
        • TLSだけじゃない
        • dPOPも
      • SCIM
        • 2019年6月のデータでは675万ユーザがSCIMでプロビジョニングされた
        • Mark Wahlが新しいSCIMのプロファイルを提案している
    • 分権とプライバシー by デザイン
      • 全ての人が自分のアイデンティティを自分でコントロールできる世界へ
      • DIDのデモ(昨日と同じもの) by Ankur Patel
      • まだまだこれから
    • とりあえず、今すぐやるべきこと
      • OpenID Connect、OAuthを使いましょう
      • モダンプロトコルに対応しましょう
      • パスワードレスの時代です
      • とにかく多要素認証を有効化しましょう。99%のID盗難は防げるよ

  • Standards: The Bedrock of Identity
    • パネルディスカッション
      • モデレーター:Pamela Dingle
      • パネリスト:Kim Cameron, Vittorio Bertocci, Brian Campbell, Annabel Backman
    • パネルはきつい。。。あんまり拾えてないです
    • それぞれがフォーカスしている/してきた標準仕様について紹介
    • そういえばVittorioはws-*の人だったなぁ
    • 標準化関連のミーティングはグローバルのあちこちで開催されるのは、みんなに参加してもらいたいから
    • しかしSAMLはなんで800ページにも及ぶ巨大なモノリスになってしまったのか
      • 何にでも対応できるように色々と組み込んでしまった
      • 結果、拡張が難しい巨大な仕様になってしまった
    • その反省を踏まえ、OAuth、OpenID Connectではシンプルなことをシンプルに実装できるように、という原則に則って設計をした
    • SecEventの話し。
      • SSOの世界ではリスクが顕在化した時にドミノ現象で伝搬してしまうので、リスクイベントの標準的な伝達方法が必要となった
    • プロトコル設計をする時はシンプルにすることが大事
      • DIDとOIDC、FIDOを組み合わせることで使いやすい姿を模索するなど
    • これからこの世界をドライブしていこうとしている人たちへメッセージは?
      • 標準化の世界へぜひ参加して
      • コミュニティへ参加すること。メーリングリストがあるので、そこでユースケースや考えたことを共有するところから。Don't be shy!
      • 言語の壁もあるかも知れないけど気にするな

◆ブレークアウトセッション

  • The Identity Architecture Panel
    • パネルディスカッション
      • モデレーター:Barber Amin
      • パネリスト:Kristina Williams, Greg Smith, Stephanie Kesler, Kim Cameron
    • やっぱりパネルはきつい・・・
    • ゼロ・トラストの世界。ブロックからモニター、緩和へ
    • 企業は従業員にとってのIdentity Providerが、管理者はSAMLを知っているわけではないし、我々(IDaaS事業者)はインフラの形を変え管理者が何もしなくても良い世界を作ろうとしている
    • プライバシーはコンシューマだけでなく従業員にとっても非常に重要
      • CIAMのアプローチでは管理者はアイデンティティを管理することができない
      • エンタープライズIAMの世界では管理者が従業員のアイデンティティを管理する
      • コンテキストに合わせた柔軟なユーザージャーニーが必要である
      • マイクロソフトは固定的なログインを柔軟にするためにIdentity Experience Framework(IEF)を提供している
      • IEFを使えば、コンテキストに合わせた柔軟なユーザージャーニーを提供することが可能である
      • 例えば、HRシステムの重要なデータへアクセスする際は追加の認証を要求する、なども考えなければならない
    • どのようにして開発者にプライバシーを保護を意識させるのか?
      • 教育なども重要
      • データの分類と評価がまずは大事
    • 昨年、テレコム企業の課金システムのリプレイスを行なった
      • アーキテクチャの全面書き換えを行った
      • 保護されたAPIやデータへのアクセスをトークンを使って制御することにした
    • CCPAがあるけど、何かアドバイスは?
      • まずはデータを特定して分類するところから始めましょう
    • DIDについて
      • iPhone上のデータは誰の持ち物?Appleもデータのコントロールできちゃうよね
      • 個人データは借財。これは長くは続かない。DIDとかブロックチェーンが解決の糸口になるかもしれない
      • 5年から10年くらいはかかるかな
    • 今後我々はどんなテクノロジーをキャッチアップしていけばいい?
      • AI(プライバシーも考慮して)
      • FIDO2
      • コンテキストに合わせたユーザージャーニー(IEF)
      • マシンラーニング
      • Decentralized Identity

  • Blurring the boundaries between CIAM and IAM / Microsoft
    • アイデンティティはセキュリティの要である
    • 社内外とのコラボレーションのあり方の変化
      • B2Bシナリオ
        • パートナー側でアイデンティティを管理する
        • つまりBYOID
      • B2Cシナリオ
        • セルフサインアップ
        • 同じくBYOID
    • こうやってみるとB2BもB2Cも同じ
      • アカウントを作って
      • 承認して
      • アクセスできるようになる
    • 共通しているのは人を中心に据えていること
    • サンプルケース1
      • 個人が複数のロールを担うことがある(不動産のオーナーだったり、売主だったり、従業員だったり)
      • 一つのGoogleアカウントでサインアップ〜サインインする(Azure AD B2B)
      • システム側でロールを切り替えられるような実装をすることで、役割ごとにユーザアカウントを個別に作る必要がなくなる
    • サンプルケース2
      • 大学のケース
      • 入学希望して、受験生となって、学生になって、卒業生になって、大学院に入ってまた学生になって、学校に就職して職員となって。。というライフサイクル単位でアカウントを作るのではなく、一つのアカウントの状態を変えていく
    • 共通するのは、一つのアカウントを関係性に応じて変化させていく、という考え方

  • Identity Proofing - What Happens Before Authentication by Capital One
    • Identity Proofingとは
      • 個人に関する情報を集めて検証するプロセス
      • アカウントをオープンする時に実行したりする
      • 認証とは異なる
    • なぜIdentity Proofingが重要なのか
      • 認証して認可してシステムやデータへアクセスさせるが、そもそも「誰?」という部分を知らなければならないため
    • NIST SP800-63Aにおける定義
      • Resolution
      • Validation
      • Verification
    • Identity Assurance Levelとは
      • 検証に使うエビデンスと方法の品質
    • 企業におけるシナリオ
      • 雇用時
        • バックグラウンドチェック
        • 対面での書類確認
        • 初期クレデンシャルの発行
      • クレデンシャルのリカバリ時
        • パスワードレスのシナリオの場合
        • 免許証などのドキュメントをビデオ会議で見せて確認する
    • コンシューマの世界におけるIdentity Proofing
      • スピードと正確性とコストが大切
      • 時間がかかると顧客はドロップしてしまう
    • 色々な方法
      • モバイルデバイスを使った確認
        • SMSへのコード送信
      • ドキュメントを使った確認
        • 券面のスキャン、バーコードのスキャン
        • 券面のスキャンはPhotoShop対策も合わせて必要
    • リスクベースアプローチが必要
      • Identity ProofingはRiskスコアと同義でもある
    • まとめ
      • 一般的にユーザが提供したり手動で入力した個人データは不正確である
      • システム横断で使えるRiskスコアが必要
      • データソースを増やして、検証の精度を高めるためには外部ベンダーとの協業が必要である(Capital Oneとか)

  • Frictionless Identity Verification by ADP
    • ADP自体はセキュリティの会社ではなく、HCMの会社
    • 40Mくらいのアクティブユーザー数がある
    • 次のチャレンジはユーザエクスペリエンスの改善
    • 現状、ADPのサービスに従業員がセルフ登録する方法は以下の通り
      • Federated SSO
      • Personal Code
      • Company Code
      • Codeless Registration(モバイル向け)
    • これまでIdentity Assuranceを担保するためにやってきたこと
      • Bot Protection(ロボットよけ)
      • AIベースのアイデンティティ確認
      • 知識ベースの認証
      • デバイスベースのリスク管理
      • 外部ベンダとの協業(Capital One)
    • 登録時のユーザージャーニーを整理し、70%のコンバージョンを実現した

  • So You Think You Can Two Factor by Nishant
    • 多要素認証を使う時
      • PSD2など法令により必須な時
    • 認証要素は非常に多岐にわたっている
    • これらを単純に提供するのは説明書なしで家具を組み立てさせるようなもの
    • どのように利用させる要素を考えるか
      • ユーザが使いやすいもの
      • コスト
      • 対応する脅威モデル
      • 効果
      • 法令遵守
    • 生体認証はセキュリティではなく、利便性のためにある
    • 生体情報(いわゆる身体的な特徴情報)はすでに必須ではない
    • ユーザの行動、デバイスID(Fingerpirnt)を使ったアノマリ検知も可能(機械学習ベース)
    • ユーザへの浸透(使い慣れているものを使う)
      • Googleは7年前から2要素認証を提供しているが利用している人は10%程度だった
      • Yubikeyに対応したら登録者が増えた、なぜならYubikeyを使っている人が増えたから
      • ユーザはリスクを理解しているわけではない
      • Googleは2要素認証を強制はしていない。なぜならサービスを使わせたいから
    • オムニチャネルの検討
      • UX向上の別の例
      • コンタクトセンターでの認証をスマホで行う、などチャネルを分離することによるUX向上とセキュリティ向上の両方を実現
    • プロセス自体の検討
      • 付与
        • 第1要素を付与する時に同時に2要素目の登録を行う
        • 間が空くと弱いタイミングができてしまう
      • バックアップを取得する
      • 緊急避難のパスを作っておく
      • リカバリプロセスを作っておく(例えばSMSや免許証での検証など)
      • 第2要素の破棄の方法を考えておく
    • まとめると以下が大事
      • ちゃんと使えること
      • 複数の方法を用意しておくこと
      • ユーザが受け入れられること
      • オムニチャネルの検討
      • 管理プロセスの検討

  • Why Governments are still important even in a Self-Sovereign Context by Adam Cooper
    • 近い将来、デジタルアイデンティティが人々のプライマリのIDになったと仮定するとどうなるだろうか
    • 政府機関の役割
      • 法律を整備する
      • アイデンティティドキュメントを交付する
      • 住民登録データを記録・保管する
    • SSIやDIDのような新しい仕組みはそれらの役割を代替するものではなく、相互運用するものである
    • 実際にアイデンティティを使う際にはアイデンティティそのものよりも適格であるかどうかの方がはるかに大切である
      • 例えば、支払い能力はあるか、など
    • そうなると、政府機関の提供するアイデンティティはトラストの源泉としての役割を持つ
    • 個人は自身のアイデンティティを提示する際に、信頼できて検証可能であることを望む
    • つまり、ポータブルで信頼に裏打ちされた状態において、自身でアイデンティティの管理を行える状態が望ましい
    • 結局トラストフレームワークが鍵となる

  • Developing World Identity
    • パネルディスカッション
      • モデレーター:Jeremy Grant
      • パネリスト:Adam Cooper, Vyjayanti Desal, Kaliya Young
    • ID4Dの取り組みの紹介(World Bank)
      • LIC(Low Income Countries)にフォーカスしている
        • ペルー、インド、パキスタン、タイなどで活動
      • デジタルIDは全ての基盤となる
        • Financial Inclusion
        • Healthcare
        • Women's Empowerment
        • Social Protection
        • Education
      • 他にもペーパーレス・トランザクション(Paymentなど)を行う上でも必要なものである
      • ID4Dの3つのアプローチ
        • Thought Leadership & Analytics
        • Country & Regional Action
        • Global Platform & Convening
      • 啓発活動を含め各種ドキュメントの発行なども行なったり、原則をプラクティスへ落とし込む活動をしている
      • グローバルで一つの大きなIDシステムを作ろうとしているわけではなく、各国がオープンなIDシステムをもち、相互運用性を持てるような世界を目指していく
    • Aadhaarの話(Kaliya)
      • 2000年代初頭、IDシステムをどうやって変えていくか考えた
      • 国民を登録する台帳は存在、ローカルガバメントが誕生・死亡の登録を管理していた
      • Nandan Nilekani氏が閣僚となり、インドのユニークIDのオーソリティを作ることとなった
      • 最低限実行可能なID基盤として以下をもつ
        • 名前、生年月日、性別、住所
        • 生体情報(写真、2つの虹彩情報、10の指紋情報)
        • (ボーナス。必要か?)電話番号、メールアドレス、銀行口座情報
      • 登録時はセントラルレポジトリへデータが送られ、ユニーク性のチェック後、IDが発行され、カードが送付される(なんのセキュリティ機能もないカード)
      • Aadhaarを使った認証の方式
        • Aadhaar番号と名前、住所
        • Aadhaar番号と生体情報
        • Aadhaar番号とワンタイムパスワード
        • Aadhaar番号と多要素認証
        • (KYC時は)Aadhaar番号と生体情報+eKYCドキュメントの名前と住所
      • 問題点
        • 住民のゴールデンレコードができてしまう
        • セキュリティ保護されていないカードが存在する
        • 地方の支局に行くと生体情報の確認ができないことがある
        • ワンタイムパスワードを使おうとしても携帯電話番号を持っていない人がいる
      • 良い点
        • みんなが持っている
        • ユニバーサルである



と、本編はここまでです。
この後、イベントのFounderであるPing IdentityのCEO、Andre主催のパーティに参加してきました。Newseumという報道関係の博物館を貸し切っての大イベントでした。
ちなみにベルリンの壁とかがありました。
しかし何と言っても目玉はID厨だけで構成されているバンド、ZZAuthです。
メンバが以上に豪華です。Eve Malar, Justin Ritcher, Alex Weinert, Pamela Dingle, Sofia-Cristineなどなど・・・





ということでいよいよ次回は最終日です。

Identiverse 2019参加メモ(Day4)

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

いよいよ最終日です。
割と毎日みっちりとセッションを聞いたので、かなりの疲労度ですが何はともあれようやく最終日です。

初日から3日までの記録はこちらです。


本日は午前中にブレークアウトセッションやマスタークラス(ベンダーによる製品解説)があった後、お昼の時間帯にクロージングキーノートとして待ちに待ったSteve Wozniakの登場、というスケジュールです。

では、早速参加したセッションについてメモを記録しておきます。

◆ブレークアウトセッション・マスタークラス

  • Adventures in Self-Sovereign Identity: From Hyperledger Indy to W3C Verifiable Credentials by Workday
    • 実はDIFのメンバーになぜWorkdayがいるのか結構疑問だったので、このセッションには期待していました。結果非常に有益でした。
    • スピーカーはCSOの人で、ここ最近Self Sovereign Identityのリサーチを担当してきたとのこと
    • 昨年よりIBMと一緒にHyperledger IndyベースでPoCをやってきた
    • 本日はその結果をデモを交えて紹介してくれるとのこと
    • まずはお決まり通り、SSIで解決したいことの例
      • 成績の情報を大学が学生に付与
      • 学生は就職したい企業に成績情報を提示
      • 企業が内容の検証をする
    • このシナリオで確認に時間がかかったり、プライバシーの問題を抱えていたりする(例えば、2018年以降に卒業していることがわかれば良いので、実際の卒業年度がわかる必要がなかったり、成績の平均が3よりよければ良いので実際の細かい点数までは必要ないはず、という話。ゼロ知識証明ですね)
    • 昨年、IBM、Workday、Evernym、ATB Financialで実証実験を行った
    • 学生のシナリオ以外に、以下のシナリオを各役割を持って実行した(要はオンラインでのKYCと銀行口座の即時開設のシナリオです)
      • Workday:従業員証の発行
      • ADOT(アリゾナ州の交通局):免許証の発行
      • Evernym:Identity Walletの提供
      • ATB Financial:銀行口座の開設
      • IBM:Hyperledger周りのインフラの提供
    • 環境を設計するにあたり、色々と検討したこと(この辺りはかなり細かく資料では説明されていたので今後資料が公開されることがあれば是非見てみるべきだと思います。そのくらい参考になりました。写真は結構撮りましたが、今回はとりあえずのメモだけ記録しておきます)
      • 暗号アルゴリズムの選定
        • Ed25519:署名・署名検証に利用
        • Curve25519:Key Agreementに利用
      • 属性のブラインディング(匿名化)
      • ゼロ知識証明の利用
      • Walletとの接続の方式
      • Schemaの設計
      • Credentialsの設計
        • Pairwiseにできるかどうか、、など
    • デモ1
      • WorkDayに従業員がログイン、Walletを登録する(QR読み込み)
      • WorkDay側で従業員の証明情報(Verifiable Credentials)を発行すると、従業員のWalletにプッシュ通知がされ、Wallet上に情報が読み込まれる
      • ATB Onlineのサイトで口座開設プロセスをスタートすると、QRコードが表示されるため、Walletで読み込むと先に発行された従業員情報を送信して良いか確認が入り、利用者が送信する属性を選択して送信するとATB Online側の開設プロセスが始まる
      • ATB Online側の確認プロセスが終了すると、従業員のWalletに開設された口座番号の情報がプッシュ通知される
      • 従業員がATB Onlineへログインする際は、発行された口座番号をサブミットするとWalletへ通知がくるので、承認するとログインが完了する(パスワードを登録していないので、完全にパスワードレスでのログインが実行される)
    • デモ2
      • 郵便局で検証済みの住所情報をWalletへ発行する
      • アイスクリーム屋さんのキャンペーンサイトで特定の住所に住んでいることが確認できれば無料でアイスクリームがもらえるクーポンが発行される
      • 利用者がアイスクリーム屋さんのWebサイトに表示されるQRコードをWalletで読み取り、郵便局で発行された検証済み住所を提示するとクーポンのバーコードが発行される
    • これらのシナリオをHyperledgeIndyと、素のW3CのVerifiable Credentialsを使って検証をしてPros/Consを出してみた。
    • まずはHyperledgerIndy
      • Pros
        • デフォルトでPairwiseなDIDが発行されるのでVerifier(RP)側での名寄せの心配がない
        • ゼロ知識証明をサポートしている
        • エコシステムが存在する(Ledger、Wallet、プロトコル)
        • 相互運用性の実験を行うプロジェクト(Project Aries)も存在する
        • PIIはLedger上には載らない
      • Cons
        • 暗号が難しいのでプロにしか良さがわからない(顧客や監査人への説明が難しい)
        • プロジェクトが同時並行して動いているのでパーツ単位で成熟度が異なる
        • プロトコルがLedgerと密接に紐づいている(今の所)
    • 次にW3C Credentials
      • Pros
        • 暗号モデルがシンプル
        • 相互運用性が高い
        • Ledgerの種類に依存しない
        • PIIはLedger上には載らない
      • Cons
        • DIDがPairwiseではないため名寄せが出来てしまう(注釈:実装の仕方次第だと思いますが)
        • Verifiable Credentialsのフォーマットは標準化されているが、伝搬のためのプロトコルは標準化されていない
        • 標準が最終化されていない
        • 標準がオープンすぎる。JSON-LD vs JSON vs JWT
    • プロジェクトから学んだこと
      • W3Cの方が開発しやすい(開発者にとって開発しやすい)
      • 標準仕様を見て素で開発するか、OSSのプロジェクトを使って開発するか考えないといけない
      • 何よりもSovrin/HyperledgerIndyが動いた
        • PoCではRevocationのシナリオはやらなかったのでその部分は注意
    • このテクノロジーに感じるポテンシャル
      • パスワードレス・ログインにも使える(強固な認証をスケーラブルに実装できる可能性がある)
      • この方式が標準として普及していくといいかも(SAMLみたいに)
    • その他

  • Auth0 Masterclass: Identity and the Yellow Brick Road - The Last Few Steps Are Always the Hardest by Vittorio Bertocci
    • クロージング・キーノート前最後のセッションはやはりVittorioのセッションで締めておこうと思います。
    • どういう状態がID基盤の理想の状態なのか?
      • 色々なプロトコルのアプリケーションやAPIに対応している
      • 色々なプロトコルのデータソースやディレクトリに対応している
      • 色々なデバイス(ブラウザ、モバイル、デスクトップアプリ)に対応している
    • 多くの場合、暗黙の前提事項がある
      • Identity Provider
        • サポートされること
        • IDaaSが対応しているプロトコルの一つに対応している
        • 移行できること
      • 認証ロジック
        • 標準に置き換えが可能である
        • そのまま(Out-of-box)で使える
        • 過去のIDとクレデンシャルがそのまま使える
      • 認可
        • 見たものが全て、つまり今のままの権限を移行できる
    • 簡単に使えるのか、色々と出来るのか、という軸で4象限で表すと、壁に突き当たる
      • デプロイの壁(自前のデプロイの限界地点。スケーラビリティとか)
        • ゼロから作るよりはSDKを使った方が簡単になるが、出来ることは減る
        • SDKより製品を使えば簡単になるが、出来ることは更に減る
        • どんなに頑張っても自前でデプロイするには専業クラウドを超えられない地点がある(コストが無限にあれば別だが)
      • コードの壁(汎用サービスではどうしても実現できない限界地点)
        • SaaS(IDaaSを含む)を使えば簡単に使えるがカスタマイズの自由度はほとんどない
        • PaaSなどに落とし込んでいけばカスタマイズの自由度はある程度上がるが難しくなってくる
        • いずれは自前でコードを書かないとなんともならない限界点に突き当たる
    • この問題へのある程度の答えが拡張可能なIDaaSである
    • 順に導入時の課題へのAuth0での対応を見ていく
      • Identity Source
        • 標準でサポートしていないIdPとの接続
          • 最近リリース(ベータ)された汎用OIDC接続を使う
        • 標準に対応していないIdPとの接続(Apple IDとか)
          • Extensionで接続する
        • 移行できないDBとの接続
          • カスタムDB接続を使う(無理に移行せずに、一旦は繋いでしまって時期を待つ)
      • UXのカスタマイズ
        • https://flows.auth0.comで簡単に画面デザインが出来る
        • 会社名を入れて検索すると勝手に会社のロゴをとってきてセットしてくれたりする
      • ユーザーライフサイクル
        • Pre-Signup、Post-SignupのルールをJavaScriptで拡張できるので、例えばIdentity Verificationを挟んだり、と色々と出来る
        • 追加の属性を他のDBからとってきたりも可能
        • 同意をとったり、外部のページへ飛ばすことも可能

ちなみにTシャツとダイアグラムの書かれた画用紙を貰いました

◆クロージング・キーノート

いよいよクロージングです。会場となるBall Roomが開くのを大勢の参加者が扉の前に押し寄せて待っています。

開場とともに人の群が良い席を求めて雪崩れ込んでいくのは圧巻でした。やはり参加者の一番の期待はSteve Wozniakですね。あっという間に会場は満席に。最終日の最後のセッションまでこんなに熱気があるカンファレンスも滅多にないんじゃないでしょうか?

会場から開演まで20分程度の間があったのですが、その間Electricヴァイオリンのライブ演奏がステージでは行われていました。Mark Woodの使っているような楽器を使っていて非常にかっこよかったです。ちなみにElectricヴァイオリンってフレットが付いているギターとヴァイオリンの合いの子みたいなモデルと、フレットレスのヴァイオリンをそのまま電子楽器にしたモデルがあるのですが、今回の方は前者のモデルをお使いでした。私も最近ヴァイオリンを弾くので、久しぶりにMark Woodを聴きたくなりました&楽器が欲しくなりましたw

さて、ようやく開演です。

Andre DurandのリードでSteve Wozniakがステージに登場すると会場は大盛り上がりです。


ステージはAndreとSteveの対談形式なので、正直なところ話の内容は拾いきれていませんが、いちいちジョークを挟みながらAndreの色々な問いに答えていくので、会場は度々爆笑の渦、でした。(付いていけない部分が多々ありましたが。名刺でステーキを切った?エピソードとか)


細かい内容は動画が公開されれば皆さんでも見ることも可能だと思いますし、私も追いきれなかったのでその時に改めて確認しようと思いますが、何点か重要だな、と思った点のみを。(かつ聞き取れた部分)
  • 注目しているテクノロジーは?AIとか。
    • 我々は脳がどのようになっているのかも分かっていないし、記憶がどこにストアされているのかすらも分かっていない
    • そんな状態なので、AIはインテリジェンスを持っていないし、シンギュラリティにはなり得ない
    • Googleは人間よりも犬の画像を認識するのは得意かもしれないが、犬が何であるかを知っているわけではない
    • 人間の脳は機械よりも優れているので、まだ存在しないものを想像して創造することが大切
  • Appleの起こしたInnovationでもっとも大切だったものは
    • iPhoneではない
    • Appストアでサードパーティにマーケットを解放したことである
    • それがなければ今、我々はUberやLyftを使うことができていないはずである
  • Blockchainベースのアイデンティティについてどう思うか?
    • 我々の日々の行動を政府がトラッキング可能で利用可能な状態であること、に対して、ブロックチェーンを導入すればこれ以上データを取得されなくなる、というのはブロックチェーンを正当化する理由にはならないと思う



そして、来年の開催地は「デンバー」です!
非常に楽しみです!




ということで、4日間に渡ってお伝えしてきた日記もおしまいです。

ちなみに午後はペンタゴンの側のショッピングモールに行ってきました。屋上からペンタゴンが見えたので写真を撮りましたが上空から取らないとなんだかわかりませんね。。。


MVP Renewal 10th!!

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

遂に10年目に突入してしまいました。
今年もEnterprise Mobilityの領域で受賞いたしました。

昨年からLINE API Expert、Auth0 Ambassadorとの平行、かつOpenIDファウンデーション・ジャパンでは理事を拝命した中での活動となっており、色々な場面で登壇させていただくことは増えた一方でBlogなどの書き物としてのアウトプットをする体力が残っていない状態が続いていますが、e-KYCや信用スコアなどビジネス面での新しい潮流や、DID・自己主権型アイデンティティなど新しい技術への注目が集まるなど、まだまだアイデンティティの分野ではやることが山積されている状態なので、引き続き活動をしていきたいと思います。

ということで、今後ともよろしくお願いいたします。

Auth0がLINE Loginに対応しました

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

先日のCEO訪日もあり色々と盛り上がっているAuth0ですが、訪日時にCEOが宣言した通り、LINE Loginに対応しました。

これまでカスタムコネクタで設定していましたが、これからはスイッチONしてclient設定をすれば使えるようになります。便利です。

ちなみに過去に投稿したカスタムコネクタでの設定方法はこちらです。
 https://idmlab.eidentity.jp/2019/01/auth0line.html


設定は非常に簡単なので解説するまでもありませんが、ざっくりと。


ConnectionsからSocialを開くとLINEのアイコンがありますのでクリックすると設定画面が開きます。



LINEの管理コンソールからChannel ID(=client_id)、Channel Secret(=client_secret)を取ってきます

Auth0側の設定画面に取得したclient_idとclient_secretを設定します

ちなみに、LINEからメールアドレスを取得したい場合は、Auth0の画面でEmail addressの項目にチェックを入れ、かつLINE管理コンソール側のOpenID Connect設定でemail属性を取得できるように申請、承認される必要があります。(私はすぐに承認されました。皆さんがすぐに申請されるものかどうかはわかりませんが)
ここまで設定すればAuth0側はおしまいですが、LINE管理コンソール側にCallback URL(redirect_uri)を設定しておく必要があります。設定するのは、「https://{テナント名}.auth0.com/login/callback」です。
ちなみに、LINE側で良くハマるのが、チャネルを作って設定したのに公開していない、というケースなので、上の図の右上の公開/非公開の部分が公開済み(Published)になっていることを確認しておいてください。


これですべて終了です。
Auth0で「try」をクリックするとLINEログイン(初回は属性提供のための認可画面)が出てきて、認可を行うとログインができます。

尚、その後メールアドレスの確認のためのメールが届きますので、VerifyをクリックするとAuth0上のメールアドレスについても確認済みのフラグが付きます。

ちなみにLINE Loginのクセなのですが、メールアドレスはid_tokenから、その他の属性はprofileエンドポイントから取得するのでAuth0のクセとの相性的に「try」の結果のjsonにはメールアドレスが載ってきません。


Auth0上に登録されたすべての属性を見たければユーザを開いて、Raw Jsonを見るとどんな属性が登録されているかがわかります。

メールアドレスもちゃんと取れてますし、うまく動いていそうです。
(実はクローズドベータの時はメールアドレスがうまくとれてなかったんです・・・)

iOS13でSign in with Appleがようやく使い物になってきた

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

色々と騒動もあってついつい忘れがちなSign in with Appleですが、先週iOS13が正式に出てきてようやく使い物になってきました。
iPhone11は・・・ボトムズですよね。買ってません。

Sign in with Appleとは

いわゆるAppleのOpenID Connect実装です。iPhoneやMacを持っている人は必ず持っているApple Idを使って自前WebサイトなどへOpenID Connectを使ってログイン出来るようになります。
6月のWWDCで発表されて結構盛り上がりました。と、どうじにOpenID Connectの実装内容についても色々と意見がついてプチ炎上?してました。最近まともになっているようですが。
私もAzure AD B2CやAuth0へ組み込んでみたりしました。

 Azure AD B2Cへの実装
  https://idmlab.eidentity.jp/2019/06/sign-in-with-appleid-ad-b2c.html
 Auth0への実装
  https://idmlab.eidentity.jp/2019/06/sign-in-with-appleidaasauth0.html

8月頭には idcon でSign in with Apple特集も開催され一瞬で定員をオーバーするなど、注目度も結構高かった記憶があります。

iOS13未満の環境での課題

Sign in with Appleが発表された当時、まだiOS13はβ版でしたので人柱になっている人たち以外の一般人はあまり恩恵を受けられませんでした。
と、言うのもSign in with Appleでログインを行う都度、メールアドレス+パスワードの入力に加えてiPhoneへワンタイムコードが飛んでくる、という実装で、せっかく同じApple IdでログインしているiPhoneやiPadでも再度認証が要求されていたためです。

こんなUXでした。

iOS13からのUX

OSに統合されたのでTouch IDやFace IDでそのままログイン出来るようになりました。
素晴らしい!


日本人はiPhoneが大好きなので各種WebサイトのSign in with Apple対応も今後進んでくると思います。(みんながiOS13以上になるのがいつか?という話はありますが)

Consumer Identity World USA 2019に登場します

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

今週からシアトル~サンフランシスコ(というかマウンテンビュー周辺)です。

今回は9/25~27にシアトルで開催されるCIW(Consumer Identity World) USA 2019でお話し、その足で翌週マウンテンビューのComputer History Museumで開催されるIIW(Internet Identity Workshop)に顔を出してきます。

最近の私の個人的テーマがBYOID(Bring Own Your Identity/自前のIDの持ち込み)とDID(Decentralized Identity/分散台帳上でのIdentity)でして、最近の各種カンファレンスでも色々とお話させていただいていますが今回もその一環です。

最近はこのようなカンファレンスだけではなく実際の商談でも色々と手を変え品を変えてこの世界観の定着を試みているんですが、まだまだ浸透してくるのは先のような気がしています。パスワードレスのような利便性の話や、eKYCなどアイデンティティの真正性の証明など色々と違った切り口で有用性もあると思うので、引き続き啓発活動が必要ですね。


さて今回ですが、B2B/B2Cなど外部IDの管理の面倒臭さBYPODとeKYCで簡素化する方法の案についてお話させていただきます。


概要は以下のような感じで、Azure AD B2CとuPortを使ったB2Bシナリオで社員証を使った身元確認によりパートナー向けWebサイトへのID登録のBYOID化、というデモもお見せできればと思います。

タイトル:
 Boost your B2B/B2C scenario with BYOID + eKYC using Decentralized Identity
概要:
 Managing external accounts such as suppliers in B2B or consumer account is painful problem for IT administrators. In this presentation, I'll show you our scenario and demo to make it easy to manage external identities powered by BYOID + eKYC. e.g. Sign-up social media account and proof their identity using driver's license as verifiable credentials in the identity wallet.

 Key takeaways:

  1. Best practice of managing external identity on supply chain management scenario with BYOID+eKYC approach.
  2. How the Decentralized Identity approach is used in eKYC process.
  3. Implementation details of the scenario, Azure AD B2C, uPort.


また、唐突に主催のKuppingerColeからアサインされたんですが、パネルディスカッションにも参加する予定です。
最近の自己主権型アイデンティティやDID周りで色々と情報交換をさせて頂いていて今回CIWのKeynoteも担当されるKristina Yasudaさんと一緒です。
プレゼンはナントカ乗り切るだけの「慣れ」という名の精神力(英語力ではない)は身についてきましたがパネルは何が出るかわからないのでかなりビビってます。最後の手段はKristinaに通訳してもらうか・・・w


帰国後も登壇続きなので、その準備をしつつ商談もこなしつつというハードコア出張に今回はなりそうですが、新しいネタを色々と仕入れてこれそうなので可能な限りレポートしていこうと思います!

Azure AD B2Cのリージョンに日本が選択できるようになりました

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

ずっと日本リージョンが選択できなかったAzure Active Directory B2C(Azure AD B2C)ですが、いつの間にか?(9月末~?)日本リージョンの選択が出来るようになっています。といってもデータの保管場所はAPACということですが。

むしろ大ニュースなのはこれまでデータの保管場所がEUとUSしかなかったのにAPACが追加されたことかもしれません。

・・・実はPrivate Previewがあったことは知ってたんですが、今回の突然のGAは全然アナウンスされてないのは何故なんだろうかという疑問が。。(2019/10/08時点)

※オフィシャルリリースがされていない以上、消える可能性はあります。現時点での利用は自己責任にて。

◆これまでの問題点とFeedback

Azure AD B2C自体はリージョンに依存しないサービスなので全リージョンでエンドポイントは使えましたが、データの実体の保管場所がEUとUSしか選べなかったので、個人データの保管場所を気にする業種・業界においてはブロック要素となってきました。(AWS Cognitoは日本にもデータを置けますし、Auth0には最後の手段カスタムデプロイプランがあったりするので無理やり日本にデプロイできたりしました)

過去から日本マイクロソフトの人を含めフィードバックはあげてきましたが中国が優先されてしまい、先に中国がPreviewとしてリリースされてしまっていました。

2019/05/06 中国におけるAzure Active Directory B2C
https://azure.microsoft.com/ja-jp/updates/azure-active-directory-b2c-in-china/

涙ぐましいフィードバック
https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/20208730-add-japan-region-to-data-residency-location-of-azu
⇒Unplannedという悲しい状態のまま放置されています

◆これまでの回避手段

データの保管場所の問題はもちろん日本だけの話ではなく、特に政府・行政系のシステムにAzure AD B2Cを採用するケースではディレクトリ上にはPII(個人情報)を置かずにREST API連携などを使って他のデータベースに逃がす、などの手段が取られてきました。
ただ、全体としての可用性を担保しようとするとそれなりにお金がかかったり、カスタムデプロイとなるのでメンテナンスが面倒くさい、といった問題が残るためいわば最後の手段でした。

◆今回のリリース(?)の内容

ひっそりドキュメントが更新されています。

https://docs.microsoft.com/ja-jp/azure/active-directory-b2c/active-directory-b2c-reference-tenant-type

日本を選択するとデータはアジア太平洋に保存される、と明記されています。

実際にディレクトリを作るとき、リージョンに日本の選択が出来るようになっています。


作成するとasiapasificに配置されます。


とりあえずはアナウンス待ちですね。

Ignite Tour TokyoでAzure AD B2C + SSI/DIDの話をします

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

あっという間に11月も終わりですね・・・

なんだか最近、月に2~3本の勢いでイベントでお話をしている気がします。おかげで色々と実験はしているもののBlogへのアウトプットが後手後手に回ってしまっていて反省です。

まぁ、その分講演の中では実験した内容を含めじっくりお話させていただいているつもりなので、是非機会があれば見に来ていただければ、ということで。

ということで、あっという間に来週の開催になってしまいましたが、12/5~6にIgnite Tour Tokyoがあり、こちらでAzure AD B2C + SSI/DIDの話をすることになっています。
基本的には前のde:codeEuropean Identity & Cloud ConferenceConsumer Identity World USAでお話してきた内容の続きではありますが、この自己主権型アイデンティティや分権型IDってキーワードが全くもってキャッチーじゃないので、地道に世界観を浸透させていくしかないのかな?と思っています。

ということでIgnite Tour Tokyoでは「分権型IDテクノロジーによる効率的な外部ユーザのID管理」というタイトルで「B2BやB2Cのシナリオにおいて外部アイデンティティの管理、特にIDの確認(KYCなど)は管理者にとって非常に頭の痛い問題です。本セッションではそれらの問題をAzure AD B2Cとブロックチェーンを使った自己主権型アイデンティティのシナリオでどのように解決するのかについて説明します。」という話をする予定です。

セッションコード:BRK30053
セッションURLはこちら)
https://tokyo.myignitetour.techcommunity.microsoft.com/sessions/87724


絶賛、過去のスライドをかき集めて準備中ですw

ベースはこの辺りなので、事前に目を通しておいていただけると理解がはやいかも。
de:codeの資料
 https://www.slideshare.net/naohiro.fujie/kyc-identity-on-blockchain
OSSコンソーシアムの資料
 https://www.slideshare.net/naohiro.fujie/kyc-153297605
didconの資料
 https://www.slideshare.net/naohiro.fujie/ssidid


では、当日お会いしましょう。

Hyperledger Indy, Ursa, Ariesのオンラインコースで自己主権型アイデンティティについて学習する

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

先日開催されたW3C/TPAC@福岡でDID WGが正式に発足したり、DIFやSovrin Foundationが活発に活動していたり、と自己主権型アイデンティティ(Self Sovereign Identity/SSI)や分散型アイデンティティ(Decentralized Identifier/DID)のムーブメントも本格化してきましたね。

そういえば@IdentityWomanことKaliya姉さんがおそらく世界初のSSIの本「A Comprehensive Guide to Self Sovereign Identity」を出版したのも今年の4月だったのでまだ半年ちょっとしか経ってないんですよね。


そんな中、元々Evernym~Sovrin Foundationが開発してきたSSIのための分散台帳技術でLinux Foundationの進めるHyperledgerプロジェクトの一員となったHyperledger Indyや、Wallet間のPeer to peer通信のプロトコルの標準化を進めようとしているHyperledger Aries、暗号化ライブラリであるHyperledger UrsaのオンラインのトレーニングコースがedXで公開されました。
※日本語記事あり:https://crypto.watch.impress.co.jp/docs/news/1220/815/index.html

HyperledgerファミリーとIndy, Ursa, Aries(出典:Evernym)

ざっくりいうと、Indyが分散台帳技術そのものであるのに対して、UrsaはZKP(ゼロ知識証明)などに使う暗号化技術、AriesはWalletやAgent間の通信に関する技術、という整理っぽいですね。(私もまだ勉強中なので間違っていたらすみません)

IndyとAriesの関係の整理(出典:Evernym)



ということで、もう少し深く勉強してみるいい機会なのでコースを受講してみようと思います。(せっかくなので受講証明がもらえる有料コース/99USドルにしました。12/2までならクーポンコード「CYBER20」を入れると20ドルくらい割引になります)

以下、コース登録までの道のりです。(実際の内容はこれからなので、また気づきがあれば書こうと思います)

1.edXのコースサイトを開く

こちらが今回のターゲットとなるコースのURLです。
https://www.edx.org/course/identity-in-hyperledger-aries-indy-and-ursa


ここからEnrollを押してスタートしていきます。

2.会員登録を行う

メールアドレスで登録するか、Facebook、Google、Microsoftアカウントでアカウントを作成します。


作成が終わると、有料会員に誘われますw。せっかくなのでお金を払ってみようと思います。

3.有料会員登録を行う

会員登録後、誘われるがままに登録をしてみます。

どうやら有料登録をすると色々と特典があるようです。(最後のは特典なのか?)

  • Unlimited Course Access
  • Graded Assignments
  • Easily Sharable
  • Support our Mission
「Pursue the Verified Track」で迷わず購入へ進めましょう。

左の中央に「Add coupon code」があるので先ほどの「CYBER20」を登録すると20ドルくらい安くなります。(12/2までらしいですが)
クレジットカードがPayPalで支払えますが、私はPayPalで支払いました。

購入が終わると登録者の本人確認が行われます。

4.本人確認を行う(eKYC!!)

方法としてはWebカメラで顔とIDドキュメント(パスポートや免許証など。名前と顔写真が一致していることを見るっぽいので、実質日本人で使えるのはパスポートだけだと思いますが)の写真を撮り1日~2日くらい審査があるようです。


まずは顔写真を撮ります。(黒線は筆者都合w)

次にパスポートの写真を撮ります。

両方揃えてアップロードして審査待ちです。



5.コースの受講を開始する

とりあえず登録はこれで終わりなので、ゆっくりコースを受講していきます。


コース目次は以下の通りです。ゆっくり学習していこうかと。

  • Welcome!
  • Chapter 1: Something Is Missing
  • Chapter 2: Adding a Layer of Trust to the Internet
  • Chapter 3: SSI Using Indy, Aries and Ursa
  • Chapter 4: A Blockchain for Identity
  • Chapter 5: The All-Important Agent, Or Rather, Agents!
  • Chapter 6: When Things Go Wrong
  • Chapter 7: Possibilities
  • Final Exam

なかなか興味深いです。





年忘れはFIDOで!指紋認証付きのeWBM Goldengateを試す

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

世の中は大晦日ですが、今日になってeWBMさんよりGoldengate G310が届いたので軽く試してみます。

届いたのは、G310というFIDO2対応のキーです。
https://www.ewbm.com/security-keys/goldengate-g310/



韓国から直送で送られてきたっぽいです。
まだ日本のAmazonでは買えないので、直販サイトか米国Amazonで買うのがいいみたいです。
 直販サイト
  https://www.ewbm.com/store/products/goldengate-g310/
 米国Amazon
  https://www.amazon.com/s?k=ewbm+g310&ref=nb_sb_noss_2

定価は60ドルですが、直販サイトだと初回は45ドルで買えるみたいです。
(私はMVPのサードパーティ特典で頂きました)


なんだかキーばっかり増えちゃって微妙な感じですが、Yubikeyとの大きな違いは指紋認証機能があることですね。
キーだらけ・・・


やれることは正直他のFIDO2対応のキーと変わらないので、今更動きについて解説する必要もないと思いますので、先日のAXIES(大学ICT推進協議会)の年次大会でお見せしたG SuiteへAzure AD B2C+FIDO実装を使ってパスワードレスでログインするデモを張っておきます。



最大の特徴の指紋登録ですが、以下の2通りの方法で設定できます。
1.公式のツール「Goldengate BioManager」を使う
2.Windowsのアカウント設定を使う

それぞれ簡単に。
まずは公式ツール「Goldengate BioManager」を使う方式から。

ツールはこの辺りからダウンロードできます。
 https://www.ewbm.com/support/BioManager/

ちなみにダウンロードしてセットアップしようとするとWindowsに実行をブロックされますが無視して進めます・・・

セットアップが終わりツールを起動するとこんな画面が出てきます。
言語の切り替えもできて、日本語も選べます。


次は指紋の登録です。

指紋追加を選ぶとタッチする様に促されるのでベタベタ触ります。


登録が終わると、登録済みの指紋以外でタッチしてもキーが反応しなくなります。
あと、PINが聞かれなくなります。
※指紋登録していない状態だと単純にタッチ+PINだけでサインインできる(Yubikeyと同じ挙動)が、指紋登録をすると登録していない指だとサインインできない。


ちなみに、2つ目の登録手段であるWindowsの標準の設定です。
設定⇒アカウントのセットアップから登録できます。

ちなみにWindows Helloの設定も同じ設定メニュー内にありますが、あくまでセキュリティキーの設定なのでここでセットアップしてもセキュリティキーでWindowsログインが出来るようになるわけではありません。もしOSログインにも使いたければ使うアカウントの設定をMicrosoftアカウントなりAzure ADアカウントなりで設定する必要があります。

指紋の追加は先ほどのBioManagerとほぼ同じです。




セキュリティキー+PINだけでは不安な方は指紋認証機能も付いているGoldengateも一つの選択肢となりえますね!

eKYCとOpenID Connectに関する最近のアクティビティ

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

年明けから異常な忙しさでほぼ4か月ぶりの投稿になってしまいました。

今日はOpenID Foundationが今年から本格的に仕様化を進めているeKYC、ID保証に関する新しい仕様である「OpenID Connect for Identity Assurance」について紹介したいと思います。
ワーキンググループが始まったころは、ここまでリモートワークや非対面が重要になる、という局面を誰も予測していませんでしたが、ここに来てオンラインでのID保証、eKYCに関するニーズが本格化しているのは恐ろしい偶然としか言いようがありません。

尚、この「OpenID Connect for Identity Assurance」は、ちょうど1年程前から私もOpenIDファウンデーションジャパンのKYCワーキンググループをリードさせていただいている関係で共同議長を務めさせていただいている、米国OpenID FoundationのeKYC and Identity Assurance Working Groupで仕様策定が進められています。

ID保証(Identity Assurance)とは?

アイデンティティ管理に必ず付いて回るのが、デジタル・アイデンティティの精度や鮮度をはじめとする「信頼性」の課題です。

例えば、エンタープライズのシナリオでは、そのアカウントの持ち主はまだ在籍しているのか、権限付与に使っている役職は正確なのか?などといった「アイデンティティ・ライフサイクル」を管理するためにMicrosoft Identity ManagerやLDAP Managerなどの製品を使って効率的かつ正確なアイデンティティ管理を行います。

また、コンシューマのシナリオではいわゆる「KYC:Know Your Customer」といわれるID保証に関する課題を常に抱えています。これは例えば、サービスの利用を開始する際に登録する氏名や住所、年齢などの属性が本当に正しいのか?という「本人確認」や「身元確認」と言われる課題で、サービスの種類によっては利用者が一定の年齢を超えていることが法令で決められていたり、サービスの利用を許可するために必要な収入や本人到達性などの要件を満たす必要があったりするケースにおいては非常に重要なID保証のユースケースの一つです。例えば、金融機関におけるAML(Anti Money Laundering:マネーロンダリング防止)やオンラインゲーム等における年齢制限などがユースケースとして該当しますね。


ちなみにIDに関する保証レベルを綺麗に体系化しているのが「NIST(米国国立標準技術研究所)」が発行しているセキュリティに関するガイドラインシリーズ(SP/Special Publications)の800-63です。※通称NIST SP800-63
尚、NIST SP800-63は連邦政府内の情報保護の要件を規定している「NIST SP800-53」の中のデジタル・アイデンティティに関するガイドラインとして位置付けられていますが、連邦政府と取引をする民間企業を対象としてNIST SP800-53から抜き出す形で定義された「NIST SP800-171」にも同様に適用されることなどから、実質的にデジタル・アイデンティティの保証に関するデファクトスタンダードとなっています。

脱線を続けますが、NIST SP800-63では以下の3つの区分でID保証に関する規定をしています。

  • Identity Assurance Level(IAL):NIST SP800-63A
    • ID登録を行う時の本人確認・身元確認の強度(自己申告<非対面<対面など)
  • Authenticator Assurance Level(AAL):NIST SP800-63B
    • 認証器の強度(単要素<ソフトウェアベースの多要素<ハードウェアベース多要素など)
  • Federation Assurance Level(FAL):NIST SP800-63C
    • アサーション保護の強度(Bearer+署名<Bearer+署名+暗号化<HoK+署名+暗号化など)

各ガイドラインの日本語訳をOpenIDファウンデーション・ジャパンが公開しているので、興味のある方は参考にしてください。
https://openid-foundation-japan.github.io/800-63-3-final/index.ja.html


このように単にアイデンティティに関する「保証」といっても多岐にわたって考慮すべき点があります。


OpenIDファウンデーションジャパンにおける活動

冒頭で述べた通り、OpenIDファウンデーションジャパンにおいても先に述べた「KYC」に関するワーキンググループを2019年1月より設置し活動をしています。

このワーキンググループではOpenID Connectの仕様の拡張などといった単純に技術にフォーカスしたワーキングではなく、日本国内の各種業界(金融、テレコム、古物など)におけるID保証、本人確認に関する現状の調査、および現在業界毎に分断されている本人確認に関する要件の共通化に向けた課題の洗い出しなどポリシー面からの整理や、OpenID Connect for Identity Assuranceの仕様への国内事情のインプット、分散台帳を活用したアイデンティティの保証として注目されている「DID:Decentralized Identifier」や「VC:Verifiable Credentials」といった新しい技術の調査も、NFCリーダを使った公的証明書のICチップ読み取りや画像認識などeKYCに関連する技術に関しても網羅的に調査を行っています。

現在、ワーキンググループは第1シーズンの活動を終え、第2シーズンの活動を開始したところですので、興味のある方はこの機会にOpenIDファウンデーションジャパンへの入会とワーキンググループへの参画をご検討ください。

尚、第1シーズンの活動実績と成果物については2020年1月に開催された「OpenID Summit Tokyo」の中で発表させていただきましたので、詳しくは発表資料・成果物をご覧ください。



米OpenID Foundationにおける活動

ようやくOpenID Connectの仕様の話です。米OpenID Foundationでは2020年1月より「eKYC and Identity Assurance Working Group」という新しいワーキンググループを立ち上げ、ID保証に関するOpenID Connectの新しい仕様である「OpenID Connect for Identity Assurance(通称OIDC4IDA)」の策定を進めています。尚、先に述べた通り、OpenIDファウンデーションジャパンでKYCワーキンググループをリードさせていただいている縁もあり、こちらのワーキンググループでは議長であるDr. Torste Lodderstedtの元、Mark Haine, Anthony Nadalinと共に共同議長を務めさせていただいております。

どのような仕様か

Abstractに記載されているとおり、本仕様は「OpenID Providerがエンドユーザに関する検証済みの属性をRelying Partyに対して提供するためのOpenID Connectの拡張」であり、「特定の法律に基づき自然人のアイデンティティを検証するために利用されることを意図して」定義されています。
This specification defines an extension of OpenID Connect for providing Relying Parties with verified Claims about End-Users. This extension is intended to be used to verify the identity of a natural person in compliance with a certain law.

簡単に言うと、OpenID Providerに登録されているアイデンティティが何に基づき、どのように検証されたものか?というメタデータを含めてRelying Partyに対して提供することにより、アプリケーション側が安心してサービスを提供することが出来るようにすることを目指しています。

例えば、ial_exmample_goldというトラストフレームワークに則って確認済みのgiven_nameとfamily_name属性の値である、ということをRelying Partyに伝達する時、id_tokenやuserInfoエンドポイントから以下のような形でverified_claimsとしてJSONが返却されます。
{
"verified_claims":{
"verification":{
"trust_framework":"ial_example_gold"
},
"claims":{
"given_name":"Max",
"family_name":"Meier"
}
}
}

細かい技術面での解説はAuthleteの川崎さんが解説してくれていますし、少し前のDraftですが仕様の日本語化もされていますので、そちらをご覧いただければと思います。



仕様の現状

現在、本仕様は2nd Implementer's draftのレビュー期間が終わり、仕様の承認に関する投票が開始されています。
https://openid.net/2020/04/27/notice-of-vote-for-second-implementers-draft-of-openid-connect-for-identity-assurance-specification/

こちらも興味があれば米国OpenID Foundationの会員(個人でもなれます)として加入していただき、仕様策定にコントリビュートしていただければと思います。
(意外と日本人もいますよ!)




Azure ADの外部コラボレーションとBYOID

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

リモートワークで組織外の方々とのコラボレーションが大きなテーマになっている方々も多いと思いますが、そういう時はAzure ADの外部連携(B2B)の機能ですよね。

そう言えばAzure ADのDirect FederationがGoogle以外にもSAML/ws-federationの外部IdPをサポートした、という会話をfacebookで某安納さんがしていたのを思い出したのと、先日 Alex Simons が色々と新しい機能が出たよ、というもはや個別の機能リリースの紹介だと無理だから一気にまとめて発表、みたいなポストをしていた中に、Azure AD B2CのSAMLサポートが正式リリースされた、という話があったので、もしやこれは繋がる???ということでやってみました。
いわゆるBYOD(Bring Your Own Identity)ってやつです。

当然、Azure ADのカスタムドメインを使った外部ID連携でも良いわけですが、この辺は後で比較をしてきます。


まず関連する記事、ドキュメント類を。


とりあえず完成イメージを

言葉で説明しても伝わりにくいと思うので、どういうことが出来るようになるのか?を動画にしています。
Azure AD B2Bで招待した外部ユーザでログインしようとすると、Azure AD B2Cにリダイレクトされ、LINEでログインすると、Azure ADにゲストユーザとして登録されてアプリケーションが使えるようになる、というシナリオです。


Azure AD B2CのSAMLサポート

先に書いた公式ドキュメント通りに設定していくと、Azure AD B2CがSAML IdPとして動作出来るようになります。(カスタムポリシーを使います。慣れると非常に簡単です)

大きな流れは以下の通りです。

Azure AD B2C側の設定
  • アサーション署名用の証明書(PFX)を作ってポリシーキーとしてアップロードする
  • ClaimsProviderとして、SAML2AssertionIssuerを作成する
    • MetadataにIssuerUriとして設定したものがIdPのEntityIDになります
    • CryptographicKeysに先にアップロードした証明書コンテナを指定するとアサーション署名をしてくれます(暗号化用証明書もアップロードすれば暗号化もできます)
こんな感じの設定になります。
<ClaimsProvider>
<DisplayName>Token Issuer</DisplayName>
<TechnicalProfiles>

<!-- SAML Token Issuer technical profile -->
<TechnicalProfile Id="Saml2AssertionIssuer_SAMPLE">
<DisplayName>Token Issuer</DisplayName>
<Protocol Name="SAML2"/>
<OutputTokenFormat>SAML2</OutputTokenFormat>
<Metadata>
<Item Key="IssuerUri">https://nfpoc.b2clogin.com/nfpoc.onmicrosoft.com/B2C_1A_SI_SAML_SAMPLE</Item>
</Metadata>
<CryptographicKeys>
<Key Id="MetadataSigning" StorageReferenceId="B2C_1A_samlsampleapp"/>
<Key Id="SamlAssertionSigning" StorageReferenceId="B2C_1A_samlsampleapp"/>
<Key Id="SamlMessageSigning" StorageReferenceId="B2C_1A_samlsampleapp"/>
</CryptographicKeys>
<InputClaims/>
<OutputClaims/>
<UseTechnicalProfileForSessionManagement ReferenceId="SM-Saml-issuer"/>
</TechnicalProfile>

<!-- Session management technical profile for SAML based tokens -->
<TechnicalProfile Id="SM-Saml-issuer">
<DisplayName>Session Management Provider</DisplayName>
<Protocol Name="Proprietary" Handler="Web.TPEngine.SSO.SamlSSOSessionProvider, Web.TPEngine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"/>
</TechnicalProfile>
</TechnicalProfiles>
</ClaimsProvider>


  • UserJourneyを定義する
    • この辺は通常のカスタムポリシーと同じです
  • RelyingPartyの定義を行う
    • 公式ドキュメントだとSAML SPに関するパラメータはAzure AD B2Cにアプリケーション定義を作ってマニフェストで設定する、ということになっていますが、Azure ADとB2Bとして連携する場合は、ちょっと工夫が必要です(後述します)

Azure AD側の設定

Azure ADの直接フェデレーションの設定を行います。
  • プロトコルはSAMLを選ぶ
  • IdPのドメイン名はSAML IdPの認証エンドポイントと同一ドメインである必要があるため、Azure AD B2Cのドメイン名(~.b2clogin.com)を指定する
  • 上記でAzure AD B2Cの設定が上手くいっていればSAML Metadataのダウンロードが出来るようになっていますので、保存したMetadataをアップロードして解析を行う
直接フェデレーションの設定画面。ここで「新しいSAML/WS-Fed IdP」を選びます。

    こんな感じで設定します。



    設定としては非常にシンプルです。
    ただ、何点かクセがありますので、その部分を重点的に書いておきます。

    設定のポイント

    Azure AD B2Cのアプリケーション設定
    • ドキュメントを見ると、Azure AD B2Bと直接連携するためには以下の情報を設定する必要があることがわかります。
      • AssertionConsumerService
        • https://login.microsoftonline.com/login.srf
      • Audience(日本語ドキュメントだと「対象ユーザー」となっていますが。。。SAML SPのEntityIDのことです)
        • urn:federation:MicrosoftOnline
      • しかし、現状のAzure AD B2Cのアプリケーション登録ではカスタムスキームのAudience(urn:federation:MicrosoftOnline)をマニフェスト編集をしても登録することが出来ません。
      • ということで、SP(Azure AD)のMetadataを作って適当なところ(今回はbob)にアップロードし、カスタムポリシーから参照する形をとります。
      こんな感じです。
      <RelyingParty>
      <DefaultUserJourney ReferenceId="SI_SAML_SAMPLE" />
      <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2"/>
      <Metadata>
      <Item Key="PartnerEntity">https://nfpoccontent.blob.core.windows.net/root/aad_sp_meta.xml</Item>

      手動で作ったSP Metadataはこんな感じです。単純にEntityIDとエンドポイントさえ書いてあれば最低限はOKです。

      <?xml version="1.0"?>
      <md:EntityDescriptor
      xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
      xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
      entityID="urn:federation:MicrosoftOnline"
      validUntil="2031-12-31T00:00:00.000Z">
      <md:SPSSODescriptor
      protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
      <md:SingleLogoutService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://login.microsoftonline.com/login.srf"/>
      <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://login.microsoftonline.com/login.srf" index="0"/>
      </md:SPSSODescriptor>
      </md:EntityDescriptor>

      Azure AD B2CのSAML Metadata

      • 一応ドキュメントを漁ると出てくるのですが、見落としがちなので書いておきますが、以下のルールでMetadata URLが生成されます。
        • https://ドテナント名.b2clogin.com/テナント名.onmicrosoft.com/B2C_1A_ポリシー名/Samlp/metadata
      Azure AD B2CからAzure ADへ渡す属性(SAML AssertionのAttributeStatement)

      • ドキュメントを見るとnameidがpersistentであること、emailaddressを属性として渡すこと、とありますので、それに合わせてAzure AD B2CのRelyingParty設定を行います。具体的にはOutputClaimsの設定です。
      • また、標準的なAzure AD B2CのSAML設定だと結構冗長な感じでAttributeStatementが書かれるので、TechnicalProfileのMetadataにSaml11AttributeEncodingInfo(Saml20~でもOK)を指定することで少しすっきりします。
      こんな感じのRelyingParty定義になります。

      <RelyingParty>
      <DefaultUserJourney ReferenceId="SI_SAML_SAMPLE" />
      <TechnicalProfile Id="PolicyProfile">
      <DisplayName>PolicyProfile</DisplayName>
      <Protocol Name="SAML2"/>
      <Metadata>
      <Item Key="PartnerEntity">https://nfpoccontent.blob.core.windows.net/root/aad_sp_meta.xml</Item>
      <Item Key="Saml11AttributeEncodingInfo">
      <![CDATA[
      <saml:AttributeStatement xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion">
      <saml:Attribute AttributeName="emailaddress" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims">
      <saml:AttributeValue>
      </saml:AttributeValue>
      </saml:AttributeStatement>]]></Item>
      </Metadata>
      <OutputClaims>
      <OutputClaim ClaimTypeReferenceId="objectId" PartnerClaimType="objectId"/>
      <OutputClaim ClaimTypeReferenceId="b2cmail" PartnerClaimType="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" />
      </OutputClaims>
      <SubjectNamingInfo ClaimType="objectId" ExcludeAsClaim="true"/>
      </TechnicalProfile>
      </RelyingParty>
      </TrustFrameworkPolicy>

      ちなみにClaimType「b2cmail」は適当に適宜した属性なので自由に定義してもらえれば良いかと思います。重要なのは、「Azure AD B2Cのドメインと同じドメイン名を持つメールアドレスが設定されていること」です。例えば、hoge.b2clogin.comというAzure AD B2Cドメインを使っている場合は、fuga@hoge.b2clogin.comという値を返す必要があります。
      ※この辺りは早くAzure AD B2Cがカスタムドメインをサポートしてくれないと実利用するには辛いですね。

      いざ、動作確認

      設定はこれでおしまいです。
      しかし、あくまでこれはAzure AD B2Bにおける「外部ユーザの招待において独自のパスワードを払い出さずに済ませるための機能(これ重要)」なので、あらかじめユーザを招待しておく必要があります。

      ここは通常の招待と同じなので詳細は割愛しますが、Azure AD B2Cのドメインと同じドメインのユーザを指定して招待する、というところがポイントです。
      つまり、メールは届きません。(少なくともb2clogin.comを使っている限り、一般人はこのドメインでメールは届かないと思います)

      ただ、招待されている状態であれば招待元のアプリケーションにアクセスすれば招待の承認と同じことが起きますので、運用でカバーです。



      そして、これも公式ドキュメントに記載されていますが、現状B2Bの直接フェデレーションはマルチテナントアプリケーションでのホームレルムディスカバリが使えないので、招待元ディレクトリのテナントIDやドメイン名が明示的に指定されているアプリケーションしか動きません。
      例えば、

      • https://myapps.microsoft.comはダメ
      • https://myapps.microsoft.com/?tenantid=xxxxxxxxはOK
      という感じです。


      ここまで行けば、冒頭に動画で紹介した動きが再現できるはずです。
      ちなみに動画内では条件付きアクセスを使ってゲストユーザの初回ログイン時に利用規約に同意させる様にしています。

      カスタムドメイン単位でのフェデレーションと何が違うのか?

      ここで疑問が出てくるのが、元々Azure ADにはカスタムドメイン単位で外部のSAML/WS-FederationのIdPと連携する機能があります。ちょっと前に多くの企業がAD FSをオンプレにおいてOffice365とSSOをやっていた構成ですね。

      もちろんこのケースは社内ユーザを想定した話ですが、技術的に言うとB2Bの直接フェデレーションとほぼ変わりません。

      ただ、細かく見るとちょっとずつ違います。
      非常に雑な比較ですが、こんな感じです。

      カスタムドメインのID連携B2Bの直接フェデレーション
      フェデレーション単位ドメイン単位ドメイン単位
      ユーザの管理あらかじめ作成が必要(Azure AD Connectでの同期など)
      ImmutableIdでのマッチング
      あらかじめ招待が必要
      メールアドレスでのマッチング
      アプリケーションの制限マルチテナントでも可
      また、WS-Fedでwindowstranportエンドポイントの整備などの条件を満たせばWindows 10 PCログオンも可(Webサインイン設定不要)
      マルチテナントアプリは不可
      当然Windows 10 PCログインには使えない




      ということで、実用的かどうかはユースケース次第というところですが、日々色々な機能が拡張されてきているな、というところです。



      Azure ADを拡張してOpenID Connect for Identity Assuranceに対応させる

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

      先日、OpenID ConnectのID保証に関する拡張仕様である「OpenID Connect for Identity Assurance」について紹介しましたが、実際に仕様を理解するためには実装してみるのが一番、ということでAzure Active Directoryを拡張して実装してみようと思います。(尚、現状は完成している訳ではありません。軽く動作を確認してみた程度です)

      Azure ADに足りないもの

      OpenID Connect for Identity Assuranceを実装する上で、Azure ADに足りないものは最低限でも以下の通りです。

      • Authorizationエンドポイントがclaimsパラメータを受け付ける機能
      • verified_claims等の属性をid_tokenやuserInfoエンドポイントから返す機能

      逆に、Azure ADでも以下について当然ですが出来ます。

      • 認証
      • ユーザデータを保持するデータベース
      • アプリケーション(Client)管理

      実装に向けた戦略

      ということで、以下の戦略で拡張してみることにしました。
      • Azure ADのエンドポイントをラップするWebアプリを用意し、request/responseの整形を行う
      • 認証、データ保持、アプリケーション管理はAzure ADの機能を使う
      • OpenID Connect for Identity Assuranceで拡張された属性(verified_claims関係)はAzure ADのスキーマを拡張する
      こんな感じの仕組みになるはずです。


      いざ実装

      準備1:Azure ADのスキーマを拡張する

      Azure ADにはスキーマ拡張を行う機能がありますので、今回はこの機能を使ってAzure AD上にID保証に関する情報、ID保証済みの属性を保存できるようにします。

      Azure ADのスキーマ拡張に関するドキュメントはこちら

      OpenID Connect for Identity Assuranceでは「verified_claims」というエレメントの定義がされており、配下に「verification」と「claims」というエレメントが存在します。
      • verification : IDの検証をどのように行ったのか?の記録
        • trust_framework : どんなルールによってIDの確認・検証をしたのか。例えば犯罪収益移転防止法や携帯電話不正利用法などの、本人確認を行った際の根拠法やルールを指定します
        • Evidence : ID確認時に利用した証拠(エビデンス)を指定します。免許証などですね。
          • type : エビデンスの種類を指定します。id_document(証明書類)、utility_bill(公共料金の領収書)、qes(欧州限定ですがeIDASの電子証明書)がありますが、ここではid_documentを使いました。
          • method : typeで指定したエビデンスをどのように確認したのか?を指定します。例えば対面で確認した場合は「Physical In-Person Proofing」ということで「pipp」という値を設定します。
          • document : typeにid_documentを指定した場合に、具体的に何の証明書類を使ったのか?を指定します。例えば日本の免許証なら「jp_drivers_license」を指定します。
          • issuer : 証明書を発行した機関に関する情報を指定します。
            • name : 機関名
            • country : 機関の属する国
          • date_of_issuance : 証明書類の発行日を指定します。
          • date_of_expiry : 証明書の有効期限を指定します。
      • claims : 検証された属性(ここは要求された属性を普通に指定します)
        • given_name : 検証済みの名
        • family_name : 検証済みの姓
        • など

      この形でAzure ADの属性を拡張出来ればいいのですが、上記ドキュメントにもある通り、拡張できる属性の型はStringやInteger、DateTimeなどに限定され入れ子の構造や配列構造が取れません。本来なら複数のエビデンスを使ったID証明などもあり得ますが、現状はデータをフラットで持つしかありませんので諦めます。

      具体的な方法は以下の通りです。
      • Directory.AccessAsUser.Allをスコープに指定してaccess_tokenを取得する
      • https://graph.microsoft.com/v1.0/schemaExtensionsに拡張したいスキーマの構造(JSON)をPOSTする
      • 成功したら他のクライアントからでも参照可能な様にスキーマをアクティベーションする(status属性をPATCHでActiveに更新する)
      今回、以下の2つの拡張属性を作りました。
      • verification
      • verifiedClaims

      それぞれのPOSTしたデータはこちらです。
      - verification
      {
      "id":"verification",
      "description": "verification extension for OpenID Connect for Identity Assurance",
      "targetTypes": [
      "User"
      ],
      "properties": [
      {
      "name": "verificationId",
      "type": "String"
      },
      {
      "name": "trustframework",
      "type": "String"
      },
      {
      "name": "evidenceType",
      "type": "String"
      },
      {
      "name": "evidenceMethod",
      "type": "String"
      },
      {
      "name": "evidenceDocumentType",
      "type": "String"
      },
      {
      "name": "evidenceDocumentIssuerName",
      "type": "String"
      },
      {
      "name": "evidenceDocumentIssuerCountry",
      "type": "String"
      },
      {
      "name": "evidenceNumber",
      "type": "String"
      },
      {
      "name": "evidenceDateOfIssurance",
      "type": "DateTime"
      },
      {
      "name": "evidenceDateOfExpiry",
      "type": "DateTime"
      }
      ]
      }



      - verifiedClaims
      {
      "id": "verifiedClaims",
      "description": "verified claims extension for OpenID Connect for Identity Assurance",
      "targetTypes": [
      "User"
      ],
      "properties": [
      {
      "name": "verificationId",
      "type": "String"
      },
      {
      "name": "givenName",
      "type": "String"
      },
      {
      "name": "familyName",
      "type": "String"
      }
      ]
      }


      ちなみに、拡張スキーマの単位でid(属性名となります)をつけることが出来ますが、.net、.comなど限られたTLDでカスタムドメインをAzure ADに追加している場合は、[カスタムドメイン名]_[拡張属性名]という名前で属性を作ることが出来ますが、カスタムドメインを持っていない場合は「ext][8桁のランダム文字列]_[拡張属性名]という形で属性名が払い出されます。

      当然ですが、この拡張属性に値を入れた状態のユーザを用意しておく必要があります。この辺りはGraph APIを使って値のセットをしてください。

      準備2:Azure ADをラップするWebサービスを作る

      ココが本番です。といってもやることはシンプルです。
      (本来はちゃんと実装しないと危険ですので注意してください。本ポストにサンプルコードが出てきますが、かなり手抜きなのであくまで参考として捉えてください


      • Authorizationエンドポイント
        • clientからの要求の中でAzure ADが受け取ってくれないclaimsパラメータをパースして保持します。後からレスポンスを作るときに何が要求されていたのかを判断するために使います。
        • ※テスト実装では決めうち実装なので実際には保持していません
      router.get('/authorize', (req, res) => {
      // get claims from request
      var _claims = req.query.claims;
      // redirect to Azure AD
      var target = lib.addQueryTo(conf.AAD_AuthZ, {
      response_type: 'code',
      scope: 'openid User.Read',
      client_id: req.query.client_id,
      state: req.query.state,
      redirect_uri: req.query.redirect_uri });
      res.redirect(target);
      });


      • Tokenエンドポイント
        • codeを受け取ってAzure ADのTokenエンドポイントへ渡してaccess_token、id_tokenを受け取ります。
        • id_tokenには当然verified_claimsが含まれていないので、一度id_tokenをほどき、必要に応じてaccess_tokenを使ってMicrosoft Graphで追加の属性を取得、id_tokenを生成してclientへ返却します。
        • ※テスト実装ではPKCEに対応させていませんので、code横取りをして実装しています。本来はclientとPKCEに使う情報を共有しないと横取り出来ないので、ここはちゃんと考えないとダメです。
      router.post('/token', async (req,res) => {
      try{
      let response_from_aad_token = await request({
      url: conf.AAD_Token,
      method: "POST",
      form: {
      grant_type: 'authorization_code',
      code: req.body.code,
      client_id: req.body.client_id,
      client_secret: req.body.client_secret,
      redirect_uri: req.body.redirect_uri
      },
      json: true
      })
      console.log(response_from_aad_token);
      // extract response and re-generate id_token with verified claims
      let decoded_jwt = jwt.decode(response_from_aad_token.id_token)

      // get additional claims using graph api
      let response_from_graph = await request({
      url: conf.AAD_Graph + "/v1.0/me?$select=id,userPrincipalName," + conf.AAD_ExtPrefix + "_verifiedClaims," + conf.AAD_ExtPrefix + "_verification",
      method: "GET",
      headers: {
      'Authorization': 'Bearer ' + response_from_aad_token.access_token,
      'Content-Type': 'application/json'
      }
      })
      console.log(response_from_graph);
      var user = JSON.parse(response_from_graph);
      // get properties from user object
      for (var prop in user){
      if(prop.includes('_verification')){
      var _verification = {
      trustframework: user[prop].trustframework,
      evidenceType: user[prop].evidenceType,
      evidenceMethod: user[prop].evidenceMethod,
      evidenceDocumentType: user[prop].evidenceDocumentType,
      evidenceDocumentIssuerName: user[prop].evidenceDocumentIssuerName,
      evidenceDocumentIssuerCountry: user[prop].evidenceDocumentIssuerCountry,
      evidenceDateOfIssurance: user[prop].evidenceDateOfIssurance,
      evidenceDateOfExpiry: user[prop].evidenceDateOfExpiry
      }
      } else if(prop.includes('_verifiedClaims')){
      var _verifiedClaims = {
      familyName: user[prop].familyName,
      givenName: user[prop].givenName
      }
      }
      }
      // create new jwt.
      var privateKey = fs.readFileSync('./private_key.pem', 'utf-8')
      var new_jwt = null;
      if (typeof _verification !== 'undefined') {
      new_jwt = jwt.sign({
      sub: decoded_jwt.sub,
      iss: 'https://' + req.headers.host,
      aud: decoded_jwt.aud,
      iat: decoded_jwt.iat,
      exp: decoded_jwt.exp,
      email: decoded_jwt.email,
      verified_claims: {
      verification: {
      trust_framework: _verification.trustframework,
      evidence: [
      {
      type: _verification.evidenceType,
      method: _verification.evidenceMethod,
      document: {
      type: _verification.evidenceDocumentType,
      issuer: {
      name: _verification.evidenceDocumentIssuerName,
      country: _verification.evidenceDocumentIssuerCountry
      },
      number: _verification.evidenceNumber,
      date_of_issuance: _verification.evidenceDateOfIssurance,
      date_of_expiry: _verification.evidenceDateOfExpiry
      }
      }
      ]
      },
      claims: {
      given_name: _verifiedClaims.givenName,
      first_name: _verifiedClaims.familyName
      }
      }
      }, privateKey, { algorithm: 'RS256' });
      } else {
      new_jwt = jwt.sign({
      sub: decoded_jwt.sub,
      iss: 'https://' + req.headers.host,
      aud: decoded_jwt.aud,
      iat: decoded_jwt.iat,
      exp: decoded_jwt.exp,
      email: decoded_jwt.email,
      }, privateKey, { algorithm: 'RS256' });
      }

      res.send({
      token_type: "bearer",
      scope: "openid",
      expires_in: response_from_aad_token.expires_in,
      access_token: response_from_aad_token.access_token,
      id_token: new_jwt
      });
      } catch(e){
      console.log(e);
      }
      });


      • userInfoエンドポイント
        • access_tokenを使ってMicrosoft Graphから必要な属性を取得して、整形した上でclientへ返却します
        • ※テスト実装ではここは実装していません。id_tokenにverified_claimsを入れて返却するところまでです。
      • その他
        • .well-known/openid-configurationとかjwks_uriは必要に応じて実装します。id_tokenの署名をAzure ADではなくこのWebサービス側で行うので対応した公開鍵などの情報をclientへ公開してあげる必要があります。

      とりあえずこんな感じでnode.jsで実装してみています。


      実際に動かす

      テストするにしてもclientが必要になるので、phpでちょこっと書いておく必要があります。
      やるべきことはclaimsパラメータを認証要求に乗せて検証済み属性を要求する、ということだけであとは普通のOpenID Connectのクライアントです。

      こんな感じですね。
          // claims生成
      $verificationArray = array(
      'trust_framework'=>'null'
      );
      $claimsArray = array(
      'given_name'=>'null',
      'family_name'=>'null'
      );
      $verified_claimsArray = array(
      'verification'=>$verificationArray,
      'claims'=>$claimsArray
      );
      $id_tokenArray = array(
      'email'=>'null',
      'verified_claims'=>$verified_claimsArray
      );
      $claimsArray = array(
      'id_token'=>$id_tokenArray
      );

      // GETパラメータ関係
      $query = http_build_query(array(
      'client_id'=>$client_id,
      'response_type'=>$response_type,
      'redirect_uri'=> $redirect_uri,
      'scope'=>'openid User.Read',
      'state'=>$state,
      'nonce'=>$nonce,
      'claims'=>json_encode($claimsArray)
      ));
      // リクエスト
      header('Location: ' . $authorization_endpoint . '?' . $query );


      動かすとこんな感じになります。
      node.jsを動かすのにglitchを使っているので起き上がるまでにちょっと時間がかかってますが。。。


      ということで、ここまでのソースはこちらにあります。
      くれぐれも真似して使わない様にしてください。色々危ないので。
      https://github.com/fujie/aad_oidc4ida


      Build速報!FacebookでAzure ADへログインする

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

      Buildですね。リモート開催になって日本からでも参加しやすくなって睡眠時間が削られる日々をお過ごしだと思います。

      今回も色々とAzure ADに関する新機能の発表がありました。

      詳しくはAlexのBlogを参照してもらえれば良いのですが、今回はAzure AD B2Bの直接フェデレーションへのFacebookログインの登場(Public Preview)の話です。

      AlexのBlog)
      https://techcommunity.microsoft.com/t5/azure-active-directory-identity/build-2020-fostering-a-secure-and-trustworthy-app-ecosystem-for/ba-p/1257360

      Azure AD B2Bの直接フェデレーションについてはこれまでも取り上げてきましたが、Googleに対応してから約2年、ここに来てFacebookに対応しました。

      Googleとの連携の件
      https://idmlab.eidentity.jp/2018/08/azure-ad-b2bgoogleid.html

      カスタムドメイン vs 直接フェデレーションの件
      https://idmlab.eidentity.jp/2020/05/azure-adbyoid.html



      もはやB2Bとは?というしかない状態なのですが、早速触ってみましょう。

      外部アイデンティティプロバイダの設定

      これまでも紹介したことのある画面です。Azure ADのポータルを開き、External Identitiesメニューから「すべてのIDプロバイダー」を開くと「Google」に加えて新たに「Facebook」が選べるようになっています。


      ここでFacebookを追加して、AppIdとAppSecretを追加すれば基本は終わりなのですが、設定前に外部ユーザによるサインアップを許可しておく必要があります。
      「外部コラボレーションの設定」メニューを見ると、新しく「ユーザーフローによるゲストセルフサービスサインアップを有効にする」という設定が追加されているので有効にしておきましょう。

      後はFacebook Developerコンソールで作成したアプリケーションのAppIdとAppSecretを設定すれば終わりです。

      Facebook側の設定方法はAzure AD B2Cのドキュメントに記載がありますので、1点を除いてこちらをそのまま使って大丈夫です。
      https://docs.microsoft.com/en-us/azure/active-directory-b2c/identity-provider-facebook

      その1点とは、そうですredirect_uriです。
      直接フェデレーションの場合にFacebookに設定するredirect_uriはどうなるのか?というと、
      https://login.microsoftonline.com/te/{テナントID}/oauth2/authresp
      となります。

      ここまで設定を進めると、ユーザーフローからAzure ADにアクセスするためのアプリケーション「aad-extensions-app」が自動的に登録されます。


      ちなみに、このアプリケーションを削除すると面倒なことになるので、消さないようにしてください。
      万一消してしまったらAzure AD B2Cでのb2c-extension-appと同じように回復をしてください。
      参考)B2Cでの回復手順
      https://docs.microsoft.com/ja-jp/azure/active-directory-b2c/extensions-app


      ユーザーフローの登録

      外部IDプロバイダの設定が終わったら、次はユーザーフローの登録です。
      基本この辺りもAzure AD B2Cと同じです。


      ユーザーフローの名称(ポリシー名となります)、利用するIDプロバイダ、連携する属性を設定していきます。
      尚、属性は標準で用意されているもの以外に「カスタムのユーザー属性」メニューから自分で好きな属性を追加することもできます。

      これでIDプロバイダとユーザーフローの登録はおしまいです。

      アプリケーションの登録

      次に、先ほど作成したユーザーフローを使ってサインアップやサインインを行う対象となるアプリケーションを登録します。
      ポイントは、APIのアクセス許可で「User.Read」スコープに対して管理者による同意をしておくこと、です。現状のユーザーフローでのユーザ作成やログイン時にユーザ自身による同意が上手く取れない?のでこの設定は入れておく必要がありそうです。

      ユーザーフローとアプリケーションの紐づけ

      アプリケーションを作成したら、先に作成しておいたユーザーフローを使う様に構成をします。
      先ほどのExternal Identitiesメニューに戻り、先ほど作成したユーザーフローを開きます。アプリケーションに関する設定項目がありますので、ここで作成したアプリケーションを指定します。

      これで一通りの設定は終了です。

      動作確認

      では早速動かしてみます。

      このアプリケーションにアクセスする為には、以下のパラメータをつけてAuthorizationエンドポイント(https://login.microsoftonline.com/{テナントID}/oauth2/authorize)へアクセスする必要があります。(通常のOpenID Connectのアプリケーションと同じです)

      • client_id={登録したアプリのClient Id}
      • response_type=id_token
      • scope=openid
      • nonce={生成したnonceの値。テストなら何でもOK}
      • redirect_uri={登録したアプリのredirect_url}

      今回、アプリケーションとしてはhttps://jwt.msを使ったのでこんなURLになります。
      https://login.microsoftonline.com/{テナントID}/oauth2/authorize?client_id={クライアントID}&response_type=id_token&scope=openid&nonce=hoge&redirect_uri=https:%2F%2Fjwt.ms

      実行してみると、いつものサインイン画面になるので、まずはアカウントを作成します。

      アカウントの作成画面に「Facebookアカウントでサインイン」というメニューが出来ています。
      ここでFacebookアカウントでサインインすると、Azure ADへのアカウント登録を行う際に追加で登録するアカウントを入力する画面が出てきます。

      続行するとアカウントがAzure AD上に登録されます。
      アカウントタイプはゲスト、ソースはFacebookになっているのがわかります。


      ちなみに登録後、サインインする場合はサインインオプションをクリックするとFacebookログインのメニューが出ていますので、そちらを使ってサインインします。


      いかがでしょうか?
      基本はAzure AD B2Cの機能の一部を通常のAzure ADの直接フェデレーション向けに開放しただけなので、Azure AD B2Cに慣れている方は直感的に理解できると思います。

      しかし、冒頭にも書きましたが、こうなってくると「B2Bとは?」という疑問がやはり出てきますが大人しくしておきましょう。

      おまけ

      たまたまテストに使ったAzure ADにG-SuiteとのSSO設定があったので、SAMLの属性マッピングの調整をちょこっとして、GmailにAzure ADの直接フェデレーションを使ってFacebookアカウントでログインする、というくだらないものを作ってみたので動画を貼っておきます。

      分散型ID「ION」のプレビューがアップデート

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

      本ブログでも何度か触れたことのある分散型ID(この日本語訳は微妙だな、、、とは思いますが。Decentralized Identity)ですが、マイクロソフトも「ION(アイオン)」というコードネームで取り組んでいる、という話は過去のde:codeなどでも紹介してきました。

      de:code 2019での発表資料


      本ブログの過去ポスト
      https://idmlab.eidentity.jp/2019/04/blog-post.html


      先日のBuildでも当然セッションがあり、6月にUpdateあるよ!的な話がささやかれていたのですが、予定通り出てきました。

      URLは相変わらずプレビュー間満載ですが・・・・
      https://didproject.azurewebsites.net/docs/overview.html

      新プレビューの概要

      今回のプレビューで出来るようになったことは大きくは以下の通りです。

      • Azure ADとの統合(Credentialsのソースとして利用)
      • Microsoft AuthenticatorをWalletとして利用
      • Azure Key VaultでVerifiable Credentialsへの署名する鍵を管理
      想像するにこんな感じの構造になっていると思われます。

      構造としてはこんな感じです。
      【Verifiable Credentialsの発行時】
      • Portable Identity Cards(実体のアプリ名はVerifiable Credentials Issuer Service)がAzure ADにEnterprise Applicationとして登録されている
      • Portable Identity CardsがAzure AD上に登録されたユーザの情報を元にVerifiable Credentials(VC)を発行する
      • ユーザはMicrosoft Authenticator(現状はAndroid/Beta版のみ対応)に発行されたVCをカードのメタファとして保存(ちなみに使われていると思われるAndroid用のSDKもここに公開されているので自作するのも可能なはず)
      • VCへの署名をするための秘密鍵はAzure KeyVaultで管理される
      • 分散台帳(ION)とのやり取りはPortable Identity Cardsサービスが使っているverifiablecredentials-verification-sdk-typescriptがやっている
      【Verifiable Credentialsの利用時】
      • Portable Identity Cardsサービスと同じく、verifiablecredentials-verification-sdk-typescriptを使ったサービスへアクセス
      • サービスはQRコードを使ってVCの開示要求、ユーザはMicrosoft AuthenticatorでQEコードを読み込み、VCを送付
      • Portable Identity CardsサービスはVCをDLT上の公開鍵を使って検証(この辺もverifiablecredentials-verification-sdk-typescriptがやっている)


      上記よりわかる通り、実体は「verifiablecredentials-verification-sdk-typescript」です。これをVC発行者がわかりやすいようにAzure AD/Azure KeyVaultと統合したものがPortable Identity Cardsであり、ユーザが使いやすいようにしたのがMicrosoft Authenticatorということです。



      動きを見てみる

      では、早速試してみましょう。

      と言いたいところなのですが、Limited PreviewなのでMicrosoftに承認されないと動きません。(申請してみたけど返事がない・・・)
      ただ、手順を見ているとAzure ADのEnterprise ApplicationsにVerifiable Credentials Issuer Serviceが出てきてObjectIDが取れればPreview機能が有効になっているよ、とあるのですが、一向にPortable Identity Cardsの管理コンソールがAzure Portalに現れません・・・・

      上の図の通り、Previewが有効化されたテナントでAzure AD P1もしくはP2を有効にするとエンタープライズアプリケーションの一覧にVerifiable Credentials Issuer Serviceは出てきましたが、Portable Identity Cardsのコンソールが出てこない・・・(以下の図は手順書より)




      ということで、自前のAzure ADを使うのはあきらめて素のverifiablecredentials-verification-sdk-typescriptを使ったサンプルコードを使って試してみます。
      ちなみに、昨日までVCの発行まではうまく動いたのですが、検証はうまく動きませんでした。しかし、今朝サンプルコードが更新され現在はちゃんと検証まで動くようになりました。

      サンプルコートはココにありますので、ローカルにcloneして使いました。

      ちなみにMicrosoft Authenticatorからサービスにアクセスできる必要があるので、ngrokを使って外部からアクセスできるようにしました。

      改造したコードはこちらです。
      Issuer
      Verifier

      それぞれnpm installしてnode app.jsで実行できます。


      まずはIssuerから動かします。
      (前もってMicrosoft Authenticatorのベータ版を入れておいてください。現状Android版のみです)

      起動すると画面上にボタンがあるのでクリックするとQRコードが表示されますので、これをAuthenticatorで読み込むと、Azure AD B2Cでのログインを要求されますので、アカウントの作成~ログインを行うとカード(Verified Credential Ninja)が追加されます。

      Authenticatorでその他のアカウントを追加してQRコードを読み取る

      Sign in to your accountでAzure AD B2Cへログインする。(初回は新規作成)

      ログインが終わったらAcceptをタップします。

      上手くいくとカードがAuthenticatorの中に保存されます。この中にVerifiable Credentialsとして氏名の情報が入っています。

      次はVerifyです。
      ngrokを使っていると2つ同時にサービスを挙げられないのでIssuerを停止しておきます。
      Verifierを起動するとIssuerと同じようにボタンがあるのでクリックするとQRコードが表示されます。
      これをAuthenticatorのカードの画面にあるQRコードリーダーを使って読み取ります。


      上手くいくと画面上に「Congratulations, XX XX is a Verified Credential Ninja!」と出てきます。


      ここまでは外から観測できたことなので、今後は引き続き中身を掘ってみようと思います。
      IdentityCardRules.jsonファイルをいじくると他のOpenID Providerからでもクレデンシャル発行が出来るようですし。



      参考)Buildのセッションの動画


      [DID]リゾルバあれこれ

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

      完全に個人メモです。

      ご存知の通りDID(Decentralized Identifier)の構造は
      did:{method}:{method specific identifier}
      となっています。

      例えば、イーサリアムだったら
      did:ethr:0xE6Fe788d8ca214A080b0f6aC7F48480b2AEfa9a6
      という感じです。

      現状Blockchainの系がバラバラと乱立している状態なので、系の間でユニバーサルに一意に識別できる仕組みがないとDIDがIdentifier(識別子)としての役割を果たせないことはわかるんですが、そもそも論としてメソッド名が識別子の中に入っているって言うのもなぁ、と個人的には思いますが他にいいアイデアが出せるわけではないので自粛しておきます。

      話はそれましたがDIDが上記の様な形式になっている以上、系を跨いで識別子(DID)および関連する情報(DID Metadata)を解決する仕組みがないと、DIDを使ったアイデンティティ管理システムが成立しません。ということで今日の本題の「リゾルバ」が必要になるわけで、実質標準になっているのがMarcusがやっている「Universal Resolver」である、というわけです。

      元々DID関係はW3CのWeb Payment WG、Verifiable Credentials TF、OASISのXDI TC Registry WGが別々にやっていて、2015年〜2016年あたりでDPKIとかのドラフトとして出てきた中でレゾルバの必要性に注目してUniversal Resolverを作った、みたいな話を2018年のEuropean Identity and Cloud ConferenceでMarkusから聞いたとき、リソルバ自身の信頼性ってどうやって担保するの??みたいな話を聞いた覚えがあります。その時にMarkusはリゾルバ自体はOSSだからプライベート実装しても良いし、アプリに組み込んでも良いよ、みたいな話をしていました。

      そんな中でMarkusがサンプル実装として公開したのが先の https://uniresolver.io/ で、他にもベンダが実装してきている例としてMicrosoftが自前のDID Projectで実装したのが、 https://beta.discover.did.microsoft.com/ だったりする、ということなんですね。

      と言うことで、それぞれどんな感じなのかみてみようと思います。

      登録されているDID method

      そもそも現在どんなDID methodが存在しているのか、という話になるのですが、DID methodはW3Cのコミュニティグループで「ゆるく」管理?されています。

      https://w3c-ccg.github.io/did-method-registry/

      今日(2020/07/23)の段階で59個も登録されてるんですね。残念ながらuPortはdeprecatedになってます(単にethrに引っ越しただけですが)。

      Universal Resolverの状況

      Universal ResolverではメソッドをサポートするためにDriverという単位でプラグインを追加していく形になります。

      githubのレポジトリを見るとDriverの開発の方法や現在開発されているDriverの一覧を確認することが出来ます。

      https://github.com/decentralized-identity/universal-resolver/

      同じく今日時点で28種類ある様です。

      使い方としては非常にシンプルでUniversal Resolverをデプロイし、エンドポイントに対して
      curl -X GET http://localhost:8080/1.0/identifiers/did:sov:WRfXPg8dantKVubE3HX8pw
      という感じでGETしてあげればDID metadataが返ってくるという仕掛けです。

      これをWebで簡単に触れる様にしたのが先に書いた

      https://uniresolver.io/

      ってことです。


      Microsoftの実装は?

      前回のポストでも紹介しましたがMicrosoftもDIDの世界に突き進んでいるわけですが、当然マネージドなリゾルバを提供しています。
      公開されているサンプルソースを掘っていくと、

      https://beta.discover.did.microsoft.com/

      というURLが出てきます。

      ご存知の通りMicrosoftのDID/IONのメソッドは ion で、現在Universal Resolverではサポートされていません。ionメソッドのDIDをUniversal Resolverで解決しようとしてもNFです。



      と言うことでMicrosoftのDIDを解決するには上記のリゾルバを使うしかなさそうです。

      使い方としては、Universal Resolverと同じで


      curl -X GET https://beta.discover.did.microsoft.com/1.0/identifiers/did:ion:EiBo3GQwMgF...
      と言う感じです。

      DID metadataの視認性を上げるためにFirefoxで開いてみます。


      ふとした疑問として、どこまでMicrosoftのリゾルバは他のメソッドをサポートしているんだろう?と思って実験してみました。サンプルとして使ったDIDはUniversal Resolverのレポジトリにあるテスト用のものを使いました。

      以下が結果です。
      methodsupport
      sovOK
      btctrOK
      v1:testOK
      keyOK
      ipidNG? Universal ResolverでもTimeoutするのでipid側の不具合かも
      webNG? サンプルになっているのがdid:web:uport.meなのでDIDの問題かと
      ethrNG. Timeout
      naclOK
      joloNG. Timeout
      stackOK
      erc725NG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
      hcrOK
      neoidNG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
      elemNG
      githubNG
      ccpOK
      workOK
      ontOK
      kiltOK
      evanOK
      echoOK
      factomOK
      dockOK
      abtOK
      trustblocNG
      siriusNG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
      mpgNG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
      trustNG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい
      ioNG? Universal ResolverでもExceptionが出るのでドライバの問題っぽい



      ということで完全に自分メモでした。





      Azure Identity Protection for B2CがPublic Preview

      $
      0
      0

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

      ずっと出ると言われていて待っていたAzure Identity Protection(リスク判定と条件付きアクセス)のAzure AD B2C対応版がようやくPublic Previewになりました。

      公式Blogでのアナウンス

       Azure Active Directory External Identities goes premium with advanced security for B2C

       https://techcommunity.microsoft.com/t5/azure-active-directory-identity/azure-active-directory-external-identities-goes-premium-with/ba-p/1604572


      ポイントをまとめるとこんな感じです。

      • Identity Protection
        • 基本は普通のAzure AD版のIdentity Protectionのサブセット
        • 以下の制限あり
          • B2Cテナントでのセキュリティ・センターは使えない
          • ROPCフローでは使えない
          • ローカルアカウントでしか使えない
      • 条件付きアクセス
        • 基本は普通のAzure AD版の条件付きアクセスのサブセット
        • 以下の制限あり
          • デバイス状態をベースとして条件判定は使えない(設定はできちゃいますが)
      • ビルトインのユーザ・フローでもカスタム・ポリシーでも使える
      • ライセンス
        • Premium P2 Tierが必要


      一番気になるP2ライセンスの価格表ですが、月間アクティブユーザー課金で通常の利用料+1.8円程度かかるみたいですね。(契約形態などにも依存するはずなので正確にはちゃんと調べてくださいね)

      https://azure.microsoft.com/en-us/pricing/details/active-directory/external-identities/


      徐々に全テナントにロールアウトされるみたいですが、私のテナントではすでに使えているのでFirst Lookをとりあえず。


      何はともあれPricing TierをPremium P2へ。


      ビルトインフローは面倒なのでカスタム・ポリシーで。

      基本的な考え方としては、①リスク評価をして、②結果によっては多要素認証などによりユーザに対応をさせて、③結果OKであればリスクを緩和する、というプロセスでUserJourneyを汲みます。

      全部は紹介しませんが、とりあえずこんな感じですね。

      ConditionalAccessProtocolProviderを使ったTechnicalProfileを作ってOperationTypeでリスク評価なのか緩和なのかを切り替える、という感じです。


      リスク評価の結果のアクションをどうするか、については通常の条件付きアクセスと同じように設定します。

      とりあえず評価だけですが、ポリシーを実行するとカスタム属性に評価結果が出てきます。


      ざっとですが、こんな感じです。

      サードパーティのソリューションとの連携のエコシステムもできつつある中、純正機能もどんどんリリースされるので、全体として成長していくようにキャッチアップを続けていかないといけませんね。

      Microsoft IgniteでのDID/VC関連トピックス

      $
      0
      0

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

      先週のオンライン開催されたMicrosoft IgniteではAzure Active Directoryを始めとするアイデンティティ関連のトピックスや新機能発表が色々とありました。

      個人的に気になったのは、

      • Identity ProtectionがAzure AD B2Cにもきた
      • 条件付きアクセスがGraph API経由で触れる様になった
      • ヘッダ認証が使える様になった
      • VC関係の近況と退役軍人向けの教育プログラムへの適用事例
      の4点です。

      1点目は先日Blogにも書いた通り、今後のB2C向けサービスの幅が非常に広がる話ですし、2点目はリスクイベントを拾ってTeamsなど外部サービスに連携させるデモなどもあり運用面で非常に有用だと思いました。また3点目は以前Ping Access連携で実現していたことがMS純正でできる様になる、というところでレガシーアプリケーションへの適用の面では非常に有用だと思います。

      そして、最後が本日のメインであるDID/VC関係の近況です。
      * DID : Decentralized Identifier
      * VC : Verifiable Credentials

      こちらも以前ブログに書きましたが、その後ブラッシュアップされてきているもです。
      ※この辺のキーワード(含む自己主権型アイデンティティ/SSI)の使い方は間違って使われているケースが散見される(Decentralized Identityとか)たり、=ブロックチェーンみたいな誤解もあるみたいなのでどこかでちゃんとまとめないとな、、、と。この辺りのスライドを書いてから、自分の理解も進んだのと標準化の方向性も進捗してるのでどこかでUpdateします。。。

      話がそれましたが、早速Igniteでのトピックスを追いかけてみましょう。

      VC関係の話が取り上げられたのはキーノートを含む以下の4つのセッションです。

      全体を簡単に要約すると、
      • VCを使うとVerifier(学校とか企業とか)が各種証明(学歴、職歴など)を簡単・確実に検証できるよ
      • VerifierがSubject(個人)の情報を一生懸命集める事によるプライバシー上の懸念もなくなるよ
      • すでに米国の退役軍人向けの教育プログラム(MILGears)で実証実験が走ってるよ
      • 今はプライベートプレビューだけど、もうすぐみんな使える様になるぞ!
      • VCをLinkedInのプロファイルに追加できるなるぞ!
      みたいな話でした。

      ざっくりみていきましょう。

      まずはSatyaのキーノートです。後半54分あたりからDecentralized Identity Systemの話が出てきます。

      私たちはオープンな分散型アイデンティティシステムを作り上げようとしています。そしてそれは、どんな中央集権的なオーソリティやテック企業からも独立しています。すでに退役軍人向けの教育プログラムでパイロットをしています。


      彼らは自身の検証済みの記録をスマートフォン上のWalletに保管することができ、大学や企業に直接提示することができます。大学はそれ(VC)を数秒で検証することができ、センシティブなデータを保管する必要はありません。また退役軍人たちは、VCをLinkedInのプロファイルに追加することができ、新たな職業を得る機会に役立つでしょう。


      次はVasuのキーノートです。途中16分すぎから出てくるIrinaのパートでIdentityの話があり、17分過ぎから分散型アイデンティティの話です。

      オンライン化に伴いデジタル信頼やプライバシーはとっても重要なものになっています。しかし現在私たちはアイデンティティをデジタルに検証する仕組みを持っておらず、またデジタル・プライバシーは私たちのコントロール外となっています。私たちがパーソナルデータをオンラインで共有する際、企業・組織は記載されている目的外には利用せず、許可なく共有することはないことを約束し、それらのパーソナルデータが盗まれない様に、誤用されない様に保護する努力をします。マイクロソフトはすべての人々が自身のアイデンティティをコントロールできる様にする必要があると考えています。アイデンティティはどんな組織やテック企業からも独立しているべきなのです。これが私たちが分散型アイデンティティ分野に投資する理由であり、すべての人が自身のデジタルアイデンティティを所有し、誰が何の目的でいつアクセスできるか決定できるべきだと考えています。
      年齢、学歴、職歴、クレジットスコア、生体情報は利用者自身のコントロール配下におかれ、政府や大学や企業の様なサードパーティはそれらの情報を検証できる様になります。それらすべてのクレデンシャルはデジタル・カードの様な形でMicrosoft Authenticatorの様なデジタル・ウォレットに保存されます。



      私たちはVerifiable CredentialsとDecentralized Identifiersに関するオープンな標準に基づく自己主権型アイデンティティのヴィジョンを現実のものとするため、Decentralized Identity Foundationと共に活動しています。

      私たちはこの分散型アイデンティティのシステムを多くの顧客と共にパイロットしており、MILGearsの教育プログラムもその一つです。 


      ここでMilGearの人のインタビュー動画が流れた後、VasuがIrinaに今のステータスと今後どうなるの?って聞いてくれます(Good Job!)。「We're currently in private preview, but soon anyone will be able to try it.」素晴らしい!


      次はおなじみJoyです。19分くらいから分散型アイデンティティ関係の話が始まります。


      我々が物理的な世界で行ってきたパスポートや学位やその他証明書のやりとりをデジタル化するにはどうすれば良いのでしょうか?私たちはデジタルにそれらのクレデンシャルを検証するメカニズムが必要です。しかし今日私たちが持っているシステムはデータ漏洩や誤用で溢れています。私たちは分散型アイデンティティシステムとVerifiable Credentialsが解決策になると信じています。コミュニティの努力とオープンな標準をベースに構成され、既存のアイデンティティシステムと簡単に接続することが可能です。それはオープンな標準技術を用いており、マイクロソフトを含むどんな組織も支配することはできません。そして、それはすでに現実のものとなっているのです。


      ここでやはりMILGearsの事例の話。どこにVerifiable Credentialsを提示したのか確認することができます。


      退役後、大学や企業に就職する際に、軍がIssuerとなってそれまでの学歴や経歴を証明する、という形態の様ですね。

      退役後、高等教育や企業への就職する際、大学や企業は学歴や軍でのトレーニング履歴にアクセスする方法がありませんでした。そのため、彼らは証明書などのドキュメントを収集し確認する長いプロセスを必要としていました。そして、多くの場合、それらのプロセスは紙をベースとしており、数ヶ月を要することもありました。

      このプロセスをデジタル化することにより、彼らの待ち時間を減らすだけでなく、自身のデータに関するコントロールを行うことができる様になりました。大学がデータを収集し、保管し、保護する必要がなくなったのです。


      ここでMILGearsのデモです。ここでMILGearsが保持している記録をVerifiable Credentialsとして発行します。

      QRコードが表示されるのでMicrosoft Authenticatorで読み込むとカードの形でVerifiable CredentialsがAuthenticator上に追加されます。

      次は大学にVerifiable Credentialsを提示します。こちらもQRコードを読み込むとVerifiable Credentialsが提示され、検証済みのデータとして大学側へ連携されます。


      デモに続いてテクニカルな話をMelanieさんから。必要なのはAzure Active Directoryサブスクリプション(正確にはPremium P1以上)とKeyVaultだけ(こちらも正確にはStorageは必要)。やるべきことはたった3つ。KeyVaultでキーペアの作成をする、Rulesファイルを作る、Displayファイルを作る、とってもシンプルでしょ、的なデモです。
      こちら、Rulesファイルですね。まぁ、確かに簡単な構造のjsonです。

      こちらはDisplayファイル。こちらも非常にシンプルなjsonファイル。Authenticatorに表示されるカードのロゴとか色を決める感じですね。


      というところでJoyのキーノートは終了です。

      最後はMicrosoft Mechanicsですが、こちらも結局Joyががっつり話をします。
      中身的には、W3Cの標準をちゃんとみてるよ、という話とこれまであったMILGearsの事例、KeyVault、RulesとDisplayなど実装にかかる話のおさらい的な感じのセッションです。

      MILGearsの事例をベースにIssuer=MILGears/Subject(Holder)=退役軍人/Verifier=大学など、と関係性を解説してくれています。わかりやすい。

      ブロックチェーンとの関係も最後に少しだけ触れられます。基本的にDID Documentと公開鍵の置き場所として使ってるだけです。



      全体的にまだ詳しいところは触れられない感じでしたが、こうして動いている姿を見ることができると非常に面白いですね。MILGearsのケースも非常に面白いと思います。退役軍人っていうともっと年寄りでそのまま隠居する?ってイメージでしたが結構若い間に退役して、その後大学に行ったり企業に就職したりするケースもあり、その場合に身元保証を軍がやる、というのは日本にいるとあまりイメージが湧きにくいとは思いますが、話を聞いてみると納得、という非常に良いユースケースだと思います。

      DID/VCはとても面白いテクノロジだとは思いますし、可能性も感じますが、別にDID/VCじゃなくても良いじゃん、というケースばかりなので今後DID/VCならではのユースケースがもっと研究されると良いな、というのが全体的な感想でした。




      Viewing all 769 articles
      Browse latest View live