2019年6月27日木曜日

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

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

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のサポートに期待ですね。

2019年6月26日水曜日

Identiverse 2019参加メモ(Day1)

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

 今週ワシントンDCで開催されているIdentiverse 2019にきています。私はまだIdentiverseがCloud Identity Summitと呼ばれていた2016年から合わせて通算で3回目の参加となります。(昨年度はスピーカーとしての参加でしたが、今回は純粋にオーディエンスとしての参加なので、大いに楽しみたいと思います)

尚、今年は10周年ということで会場のあちらこちらに10周年を祝うモニュメントがあったり、毎年恒例のTシャツも10周年記念モデル?となっていたりしてお祭りムード全開です。(残念ながら例年おもしろTシャツのデザインをしていたPing Identityの方が退職されたとのことで、今年は1種類だけでした)

10周年記念オブジェ

10周年記念Tシャツ

しかし、何と言っても今回の目玉は最終日に予定されているスペシャルゲスト、Steve Wozniakのスペシャル・キーノートです。
こちらは最終日に改めてレポートします(体力が持てば・・・)


と、言うことで初日の参加メモ(と言うか旅行日記)です。

◆Identiverseとは

まず、Identiverse(旧Cloud Identity Summit)をご存知ない方のために簡単にイベント自体の説明をしておきます。詳細はこちらに書かれている通りですが、ざっくり言うと「デジタルアイデンティティやセキュリティ分野のリーダーやユーザーが集まって来るべきデジタル世界のVisionやテクノロジーについて語らう場」で、元々はPing Identityが主催するCloud Identity Summitとしてスタートして今年で10年、200以上のセッションがあり、2000名以上の方が参加するEuropean Identity & Cloud Conferenceに並ぶグローバルで最大規模のアイデンティティ・イベントです。

日本人も10名程度ではありますが、毎年参加されています。(ここでしかお会いしない方々もいたりして・・・)

また、グローバルなアイデンティティ界隈のリーダーの方々にも直接あって近況の交換をすることのできるIDマニアにとって非常に重要なイベントでもあります。
今年も初日のレジストレーションに並んでいる時にSalesforceのVPのIan Glazerに声をかけてもらったり、廊下でUnikenのNishantと話をしたり、MicrosoftからAuth0に移籍して早1年、我らがVittorio Bertocciと写真を撮ったり、と日本ではなかなかできない体験ができます。

◆Day1で参加したセッション

今回は奇跡的に時差ボケ解消に成功したので、初日から力つきることなく朝から晩まで通してセッション参加しました。

簡単な感想などを添えてそれぞれのセッションを紹介します。
ちなみにアジェンダはこちらから見ることができます。

  • Introduction to Identity Part 1 / 2 by Ian Glazer, Pamela Dingle, Steve Hutchinson
    • 言わずと知れた大御所によるデジタルアイデンティティとはなんぞや、と言う解説セッション。
    • 標準技術から利用シーンまで網羅的かつわかりやすく解説してくれたので初学者に取っては非常に貴重な機会だったと思います。
    • それなりに広めの部屋でしたが立ち見が出るほどの大盛況でした。
    • かい摘んで解説すると、こんな感じでした。
      • B2Eの世界における従業員IDの管理のようなトラディショナルなID管理から、B2Cの世界における顧客IDの管理のようなモダンなID管理への潮流があり、これからは「個人にフォーカスしたID管理」が主流になってくる
      • B2E、B2B、B2Cのそれぞれの世界におけるID管理を「Admin-Time(管理時の目線)」と「Run-Time(実行時の目線)」で深掘り、関連するID管理の実施事項を解説してくと言うスタイル
      • 管理と言う目線では以下のキーワードについて概要及び技術標準(SCIMなど)を解説(Ian Glazerが担当)
        • Source of Truth(アイデンティティ情報の源泉)からディレクトリやアプリケーションなどの各種レポジトリへのプロビジョニングの流れ
        • その前段にあるIdentity ProofingについてB2E、B2B、B2Cでの違い
        • 権限管理、ロール管理、アイデンティティ・アナリティクス、特権ID管理
      • 利用時の目線では同じく概要から標準を解説(Pamela Dingleが担当)
        • 認証・認証要素(Active Factor/Passive Factor)とAdaptive Authenticationについて
        • シングルサインオンとは
        • APIセキュリティと委任(WS-Trust vs OAuth2.0)
        • UXについて(Discovery時のNASCAR問題、同意取得、プロファイル管理、登録やリカバリのセルフサービス化など)
      • 最後にSteve HutchinsonがAdmin-TimeとRun-Timeを合わせて全体像を語る、と言う締め

  • Modern Identity for Developers 101 by Vittorio Bertocci
    • 言わずと知れたVittorioのセッション
    • 旧来のIdentityシステムからモダンなアーキテクチャへの移り変わってきた理由をわかりやすく解説
      • 旧来はネットワーク境界の中にシステムがあり、各システムがアイデンティティ関連の機能(ユーザーストア、認証機能など)を持っていた
      • その後、複数のシステムを横断的に使いたい、と言う要望に答えてディレクトリシステムやKerberosなどネットワークレイヤに近い層でシングルサインオンを実現
      • しかしクラウドやB2Bなどネットワークの境界を超える必要が出てきたので、Federationテクノロジーが必要になってきた(モダン・アイデンティティの世界)
    • Developer向けのセッションなので、モダン・アイデンティティの世界を支える各種要素(Identity ProviderやRelying Party、id_token、access_tokenとセッション管理など)の基本的な考え方を実際のデモ(Auth0とASP.NET Coreアプリ)をFiddlerでトレースしながら解説

  • Google master class: Enabling BeyondCorp in your organization today by Google
    • ベンダーセッションなので製品・サービスに特化した解説
    • Vittorioのセッションでもあった通り、もはやネットワーク境界がセキュリティの境界となり得ない世界(Identity is the new perimeter)となってきているので、VPNやFirewallではなくアイデンティティ・アクセス管理とデバイス管理を統合的に行うことでセキュアな世界を作りましょう、と言うのがBeyondCorpの基本的な考え方
    • Identity、Context、Rules Engine、Enforcement pointを経てアプリケーションやデータへ到達できる、と言う流れ(以下、概要)
      • Identity : 利用者のアイデンティティ。Cloud Identityが該当
      • Context : 利用者がどのような状態なのか(デバイス状態やネットワーク)。Device Trustの設定など
      • Rules Engine : IdentityとContextに応じて必要な認証や認可ポリシーを判断するためのエンジン。Access Control Managerで設定
      • Enforcement point : 判断結果の応じたポリシーを実行する。Cloud IAP、Cloud IAM、VPC Service Controlなどで対象システムやAPIに応じて制御を行う
    • 最後にデモとして特定のバージョン以上のMacOSからでないとGmailが開けなくなる、と言うようなシナリオを紹介

  • US Army: The secrets of a Successful ABAC Deployment by Accenture Federal Service, NextLabs
    • 事例セッション
    • US ArmyのSAPシステムの権限管理をNextLabsのソリューションを使ってABACで最適化したよ、と言う話
    • ABACの基本的な考え方はNIST SP800-162の通り。XACMLベースです。
    • やりたいことはRealtime SoD、Realtime continues authentication/Risk-aware authorization
    • ベストプラクティスは以下の通り
      • 属性のクオリティは大事
      • ポリシーは100個以下におさめて再利用可能な設計をすること
      • RBACとABACは共存できる
    • US ArmyではNextLabsのソリューションを使い、SAPの標準の権限管理のさらに上位のレイヤーで権限管理を行った
    • 最終的にはこんな感じ
      • 権限管理に使った属性は5つ未満
      • ポリシーは10〜20個の間
      • 属性はGRCで管理

  • Decentralized Identity: Intersection of Identity and Distributed Ledger by Microsoft
    • マイクロソフトによるDIDのオーバービュー
    • 今日のアイデンティティに関する3つの課題
      • Too many passwords
      • Data ownership, privacy
      • Data oversharing
    • DLTはこれらの課題を解決できるのか?と言う問いに答えるのが、Identityと分散台帳をとり持つDecentralized Identity
    • DID AuthやVerifiable Credentialsを使うことである程度上記の課題が解決できそう。MSも最近IONを出したよ
    • しかし残課題として、UXやRP側から見たExperienceの改善や、アカウントリカバリーや鍵のローテーションの問題があるので、頑張って対応していく
    • そして、DIDはPIIなのか?という話も今後議論されていく問題。。。

  • Delivering a Trusted Digital Identity System by Mastercard
    • この辺りになると疲労度マックスなのであまり頭に入ってこなかったです。。。
    • 金融機関と言うよりテック企業になってきていて、デジタル空間での信頼を従来の社会と同様に作っていく、と言う話。
    • マスターカードのロゴのオレンジの丸は信頼を表している?と言うような話をしていた気がします
  • Throwing away the Clipboard : Digital Identity & Blockchain for Healthcare by Aetna, TrustedKey
    • 医療に関連する情報のポータビリティをTrustedKeyを使って実現しよう、と言う話(ただし、電子カルテの代わりになったり、ブロックチェーン上に医療履歴を載せようと言う話ではない)
    • 解決したい課題はユーザの利便性。
      • 保険証や本人確認書類を何度も提示しないといけない状態を解消したい。実際の医療行為を受けている時間より手続きを待っている時間の方が長いのは勘弁してほしい。
        • 医者に行く前のオンライン予約
        • 病院の受付
        • 薬局の受付
        • 医療履歴を管理するWebサイトへの登録
    • 医療機関、薬局などがIdentity Issuerとなり、TrustedKeyの提供するウォレットに情報をストア(ブロックチェーンベース)
    • 各種機関やオンラインサービスへQRコードを使って情報を提示することでUXを改善できる

  • Fastfed - A new standard to make SSO easy by AWS
    • OpenID FoundationのFastFed WGの発表
    • 現状、SSOを有効化しようとすると、IdP側に設定をした値をコピーしてRP側に設定、RP側の設定結果をIdP側にまたコピーして、、と言う流れになり非常に煩雑
    • FastFed WGでは設定や属性マッピングの自動化を行うための標準を検討している
    • AWSへのSSOをGoogle IdPで実施するデモを披露
      • AWSコンソールからGoogleアカウントを入れるだけで自動ディスカバリ〜自動設定が行われる
    • 個人的に非常に期待しているWGだったりするので、本格的に実装されてくるのが楽しみです
  • Self Sovereign OpenID Connect - a ToDo List by Nat Sakimura
    • 米国OpenID Foundationの理事長である崎村さんのセッション。
    • Self Sovereignってみんな騒いでるけど、ブロックチェーン=Self Sovereignじゃないよ、OpenID Connectでもいいよ、と言う話
    • モデルとしては、こんな感じ
      • SIOPを中心とした世界観
      • CP(Claims Provider)とIdP(SIOP)を明確に分離して、間をAggregated ClaimとかDistributed Claimで繋ぐ
    • ただ、まだまだやることもあって、以下がToDo List
      • SIOPを簡単にCPへレジストレーションできる仕組み(Dynamic Client Registration)
      • SIOPが発行するSelf IssuedなIdentifier(公開鍵のハッシュ)とCPの属性のバインディングの方法
      • 過去に遡った署名の管理(ブロックチェーンの出番かも)
      • 鍵のリカバリの仕組み
      • SIOPがオフラインでもRPが属性を取得できる仕組み
        • 基本的な考え方はDistributed Claimの利用。RPが直接CPへ問い合わせできる
      • SIOPのアドレスの解決
        • ブラウザ設定とリクエストヘッダーで解決できるような仕組みが良いのではないか?



とりあえず初日はこんなところです。


ちなみにワシントンDCの街中は結構坂もあるので、電動スクーターや電動自転車のシェアリングサービスがそこら中にあります。以前はカーシェアだけしかやっていなかったLyftがスクーターに手を出したりしていてまさにMaaS元年って感じなのかも知れません。(写真はBird)

2019年6月18日火曜日

Sign In with Apple連携その後。続々とIDaaSと連携~Auth0編

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

前回のポストでAzure AD B2CとのApple ID連携を紹介しましたが、その後も各社が情報を出してきているのでUpdateしておきます。
やっぱりApple ID強いですね。

各社公式記事


特にAuth0はカスタムコネクションではなく、ベータ版ながらもビルトインでの接続を早くも出してきています。

話は変わりますが、先日のAuth0のCEOのEuginioさんが来日された時に発表されたLINE Loginとの連携についても早くビルトインで繋げられるようになればいいですね。

現状LINE Login連携はカスタムコネクションで実装する必要があるので、今すぐつなぎたい人はこちらで。


と、話を元に戻します。
今回はAuth0のビルトインコネクションでのApple Id連携を試してみます。

◆コネクションの有効化~設定

ダッシュボードを開き、ConnectionsよりSocialを選ぶとApple[BETA]が出てきますので、このスイッチをONにします。

続いて、前回Azure AD B2Cに設定したのと同様にclient idなどのApple側の値を設定していきます。
設定するのは、
  • Client ID
  • Client Secret Signing Key
  • Apple Team ID
  • Key ID
  • 取得する属性(名前、メールアドレス)※要するにscopeにnameとemailがつきます(なんだかうまく動いていない気がします)
ポイントはAppleからダウンロードした秘密鍵を張り付けるだけでclient secretを自前で生成しなくて済むのが非常に便利です。




設定が終わってSAVEをするとTRYボタンが現れるので、クリックすると設定が上手く行っているか実際にログインして確認が出来ます。



「It Works!」が出ればOKです。

◆実際のアプリケーションに組み込む

Auth0のダッシュボードからアプリケーションを作成し、Connectionsタブを開くと先ほど設定したAppleが出てきますのでスイッチをONにします。※今回は昔作ったアプリケーションを流用していますので、アプリケーション名が変ですw


これで設定は終わりです。
実際のアプリケーションへアクセスするとAuth0のログイン画面が表示され、その中にAppleが出てくれば成功です。
※ちなみに上2つはカスタムコネクションで設定したLINE LoginとApple Id連携で、今回設定したApple Id連携は一番下のボタンです。


まだ属性の取得周りなど上手く動いていなさそうなところもありますが、今後ブラッシュアップされてくると思うので、期待しておきたいと思います。

2019年6月10日月曜日

Sign In with AppleとのID連携現状のまとめ&Azure AD B2C連携

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

WWDC'19でSign In with Appleが発表されてから皆Apple IDに夢中※1ですね。まぁ、アプリのレビューガイドライン問題※2とか色々とありますが、日本人は不思議とiPhoneが大好きなので下手したらGoogleアカウントより普及してるのかもしれません。(パスワードを覚えているかどうかは別でしょうけど)

※1.今日(6/9)時点で私が把握しているSign In with Apple関係の記事


※2.問題の概要
「サードパーティログイン採用のアプリはSign In with Appleを使うことを義務付ける」というレビューガイドラインが出たこと。Apple曰く、Relyingパーティに一切の個人情報を提供せずに認証だけを行うことができるためプライバシーに考慮している、という言いっぷりですが、逆にAppleが誰がどのアプリにログインしているかを把握するってこと?という気持ち悪い感じになっています。また、アプリ開発者はSign In with Appleを実装しなきゃダメ、という変な強権発動も流石Apple、という感じです。(個人の感想)


とは言え、Sign In with Appleが世の中に出てきたのでとりあえず色々とつないでみたくなります。私もAzure AD B2CとAuth0にはとりあえず繋いでみました。

というわけで、今回はAzure AD B2Cとのつなぎ方を解説します。
(先に書いた英語版のblogの日本語訳です)

********************
WWDC'19でアップルが「Sign In with Apple」という機能を公表しました。このポストではこの新しい機能をどうやってAzure AD B2Cで使うかを説明したいと思います。もちろん、この機能をIdentity Experience Framework(カスタムポリシー)を使って構成することもできますが、今回はビルトインポリシーのOpenID Connect IdP連携の機能(Preview)を使って構成します。


最初にどのような動きになるのかビデオに撮ってみました。



前提事項

  • アップル開発者アカウント(最低1年のサブスクリプション契約が必要)
  • Azure Active Directory B2Cのテナント
  • Azure WebApps等のWebホスティングサービス(Metadataのアップロード用)

アップル開発者コンソールでクライアントを構成する

「Sign In with Apple」はOAuth/OpenID Connect的な仕組みを採用しています(完全にプロトコルに準拠している訳ではなさそうですが)。そのため、それらのプロトコルに慣れ親しんでいる方であれば、実装するのはそれほど難しい話ではありません。

アップル管理者コンソールでOAuth/OIDCのクライアントを作成することが出来ます。手順については先に紹介したOktaのブログを参考にしました。とても良いブログだと思います。
https://developer.okta.com/blog/2019/06/04/what-the-heck-is-sign-in-with-apple

構成するための手順は以下の通りです。
  1. Sign In with Appleを有効にしてApp Idを登録する
  2. Service Idを登録する(これがclient_idとして使われます)
    • ドメインの所有権を確認する
    • redirect_uriを構成する
  3. Sign In with Appleで利用する鍵を登録する
  4. 登録した鍵をダウンロードして署名付きJWTを作る(これがclient_secretとして使われます)

Azure AD B2C上のIdentity Providerを構成する

Azure AD B2CでIdentity Providerを構成する前に、Apple Idに関するディスカバリ・ドキュメント(metadata)を作っておく必要があります。なぜなら、Appleは現在のところmetadata(/.well-known/openid-configuration)を公開していないためです。

私はAzure WebApps上に作成したmetadataを公開しましたが、任意のWebサービスを使うことが可能です。

Azure AD B2CのビルトインのOpenID ConnectのIdPを構成する際、metadataには以下の情報を記載する必要があります。
  • Issuer
  • Authorization Endpoint
  • Token Endpoint
  • Jwks Endpoint
また、metadataを公開するURIは./well-known/openid-configurationで終わっている必要があります。

こちらが作成したmetadataです。

さて、これでAzure AD B2Cのコンソールからビルトインポリシーを構成する準備が整いました。

新しいIdentity Providerを追加する。

OpenID Connect(preview)を選択する


metadata uri、client_id、client_secretを設定する。


sub属性を必須とされている属性へマッピングします。現状、Appleは名前やメールアドレスをid_tokenの中に含めて返してこないのでsub(pairwiseな値)しか使えません。

作成したIdPを利用する様にUser Flow(ポリシー)を構成する

Azure AD B2Cのコンソールでの最後のステップはUser Flowを構成することです。今回はSign In and Sign Up(v2)のポリシーテンプレートでApple IdPを使う様にフローを構成しました。

アプリケーションへ渡すための属性フローを構成します。


これで設定はおしまいです。

Azure AD B2Cに登録したアプリケーションから作成したポリシーを指定してID連携をすればApple Idでのログインが出来るようになっているはずです。


********************

と、言うことでまずはAzure AD B2Cでの構成方法を紹介しましたが、Auth0など他のものへの組込みについても解説できればと思います。(既に他の方も紹介されていますが)

2019年5月27日月曜日

de:code 2019でKYCとDecentralized Identityの話をします

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

先日のEuropean Identity & Cloud Conferenceでの登壇に引き続き、今年もde:code 2019でお話させていただきます。Webサイトには所属組織名として会社名も書いてありますが、今回は基本的にOpenIDファウンデーション・ジャパンの帽子でのお仕事です。

春のde:code、秋のTech Summitと日本マイクロソフトの大型イベントでここ数年連続でセッションを持たせていただいておりますが、大型のイベントでの登壇はオーディエンスの属性も様々なので内容とレベル設定に気を使いますね。

今回は「これからのKYCとIdentity on Blockchainの動向」というタイトルで、金融機関等におけるKYCの課題とIdentity on Blockchain、いわゆるDecentralized Identityが解決するための手段になりうるのか?という観点で最近の動向についてお話させていただこうと思います。そして、この内容を「レベル200=初級者向け」に解説しなければならない、というまた難題を・・・。(前回レベル詐欺と言われたので今回は反省して細かい部分は最低限に抑えるつもりではあります)

内容的にはOpenIDファウンデーション・ジャパンのKYCワーキング・グループで議論している内容や、先日ポストした自己主権型アイデンティティの話を中心に、KYCにおける属性情報の受け渡しと検証を誰がどうやって簡単かつ確実にするのか?みたいな話について私の考えをお話しようと思っています。

フェデレーションの様に一部のIdentity Providerに依存するモデルから、自己主権型アイデンティティでの主権・自由と引き換えに責任を自分で負うモデル、情報銀行の様に属性情報の管理を委託するようなモデルなど、色々な考え方への遷り変りの話なども少し紹介できればと思っています。


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

2019年5月11日土曜日

European Identity & Cloud Conference 2019でBYOID+DIDの話をします

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

昨年に引き続き今年もミュンヘンで開催されるEuropean Identity & Cloud Conferenceでお話させていただくことになりました。

公式サイト
 https://www.kuppingercole.com/events/eic2019

アジェンダを見ていると、AIとDecentralized Identity(ブロックチェーン)が半々くらいですかね。

私は昨年に引き続きBYOID(Bring Your Own Identity)のテーマでケーススタディ+昨年シンガポールで開催されたConsumer Identity World APACで少し頭出しをしたBYOID+Decentralized Identityのテーマで、動くものを少しお見せしようと思っています。

こんな感じの仕組みです。

外部ユーザを招待してOffice365(Teamsとか)を使ってもらうシナリオの一種ではあるんですが、通常のAzure AD B2Bでゲストの招待だとドメインのホワイトリストやTOU(Term of Use/利用規約)への同意くらいしか相手を確認する方法が無いので、その部分でDecentralized IdentityのVerifiable Claimsを使って証明書を提出させて本人確認を行う、というシナリオです。

このことにより、外部ユーザは組織アカウントでもLINEやFacebookなどの個人アカウントでのサインアップ+証明書を提出することによりTeamsやAzure ADに参加したPCへのログインなどが出来るようになります。この辺りをAzure AD B2CやAzure Functionsなどを使って自動化をしています。
外部IDを受け入れる側の組織ではID管理やパスワード管理をする必要が全くありませんので、組織の形態にもよると思いますが使える場面も出てくると考えています。

こんなことも出来るようになります。


ちなみにID Proofing周りはOSSテクノロジー社のLibJeIDとuPortを使って実装しています。

おいおいこの辺りの話しも解説したいと思います。
(月末に開催されるde:code 2019でも触れる予定です)

2019年4月26日金曜日

自己主権型アイデンティティとブロックチェーンの話し

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

ちょうど先日のidconでこの辺りの話をしたので、少し自分のためのおさらいの意味も込めて整理しておこうと思います。

まず背景として、昨年度から理事を務めさせていただいているOpenIDファウンデーションジャパンで、本人確認に関する新しいワーキンググループである「KYC(Know Your Customer) WG」を2019年1月に立ち上げ、WGリーダーを務めさせていただいております。
WGでは犯罪収益移転防止法や携帯電話不正利用防止法など各業界における本人確認のルールの調査や、Decentralized Identifier(DID)などの最近KYCと関連づけて語られる技術の調査をしたりしている訳です。
ちょうどパスポートの真正性確認に使う公開鍵を外務省が公開する・しない、という話が盛り上がっているあたりの領域です。

本人確認とアイデンティティとブロックチェーン

そして、何故かこの領域になると、自己主権型アイデンティティ(Self Sovereign Identity/SSI)とか、先ほど出てきたDIDだ、とかいうキーワードがどこからともなく持ち上がってきてやたらとブロックチェーンが銀の弾的に扱われてしまう、というのがID業界?の中の人としても結構な謎だったりするわけです。

そもそもブロックチェーンを仮想通貨以外にも適用しよう、という話は数年前からあり、例えば2016年のCloud Identity Summit 2016(CIS、現Identiverse)でもPingIdentityがSwirds社と提携してセッションの正当性の管理にHashgraphを使うPoCをやったりしていました。以前このブログでも少し紹介しましたね。

また、自己主権型アイデンティティという話もUser Centric IdentityとかDoc Sealsが提唱したIntention EconomyのVRMという形で以前からあった文脈と繋がっているものだと思われますので、特にブロックチェーンの出現によって新たに出現した話ではありません。

そして、当然の事ながら本人確認とブロックチェーンにはかなりの距離があります。ブロックチェーンが出てきたから本人確認が劇的に変わるわけでもなさそうですし。

ブロックチェーンで解決できるアイデンティティにまつわる課題とは?

となると、結局ブロックチェーンをアイデンティティの領域に応用することで何がうれしいんだろうか?という話になるわけですが、よく出てくる話としては、

  • プライバシーの保護
  • アイデンティティの証明

あたりがメジャーなのかな?と思います。他にも先のPingIdentity+Hashgraphでシングルサインオンのセッション管理を分散データベースとしてのブロックチェーンで行うことでシングルログアウト問題を解こうとした、というような話はありますがいまいち普及していません。(わかりやすいユースケースだったので個人的には良かったと思うのですが)

それぞれの話題を見ていくと何か見えてくるのか?と思うのですが、まだブロックチェーンの必然性が見えてきていないな、というのが個人的な感覚です。

プライバシーの保護とブロックチェーン

ここはまさに自己主権型アイデンティティという話なわけですが、課題意識としては、「個人が自分の意思でコンテキストに応じた自己像を提示できるようにする」、そして「個人の意思に反してコンテキスト外の自己像を推測されたり形成されたりしたくない」という話なので、必要なこととしては、

  • ユーザがアプリケーション(Relying Party)へログインする際に、Identity Providerへ認証要求を行うことによる、Identity Providerによるユーザ行動の把握を防ぎたい
  • ユーザがアプリケーション毎に提示するアイデンティティを選択的に形成したい(要はどの属性を渡すか、もしくは値そのものを渡さなくてもアプリケーションが要求している属性を満たすことを証明する)
  • アプリケーション同士が結託することで属性を補完しあって提示するつもりのないアイデンティティを勝手に形成されることを防ぎたい

というようなことなわけです。

こうなってくると、ブロックチェーンというよりもゼロ知識証明とか仮名(SAMLのnameid-formatのtransientとか、OpenID Connectのsub_type=pairwise)の方がしっくりくる領域です。今更ながら2012年くらいに盛り上がったU-ProveとかIdentity Mixerバンザイです。そういえば昔Kantaraのセミナで話したなぁ。

アイデンティティの証明とブロックチェーン

一方でアイデンティティの証明をするためにブロックチェーンを、という話については見方によってはある程度芽はあるのかもしれません。
ブロックチェーンの「一度記録すると変更しにくい」といういわゆるImmutabilityの特徴を考えると、一度発行した属性を過去にさかのぼって改竄する、というような属性値ロンダリングみたいな話は難しくなるのかもしれません。

経済産業省が主催で2月に開催されたブロックチェーン・ハッカソン2019では学位や職歴をブロックチェーンを使って確実に証明できないか?ということがテーマでした(私も審査員+ワークショップの実施という形でかかわらせていただき、非常に面白かったです)。つい先日、調査報告書も公開されたので時間がある方は見てみると面白いです。

ここはEthereum勢はERC725や735という形でこの領域に注目していて、OriginProtocolがPlaygroudを公開していたりもして、今後も発展していく可能性は十分にあるのかな?と個人的には思います。

しかし、よく考えると結局はアイデンティティの発行元がきちんと発行したアイデンティティである、ということの担保はこれまでもデジタル署名でしてきたわけで、ブロックチェーンがあるから劇的にこれが改善するわけではありませんし、ブロックチェーン上に発行されたアイデンティティ(属性の値)そのものを全部公開する、というのはあまりにも乱暴なわけです。

PKIを補完する意味でのブロックチェーン

そうなるとどうやって落としどころをつくるんだ?というだんだん本末転倒な話の方向に進んでくるわけですが、「あー確かにな」という課題の一つである「アイデンティティの発行元が消滅したり、発行元によってアイデンティティを否認や改竄されるリスクへの対応」というユースケースがにわかに持ち上がってくるわけです。

この辺りが、ID2020プロジェクトでUNHCRがMicrosoftとAccentureと共同でやっているような難民=国家(アイデンティティ発行者)によってアイデンティティを否認された人々の身元を保証するためにブロックチェーンを活用しよう、という話につながったり、先の経産省のハッカソンの大きなテーマである少子化に伴い教育機関がつぶれていくという予想がつく中で如何にして自分の学位を証明するか(要は卒業した大学が消滅してしまった場合に誰が卒業証明書を発行してくれるのか?)という話がブロックチェーンと繋がって出てくる所以だったりします。

確かに、国家等のアイデンティティの発行元によって自分のアイデンティティが消される、という緊急事態(プライバシーに優先するくらいの状況)において自分のアイデンティティを改竄出来ない状態にする緊急避難先としてブロックチェーンを選ぶのは確かに悪くないかも知れません。
また、同様にアイデンティティ発行者が消滅したとしても以前に発行されたアイデンティティ(署名されたアサーション)の検証をするための公開鍵をブロックチェーン上に保管しておけば、誰かが勝手に「過去にこの大学を卒業した。その証明はこのアサーションである。すでに誰も公開鍵を持っていないから署名検証は出来ないけどね」というようなことを言い張るというリスクへの対応は出来るでしょう。

ブロックチェーンも色々、標準化は?

ある程度ユースケースが見えてきたところで考えないといけないのは、ブロックチェーンも色々、という話です。EthereumもありますしBitcoinブロックチェーンもあります。またパーミッションドなのかパブリックなのか、などの分類も様々です。
そして最も重要なのはいかに耐改竄性が高いといってもブロックチェーンの系自体が消滅したりクローズする可能性は当然ゼロではない、というところです。

こうなると、

  • 特定の系に依存しない
  • 必要に応じて系を引っ越せる
ような仕組みというか標準を定めていく必要性が出てきます。

その辺りに取り組んでいるのがDecentralized Identity Foundation(DIF)というわけです。
ここでは主に、リファレンスモデルの策定やDecentralized Identifier(DID)や関連するメタデータ(DID Document)、検証可能なアイデンティティ情報の表現方法(Verifiable Claims/Presentation)などの標準化と、複数のブロックチェーンの系を跨いで存在するアイデンティティ情報のLookupをするためのUniversal Resolver(DNSみたいなもの)の仕組みを定義しています。

この辺りは、先日のidcon(didcon)でお話したので、こちらの資料を見て頂ければと。(まだ私の調査も浅いのと、DIF自体の定義も議論の途中で非常にふわふわした状態ですが)


当日のまとめはこちら

いずれにしても、この領域が今後どうなっていくのか?については興味深く思っているので、引き続き調べて行こうと思います。


2019年4月11日木曜日

[Azure AD B2C]各種エンドポイントにつくポリシー指定用パラメータが邪魔な件

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

完全に自分メモです。
Azure Active Directory B2Cって色々と器用なことが出来るのですが、その動作はポリシー(ユーザーフロー)という単位で定義され、クライアント(アプリケーション)から呼び出されます。
図)標準のポリシー(ユーザーフロー)定義

図)カスタムポリシー

サインアップとか、サインインとか、プロファイル編集などなど、各種動作を統一されたエンドポイントで実行するために、このポリシーを各種エンドポイントを呼び出す際、「https://hoge.b2clogin.com/hoge.onmicrosoft.com/oauth2.0/v2.0/authorize?p=B2C_1_XXXX」のようにクエリパラメータにp=ポリシー名という形でポリシーを指定して動きを変えていきます。

※ちなみにポリシー名のPrefixは、
・標準ポリシー(ユーザーフロー)だと、「B2C_1_XXX」
・カスタムポリシーだと、「B2C_1A_XXX」
です。

しかし、OAuthやOpenID Connectの非MS製ライブラリを使うとき、かなりの確率で問題になるのが、エンドポイントにクエリパラメータが付いた状態がスタート、というところです。

なぜなら、よくあるライブラリにはエンドポイントアドレスを設定、client_idなど各エンドポイントへのアクセスを行う際にクエリ指定するパラメータは個別に指定、ライブラリが自動的に
 https://hogehoge.com/oauth2/authorize?client_id=aaa....
みたいに連結して動こうとするため、最初からエンドポイントアドレスにクエリが付いているAzure AD B2Cだと、
 https://hogehoge.com/oauth2/authorize?p=B2C_A_xxx?client_id=aaa....
のように?をつけてしまったりするんです。※本来はもともとパラメータが付いているので、追加パラメータは&で繋いでほしいのですが、想定されてないのだと思います。


ということで、今回はAzure AD B2Cのエンドポイントアドレスにクエリパラメータを使わない方法の紹介です。

といっても単純に以下を使うだけです。
(.well-known/openid-configurationのアドレスです。これを叩けば対応するauthorizationとかtokenエンドポイントのアドレスが取れます)

ドメインデフォルト(パラメータあり)パラメータ無
b2cloginhttps://テナント名.b2clogin.com/テナント名.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_ポリシー名https://テナント名.b2clogin.com/tfp/テナント名.onmicrosoft.com/B2C_1_ポリシー名/v2.0/.well-known/openid-configuration
onmicrosoft(非推奨)https://login.microsoftonline.com/テナント名.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=B2C_1_ポリシー名https://login.microsoftonline.com/te/テナント名.onmicrosoft.com/B2C_1_ポリシー名/v2.0/.well-known/openid-configuration


エンドポイントアドレスがかなり長いですが、既存のクライアントとの連携などを行う場合は、こちらを使った方がベターです。

2019年3月26日火曜日

[Azure AD B2C] Custom Policyが遂にGA!

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

Public Preview開始から約2年、ようやくAzure AD B2CのCustom Policy(Identity Experience Framework)がGAしました。


公式アナウンス
 Azure AD B2C custom policies to build-your-own identity journeys reaches general availability
 https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Azure-AD-B2C-custom-policies-to-build-your-own-identity-journeys/ba-p/382791

といっても何のことか、という方もいらっしゃると思いますので、簡単に。

Azure AD B2Cには
・ビルトインポリシー
・カスタムポリシー
の2種類があります。

ざっくりいうと、ビルトインポリシーで出来るのは、
・プリセットされた外部IDプロバイダ(FacebookとかTwitterとか)の利用
・サインアップ、サインイン、プロファイル変更、パスワードリセットというアクション
・OpenID Connectを使ったアプリケーションへのID連携
です。

まぁこれでも十分と言えば十分なのですが、カスタムポリシーを使うことで、
・プリセット以外の外部IDプロバイダの組込み(LINEとかYahoo! JAPANとか、SAML IdPとか)
・複雑なアクション(複数のIDプロバイダのIDの紐づけとか、外部のREST APIの呼び出しとか)
・SAMLなどOpenID Connect以外のアプリへのID連携
など、割りとなんでもできてしまいます。

もちろん、今回のGAでカスタムポリシーのすべての機能がGAしている訳ではありませんが、Azure AD B2Cを使って出来ることが大幅に広がりました。

※現状のリリース状況(Preview/GA)はこちらから確認できます。
https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-developer-notes-custom

まだまだドキュメント等、充実しているとは言えませんが、今後に期待です!



2019年3月25日月曜日

[LINE Login]LINE Developer CommunityでOpenID Connect(+少しAzure AD B2C)の解説をしました

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

そういえば去る3/8にLINE Developer Communityの勉強会でLINE Loginを題材にOpenID Connectの解説をしてきました。(公開資料にはのっけてませんがちょっとだけAzure AD B2Cの話しもしました)

どうもアイデンティティの分野って概念と実装の両方を勉強しないとちゃんと理解できないことが多いので、座学+ハンズオンみたいな感じで勉強する形があっているんじゃないかな?と思っています。

資料とコードはこちらに公開しています。


コード
https://github.com/fujie/line_login

今回はOpenID Connectの基本的な流れを理解してもらうことが目標だったので、特にLINE LoginのSDKも使いませんでしたし、サンプルコードもステップ by ステップでストップしながら流れを理解してもらうことを想定したものなので、プロダクション環境ではくれぐれも使わない様にしてください。。。

ひっそりと申込を開始した割にすぐに定員が埋まってしまったのと最終的にキャンセル待ちが参加できた方の数と同じくらい存在したので、2回目以降の開催も考えていかないとダメですね。(どうしてもハンズオンを入れると1回あたりの人数が絞られますし)

ということで乞うご期待。


早くもクラスメソッドの方がレポートを書いて頂いておりました。感謝です。
 [レポート] 実装して理解するLINE LoginとOpenID Connect入門 に参加してOAuthとOpenID Connectについても学んできた #linedc
 https://dev.classmethod.jp/report/mrmo-linelogin-20190315/

2019年2月6日水曜日

[LINE Login]QRコードログインでメールアドレスもパスワードも不要に!

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

ついにLINE LoginがブラウザシナリオでのQRコードログインをサポートしました!
このことにより、LINEへのメールアドレスとパスワードの登録がない人でもPCのブラウザやスマホの標準ブラウザ以外でWebアプリへのLINEログインできるようになりました。
(永らく待ち望んでいた機能なのでとっても嬉しいです)

公式アナウンス
 https://developers.line.biz/ja/news/tags/line-login/


■従来の制限(ブラウザシナリオ)

従来もQRコードログインはPCやMac、iPad用のLINEアプリへのログインには使えていましたが、PCブラウザやスマホでも標準ブラウザ以外でLINE Loginを使ったWebアプリへアクセスすると、メールアドレスとパスワードを使ってログインする必要がありました。

もちろんスマホの場合はLINE Loginの自動ログイン機能が使える環境であれば、ブラウザからLINEアプリが呼び出されて自動的にログイン、ブラウザへ制御が戻る、という流れでメールアドレス・パスワードを使わないログインが実現できていました。

しかし、この自動ログイン機能はカスタムスキームを使ってLINEアプリを呼び出すところまではOKなのですが、標準以外のブラウザだとLINEアプリからブラウザへの戻す時に戻し先ブラウザの制御を行うことが出来なかったため、標準ブラウザの場合に制限されていました。
ということで、自動ログイン機能を使う場合は、以下の制限があります。
  • iOSの場合
  • LINE 7.5.0未満:アプリ内ブラウザで、LINEログインv2を実装したウェブサイトにアクセスすると、自動ログインできます。
  • LINE 7.5.0以降:アプリ内ブラウザまたはSafariブラウザで、LINEログインv2を実装したウェブサイトにアクセスすると、自動ログインできます。 
  • LINE 7.12.0以降:アプリ内ブラウザまたはSafariブラウザで、LINEログインv2またはv2.1を実装したウェブサイトにアクセスすると、自動ログインできます。 
  • Androidの場合
  • LINE 7.14.0未満:アプリ内ブラウザまたはChromeなどの外部ブラウザで、LINEログインv2を実装したウェブサイトにアクセスすると、自動ログインできます。 
  • LINE 7.14.0以降:アプリ内ブラウザまたはChromeなどの外部ブラウザで、LINEログインv2またはv2.1を実装したウェブサイトにアクセスすると、自動ログインできます。
  • 出典)https://developers.line.biz/ja/faq/


    ■QRコードログインが付かなかったことによる制限

    新規にLINEアプリを登録する時、SMSさえ通じればメールアドレスの登録は必須ではなく、パスワードも不要なため、スマホ・ネイティブな世代の殆どがメールアドレスもパスワードも登録しない状態でLINEの利用を開始していると思われます。
    もちろん、LINEもアカウントのリカバリの容易さなどを理由にメールアドレスとパスワードの登録を推奨していましたが、現実問題登録していないアカウントもそれなりの数、存在していました。(数字は言えませんが)

    上記の制限事項もあり、LINE Loginをブラウザシナリオで実装する際は、ある程度の数「使えない」ユーザが存在することを前提に設計を行う必要がありました。

    以前よりLINEさんにはブラウザでもQRコードログインをサポートしてもらえるようにお願いはしていたのですが、ようやく実現した!!というのが今回の発表です。

    ■早速使ってみる

    では、早速使ってみます。(といっても見た目は地味ですが)

    LINE Loginを使うWebサイトにアクセスするとLINEへリダイレクトされます。
    (ちなみに、QRコードログインを使うには、LINE Login v2.1を使っている必要があります)

    ログイン画面が変わっています。下の方に「QRコードログイン」がみえます!
    早速クリックすると、QRコードが表示されます。(一部マスクしています)

    おもむろにスマホを取り出してQRコードをスキャンします。
    (友達追加の時に使うアプリ内のQRリーダーを使います)

    ログイン確認をされるので、ログインボタンをタップします。
    すると、ブラウザに認証番号が表示されるので、スマホ側で数字を入力します。

    ここで入力します。


    問題なく確認が終わると、ブラウザ側でログイン処理が完了、アプリへ遷移します。



    ということで、メールアドレスもパスワードも使わずにアプリケーションへのログインができるようになりました!
    Microsoftアカウント、Yahoo! JAPANのパスワード・レス・ログインに続いてLINEも同体験を実現してきており、ようやく人類がパスワードを捨てることが出来る日がくる予感がしてきました。

    2019年2月4日月曜日

    Google+のサービス提供終了に伴うbloggerへの影響と本ブログにおける対応

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

    先日アナウンスされた通り、2019年4月でGoogle+のサービス提供が終了しますね。

    ご存知の通り、本blogはGoogleが提供しているbloggerを使っているので、何か影響があるのか調べてみました。
    結果、個人的にはそれほど大きな影響ではなさそうなので、放置することにします。

    ■Googleからの発表内容と本ブログへの影響

    2018年12月の発表、およびその後のメールなどによると、影響と対策は以下の通り。
    ※赤字部分が自身、本ブログに影響がありそうなところ
    ※今後アップデートがある可能性もあるので、一次ソースを見て対策をしてください。(本ポストの内容により影響が出ても責任はもてません)

    • 個人のGoogle+アカウントを持っている人、Google+ページを持っている人
      • 2019年2月4日
        • 新規にGoogle+プロフィール、ページ、コミュニティ、イベントの作成ができなくなる
        • 対策)特になし
      • 2019年4月2日
        • Google+アカウント、ページ等のコンテンツの削除を開始
        • 対策)コンテンツのダウンロードと保存をしておくこと(Googleフォトは消えないので大丈夫)
    • Google+コミュニティのオーナー、管理者の人
      • 2019年3月上旬〜
        • コンテンツのダウンロードと保存が可能になる
        • 対策)ダウンロードしておくこと
    • Google+ログインのボタンをサイトやアプリに配置している人
      • 今後数週間
        • ボタンが機能しなくなる(Googleログインのボタンが代わりに表示されることもあり)
        • 対策)ボタンの撤去。Googleログインのボタンが表示された人はそのまま使える(Googleアカウントでログイン)
    • Google+を使って自身のサイトや他のサイトへコメントを追加している人
      • 2019年2月4日
        • BloggerでGoogle+を使ったコメント機能は使えなくなる
        • 対策)他の機能でコメントする
      • 2019年3月7日
        • 他のサイトでGoogle+を使ったコメント機能は使えなくなる
        • 対策)他の機能でコメントする
      • 2019年4月2日〜
        • 既存のGoogle+で作成されたコメントが順次削除される
        • 対策)ダウンロードして保存しておくこと
    • G Suiteを使っている人
      • ビジネス向けGoogle+はサービス継続(新機能追加、デザイン変更あり)
      • ただし、G Suiteアカウントが外部Google+ユーザと共用しているページやコミュニティ、サークルなどについては一般向けGoogle+と同様に影響を受けるので対策は必要
      • 詳細はこちら
    • Google+ APIを使っている人(開発者)
      • 2019年3月7日
        • 全てのGoogle+ API(Google+ REST APIなど)が停止
        • Google+に関連するscope(例えば、plus.meやplug.login)を使った認可リクエストも受け付けられなくなるので注意

    ■本ブログにおける対応

    特に大きな影響はないので、基本方針は「放置」とします。

    一部影響があるのは以下。

    • プロフィール(私のプロフィール)
      • 対策)Bloggerプロフィールに戻します





    • コメントとリンク(そんなに使っている人もいないと思いますが)
      • Google+アカウントでのコメントは使えなくなります
      • 過去にGoogle+でコメントした人のコメントは消えます(特にこちらでバックアップ、どこかへ移行・公開はしません)
      • Google+への共有はできなくなります




    まぁ、大部分の方には影響ないですね。

    2019年1月31日木曜日

    Auth0でLINEログインを行う(メールアドレスの取得も)

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

    Auth0楽しいです。
    LINE Loginも楽しいです。

    と、言うことでAuth0を使ってLINE Loginを実装してみます。

    ちなみに、Auth0の古田さんが以前書いていらっしゃるQiitaを見ればそのままなんですが、メールアドレスが取れない!という課題が解決していないので、そのあたりもカバーしてみます。

    古田さんのQiita:Auth0でLINEログインを実装してみた(v2.1対応)
     https://qiita.com/furuth/items/6df4334c3821ffc69d9c

    ざっくり解説すると以下のとおり実装します。細かい手順は古田さんのQiitaを見てください。

    1. Auth0のExtensionの「Custom Social Connections」を使う(流石にLINEはビルトインされていない)
    2. LINE側に登録したClientID、ClientSecretをAuth0のExtensionに設定する
    3. Auth0のExtensionは基本的にOAuthなので、ユーザ属性はLINEのProfileエンドポイントから取得する

    LINEの場合、この3番が曲者ですね。
    以前、紹介したとおり、LINE Loginでメールアドレスを取得できるようにはなりましたが、あくまでid_tokenの中に入っており、Profileエンドポイントからは取得できないんです。

    以前のポスト


    と、言うことでAuth0のExtensionの中のプロファイル取得スクリプトでなんとかするしかありません。

    が、このプロファイル取得スクリプト、先に書いた通り、OAuthな前提なので、access_tokenを基にProfileエンドポイントへアクセスして属性を取得するようなサンプルしかありません。

    今回はここでid_tokenをとってきて中からメールアドレスを取り出したいので、以下のようにスクリプトを書き換えます。access_tokenは使いません。
    function(accessToken, ctx, cb) {
      var i = JSON.parse(jwt.decode(ctx.id_token));
      var p = {
        user_id: i.sub,
        name: i.name,
        picture: i.picture,
        email: i.email
      };
      cb(null, p);
    }
    

    ちなみに、LINEが返してくるid_token(JWT)はヘッダにtyp: JWTの記載がないので、node.jsのjsonwebtokenライブラリがうまくjsonオブジェクトに変換をしてくれず、stringで結果が返ってきてしまします。そのため、2行目でJSON.parseをつけてjsonオブジェクトに変換しています。
    ※Azure ADなどの場合はtyp: JWTがヘッダにあるので、JSON.parseは不要でした。jwt.decodeの第2引数にjson: trueってつけるとうまいことやってくれる、というドキュメントは見たことがあるんですが、今回は上手く動きませんでした
    ※場合によってjwt.decodeで怒られることがあるみたいなので、その場合は
     var jwt = require('jsonwebtoken');
     を追記してみてください。

    Tryボタンで動作確認ができ、ログインするとこんな感じでid_token内の属性が取得できます。

    ※(追記)スクリーンショットがわかりにくい(メールアドレスはTryでは出てこない)ので、ユーザ・プロファイルの画面を張っておきます。