ECDSAに対応したゼロ知識証明の論文がGoogleから出ています

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

AAMVAのモバイル運転免許証のガイドラインでも触れましたが、mdocやSD-JWTのリンク可能性へ対応するためには今後ゼロ知識証明が大切になります。

年末にGoogleの研究者が

Anonymous credentials from ECDSA

というタイトルでペーパーを出しています。

https://eprint.iacr.org/2024/2010

AIでイラスト生成すると色々とおかしなことになって面白いですねw

アブストラクトの中からポイントを抜粋すると、従来のBBS+では暗号スイートへの対応に関する要件が厳しかったのでレガシーで対応できるようにECDSAでもできるようにしたよ、ということのようですね。

Part of the difficulty arises because schemes in the literature, such as BBS+, use new cryptographic assumptions that require system-wide changes to existing issuer infrastructure.  In addition,  issuers often require digital identity credentials to be *device-bound* by incorporating the device’s secure element into the presentation flow.  As a result, schemes like BBS+ require updates to the hardware secure elements and OS on every user's device.

その難しさの一部は、BBS+などの文献に記載されているスキームが、既存の発行者インフラストラクチャにシステム全体にわたる変更を必要とする新しい暗号化前提条件を使用していることに起因しています。さらに、発行者は、デバイスのセキュアエレメントを提示フローに組み込むことで、デジタルID認証をデバイスに紐づけることを求めることがよくあります。その結果、BBS+のようなスキームでは、すべてのユーザーのデバイスのハードウェアセキュアエレメントとOSのアップデートが必要になります。

In this paper, we propose a new anonymous credential scheme for the popular and legacy-deployed Elliptic Curve Digital Signature Algorithm (ECDSA) signature scheme.  By adding efficient zk arguments for statements about SHA256 and document parsing for ISO-standardized identity formats, our anonymous credential scheme is that first one that can be deployed *without* changing any issuer processes, *without* requiring changes to mobile devices, and *without* requiring non-standard cryptographic assumptions.

本稿では、広く普及し、レガシーシステムにも導入されている楕円曲線デジタル署名アルゴリズム（ECDSA）署名スキームのための新しい匿名クレデンシャルスキームを提案する。 SHA256に関する効率的なzk引数と、ISO標準化されたIDフォーマットの文書解析を追加することで、この匿名クレデンシャルスキームは、発行者側のプロセスを変更することなく、モバイルデバイスの変更を必要とすることなく、また、非標準の暗号化前提条件を必要とすることなく実装できる初めてのスキームです。

 なかなか期待できますね。生成速度に関してもこのような記載があります。

Our proofs for ECDSA can be generated in 60ms.  When incorporated into a fully standardized identity protocol such as the ISO MDOC standard, we can generate a zero-knowledge proof for the MDOC presentation flow in 1.2 seconds on mobile devices depending on the credential size. These advantages make our scheme a promising candidate for privacy-preserving digital identity applications.

当社のECDSAの証明書は60ミリ秒で生成できます。ISO MDOC標準のような完全に標準化されたアイデンティティプロトコルに組み込まれた場合、クレデンシャルのサイズにもよりますが、モバイルデバイス上でMDOCプレゼンテーションフロー用のゼロ知識証明書を1.2秒で生成できます。これらの利点により、当社の方式はプライバシー保護型デジタルアイデンティティアプリケーションの有望な候補となっています。

mdocのプレゼンテーション時にゼロ知識証明を1.2秒で生成、このくらいなら実用性がありそうですね。

論文の本文もPDFで閲覧できるようになっているので、おいおい見ていこうと思います。

 

 

Google Walletと選択的情報開示

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

先日、「選択的情報開示とウォレットと本人確認書類」というタイトルで投稿しました。

https://idmlab.eidentity.jp/2024/08/blog-post_28.html

内容としては、本人確認書類をデジタル化するならば選択的情報開示を含めデジタル化をすることによるメリットがちゃんと見えるようにならないといけないよね〜という話だったわけですが、昨日も触れたGoogle Walletの記事には今後のロードマップが明示されています。

How we're working to make digital identity a reality for everyone

https://blog.google/products/google-pay/google-wallet-digital-id-privacy-security/

要するに安心してGoogle Walletなどのアイデンティティソリューションを利用するためにGoogleが取り組んでいることについて書かれたポストですが、その中に選択的情報開示に関して記載があります。

Selective disclosure and user control: With digital identity, the relying party (a party requesting information, for example a car rental company or a merchant) is able to request only the relevant parts of a person’s ID. Today, if you’re presenting your physical ID (for example to confirm your age or your address) you have to share everything — your name, address, your physical description and more. However, with a digital ID, you can share only the required data. Additionally, you must authenticate the device with a fingerprint, PIN or passcode in order for any of your ID information to be shared with the requester.

選択的開示とユーザー制御：デジタル ID では、依拠当事者（情報を要求する当事者、たとえばレンタカー会社や商業者）は、個人の ID の関連部分のみを要求することができる。現在、物理的なIDを提示する場合（たとえば年齢や住所を確認する場合）、氏名、住所、身体的特徴など、すべてを共有しなければならない。しかし、デジタルIDでは、必要なデータのみを共有することができる。さらに、あなたのID情報を要求者と共有するためには、指紋、PIN、パスコードでデバイスを認証する必要があります。 

選択的情報開示のUXがどうなるのか気になりますが、個人的な意見としてはリライングパーティが全体ではなく最低限の要求ができるようになるので、ウォレットとしてはそのリクエストに対応できるようにするよ、という話だけでは全然足りない気がしています。（実装する立場としては理解できますが）

あくまでユーザの意思によって開示する情報を選択できるという体験が重要だと思うので、リライングパーティがどんな属性を要求してきているかに関わらず、自身で開示する属性を選べる状態にはなっていないといけないと思います。（結果的にリライングパーティの要求を満たさなかったとしても）

また、オフラインでの利用についても考慮をしていってもらえるといいなぁ、、と思います。たとえば、画面を見せる際に検証者の目線では「これは正式な書類である」ということが視認できる状態が重要なので、表面は正式な証明書であることが視認できるだけ、タップして裏面を見せるとユーザがあらかじめ設定した開示したい最低限の情報だけが記載されている、という状態が作れるといいのではないかと思います。

いずれにしても3rdパーティウォレットを含むエコシステムが正常に出来上がるような規制などは政府が中心に整備してもらえるといいですね。ユーザーの声を正しく吸い上げるためにもAppleとGoogleだけに任せるのではなく、エコシステム全体として進化できていくことが重要な気がします。

Google Walletへ搭載できる証明書

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

Gogole Walletへの米国パスポートの搭載が先日発表されましたね。

崎村さんがGoogleのアナウンスについてポストされているのでこちらを見ると良いと思います。

https://www.sakimura.org/2024/09/6359/

簡単にいうと、米国のパスポートをGoogle Walletへ格納することができるいう話で、現在はまだ紙のパスポートと併用、かつTSAチェックでしか使えないが、将来的にはもっと使える場所の拡大をしていこう、としているという話です。

日本でも早く使えるようになるといいですねぇ。

まだ、日本では決済以外だとイベントのチケットや航空券やポイントカードなどが搭載できるくらいですし。

日本で追加できるのは

• 支払いカード
• ポイントカード
• ギフトカード
• 写真

の４カテゴリ。

ポイントカードは色々と使えるものが増えていますね。

ところで、米国を含む海外ではGoogle Walletは何に使えるのかみていきましょう。

Google Walletのヘルプページを見ると色々なものが搭載できるようになっているようです。

https://support.google.com/wallet/answer/12059409?hl=ja&ref_topic=11925097&sjid=8720886013754835920-AP

日本語ページなのでちょっと直訳感がありますが、右側のナビゲーションを見ると、関連トピックスとしてこちらが記載されています。

• お支払い方法
• 搭乗券やイベント チケットを保存して使用する
• ポイントカードとギフトカード
• Google ウォレットを公共交通機関で使用する
• Google ウォレットにヘルスパスを追加する
• 自動車用デジタルキー
• Google ウォレットに学生 ID を保存する
• 米国の運転免許証または州発行の身分証明書を追加する
• Google ウォレットに社員バッジを保存する
• Use transit loyalty cards in Google Wallet (UK only)
• スマートウォッチの Google ウォレットでパスを使用する
• Google ウォレットのパスの分類
• Google ウォレットのリンクされたパスについて
• Google ウォレットのウェブサイトの利用を開始する
• ホテルキー

ヘルスパスはワクチン接種証明で日本もやっていましたね。

https://idmlab.eidentity.jp/2021/12/verifiable-credentials.html

その他ポイントカードなど日本も使えるもの以外を見ていくと、

• 自動車用デジタルキー
• 学生ID
• 米国の運転免許証または週発行の身分証明書（今回のパスポートの件はこちらですね）
• 社員バッジ
• Transit loyalty card
• ホテルキー

などが面白そうです。

自動車の鍵だと古くからCCC（Car Connectivity Consortium）が取り組んできた活動はありますが、電子運転免許証（mDL）と連携していく動きは活発化していきそうですね。

学生IDも面白いトピックです。

マサチューセッツ工科大学（MIT）が2021年にアナウンスしたデジタル学生証や、卒業証明書のデジタル化の動きはエポックメイクングでしたが、Googleのヘルプを見ると「米国、カナダ、オーストラリアの加盟大学」がこの機能を使えるようになっているようです。

社員バッジも学生IDと同様に普及していくと面白いですね。

Credential APIも本格化してきましたし、引き続きこの分野は要ウォッチです。

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

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

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

https://openid.net/registration-oidf-workshop-monday-april-15-2024/

先日日本でもOpenID Summitの前日に開催されたワークショップですね。

その時の様子はこちらです。

https://idmlab.eidentity.jp/2024/01/openid-foundation-hybrid-workshop.html

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

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

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

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+への共有はできなくなります

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

TechSummitのおさらい③：Azure AD + Auth0 で条件付きアクセスを構成する

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

そろそろディープになってきました。公式イベントで話すにはかなり気が引けるネタ度Maxです。

今回はAuth0（おーすぜろ）とAzure ADを組み合わせることで複雑なことをやろう！という話です。

もちろんAzure ADにはPremium P1/P2という複雑なことをやりたい人向けのプレミアなライセンスがありますので、お金に余裕のある方、一気通貫でサポートを頼みたい方は迷わずそちらを選んでください。

Auth0とは？

Auth0もMicrosoftやOkta、PingIdentity、OneLoginなどと同様にIDaaS（Identity as a Service）を提供しているサービスプロバイダです。jwt.io辺りで有名ですね。
ちなみにFounderは元マイクロソフトのEugenio Paceです。「A Guide to Claims-Based Identity and Access Control」をVittorio Bertocciと一緒に書いた人ですね。まだ彼がMSにいる時代にやり取りをしてサイン本をもらったりしたもんです（遠い目）。最近は共著のVittorioもAuth0へ移ったのが個人的なビッグニュースでした。

少し特徴的なのは「開発者向け」である、という売り出し方をしているところですね。開発者向けたる所以は、ひたすらかゆいところに手が届くから、というのが最大の理由だと思います。

このAuth0、実は別のサービスとしてWebtaskというFaaS（Function as a Service）を提供しており、ID関連の機能の各所にこのWebtaskをどんどん差し込んでいくことが出来るんです。このことにより、例えばid_tokenの中身を見て処理を実行したり、ID登録直後に別の処理を走らせたり、など開発者がやりたい放題出来てしまいます。

Azure AD + Auth0？

さて、Azure ADとAuth0を組み合わせると何が出来るのか？という話に移りたいと思います。
Auth0はAuth0自体にIDを保持して自身がIdPとして振舞う以外に、外部のIdP（Connectionと呼んでいます）とID連携する機能を持っています。また、当然のごとく外部のSPとID連携することもできます。
このことを使い、IDの保持とベーシックな認証機能はAzure ADで、複雑な処理（今回は条件付きアクセスと多要素認証）はAuth0で担当、というようなことを実現することが出来ます。
使えるプロトコルも多様なので、アプリ（今回はG Suite）とAuth0の間はSAML、Auth0とAzure ADの間はOpenID Connect、という構成を組んでみました。

Azure ADのアプリ（RP）としてAuth0を登録

早速構成していくわけですが、まずはAuth0の外部IdPとしてAzure ADを構成するためには、Azure ADのRelying Party（RP）としてAuth0を登録してあげる必要があります。具体的には、ReplyUrl（応答URL）にAuth0のエンドポイント（Callback）を登録し、Auth0側に設定するためのClient IDとClient SecretをAzure ADから払い出します。

Azure ADのアプリ登録メニューより登録を行います。
　Azure ADに登録するAuth0のCallback URLは以下の通りです。
　　https://{テナント名}.auth0.com/login/callback

Auth0の外部IdPとしてAuth0を登録

次は、逆側の設定なので、Auth0にAzure ADの情報を登録していきます。
ちなみにAuth0はビルトインのConnectorとしてAzure ADが用意されているので、こちらを使ってもいいですし、OAuthを使ってカスタム接続するためのExtensionもあるのでこちらを使って接続しても問題はありません。

こちらがビルトインのAzure ADとの接続Connector

こちらがOAuthを使うExtension

私は後者のExtensionを使っています。（というかビルトインでAzure ADが存在しているのを知らなかった・・・）
Azure ADの認可エンドポイント、トークンエンドポイントと先ほどアプリ登録した際に取得したClient IDとClient Secretを登録します。

ちなみに、例のWebtaskを使ってGraph APIでAzure AD上のユーザ情報を取得することが出来ます。SAML Assertionに属性を入れてアプリに渡す必要があるので、必要な属性を取得する様にスクリプトを作ります。

function(accessToken, ctx, cb) {

  request.get('https://graph.microsoft.com/v1.0/me', {
      headers: {
        'Authorization': 'Bearer ' + accessToken,
      },
      json: true
    },

    function(e, r, u) {
      if (e) return cb(e);
      if (r.statusCode !== 200) return cb(new Error('StatusCode: ' + r.statusCode));
      var profile = {
        user_id: u.userPrincipalName,
        name: u.displayName,
        email: u.mail
      };
      cb(null, profile);
    });
}

直観的にわかりやすいスクリプトだと思うので、あまり解説する必要もないとは思いますが、トークンエンドポイントから取得したアクセストークンがコンテキストとコールバック先のオブジェクトと一緒に渡ってくるので、Graph APIにアクセスして必要な情報を取得、Profileとして設定して返却してあげる、という流れです。

G SuiteとAuth0をID連携

ここはこれまで何度となく解説してきたG Suiteのシングルサインオン設定の世界なので、G Suite側は目をつぶっていても構成できてしまう世界だと思いますので、Auth0側の設定を中心に。

ちなみにAuth0にはApplicationギャラリー的なプリセット・アプリのリストは存在しません。めちゃくちゃシンプルにNative App、SPA、Regular Web App、Machine to Machine Appの4種類しかありません。

G Suiteなど通常のアプリを使う場合はRegular Web Appを選びましょう。

また、Regular Web Appを選んだとしてもデフォルトではアプリと言っても単純なOAuthのクライアント登録しか出来ないので、AddOnという形でSAML等のプロトコルを設定してあげる必要があります。
SAMLの設定もかなりプログラマブルなので、Assertion内の各種パラメータをガリガリと書いていきます。本当に痒い所に手が届きます。ほぼ出来ないことは何もないので、Assertionの書き方の方言でうまくアプリと繋がらない、というトラブルとは無縁だと思います。その代わりSAML Assertionの中身の仕様について熟知している必要はありますが。

この構成のページからIdP MetadataやAssertion署名用の証明書のダウンロードなども可能なので、エンドポイントや証明書をG Suite側に設定してあげれば完了です。

これで一通り単純なシングルサインオンについて出来るようになっています。

条件付きアクセスを構成する

ここまでだとAuth0がG SuiteとAzure ADの間に挟まっている必要性が全くないので、最初に書いた通り、条件付きアクセスを構成してみます。
本来Azure ADではPremium P1のライセンスが必要な機能です。

Auth0での条件付きアクセスを構成するには、Rulesメニューよりルールを構成します。
このルールもJavascriptでガリガリと書いていくことが出来るので、ものすごく柔軟です。アクセス元の状態はContextから取得できるので、ソースIPやUser Agentなど様々な情報を見て多要素認証の適用の有無など各種条件を設定することが可能です。

function (user, context, callback) {
  const ipaddr = require('ipaddr.js');
  // 社内ネットワーク
  const corp_network = "x.x.x.x/16";
  // 対象のアプリケーションのclient_id
  const CLIENTS_WITH_MFA = ['G SuiteのClient Id'];

  // 接続元のソースIP
  const current_ip = ipaddr.parse(context.request.ip);
  if ((!current_ip.match(ipaddr.parseCIDR(corp_network)) && (CLIENTS_WITH_MFA.indexOf(context.clientID) !== -1))) {
      context.multifactor = {
        provider: 'google-authenticator',
        allowRememberBrowser: false
      };
  }

  callback(null, user, context);
}

ここまで構成すると社内アドレス以外からG Suiteを使おうとすると多要素認証（今回はGoogle Authenticator）を要求される様になります。

こんな感じでAzure AD+Auth0で見た目はぼぼAzure AD Premiumの条件付きアクセス、ということが実現できてしまいました(笑)。

まだまだネタは続きます。では次回！

TechSummitのおさらい②：Azure ADとSaaSアプリのSSO構成時のトラブルシュートあれこれ

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

前回に引き続きTechSummitのフォローアップです。

今回は2つ目のネタ「SaaSアプリのSSO構成時のトラブルシュートあれこれ」についてです。

簡単に言うと、同じ種類のSaaSアプリを複数インスタンス（例えば本番環境と開発環境とか）を単一のAzure ADとSSOの構成をしようとすると動きがおかしくなる「ことが」ある、というお話しです。

よくあるシーンはこんな感じで、本番・開発の2環境を用意したいけど、Azure ADってテナント毎、ユーザ毎のライセンスなので出来ればAzure ADは単一の環境で済ませたいよね、っていう話です。

TechSummitでは個人的な経験を基に、G Suiteを複数インスタンス用意してSSOを構成しようとしたとき、たまに発生する問題を紹介しました。
※ちなみにSalesforceでも起きることがあるようですが、すべてのアプリで発生するわけではありません。また、G Suiteでも毎回起きるわけではありません。

何が起きる（た）のか

先ほど書いたように、毎回起きるわけでもなく、発生条件も良くわからない状態なので、ここに書いたことが必ず起きるわけでもなく、他に発生する問題がある可能性もありますが、とりあえず私が体験したことを書いていきます。

• NameIDの値のマッピングが上手くいかない（UPNを使ってくれない）
• SP EntityIDが一致していない、と言われる

NameIDのマッピング不良と対策

まずは前者です。
初期状態のAzure ADはG SuiteのSSO構成時、NameID属性としてuserPrincipalName属性をマッピングします。また、G SuiteのNameID Formatの指定はunspecifiedです。

通常、この構成だとAzure ADはuserPrincipalNameの値をそのままG Suiteへ渡すのですが、なぜか仮名が生成されてNameIDとして渡されてしまうことがあります。通常はNameID FormatがTransientやPersistent以外は仮名が生成されることは無いはずなのですが、何かがおかしいです。

これを解消しようとすると、Azure AD側のでNameID Formatを明示的に指定してあげる（つまり、G Suiteからの指定を無視する）必要があります。
G Suiteはメールアドレス形式でNameIDの値が飛んでくるのを期待しているので、NameID Formatをemailaddress（電子メールアドレス）にしてあげます。

これでうまくいきます。

SP EntityIDの不一致

次に、SSOを試みた時に出てくる「AADSTS65005: Misconfigured application」エラーへの対策です。このエラーはAzure AD側でアプリケーション構成がおかしいので見直せ！というエラーです。

最近はAzure ADのSSO構成も人にやさしくなっており、エラーの詳しい原因が管理ポータルからある程度確認できるようになっています。（Salesforceが昔から実装していた機能ですね）
これまでSAMLのやり取りをトレース＆解析しないとダメだったのですが、この機能が出来てかなり楽になりました。

この機能を使って先のエラーの原因を探ると、なぜかSP EntityID（要するにアプリケーションを一意に識別する情報）がマッチしていない、と言われます。どう見ても一致してるんですが・・・
もちろんアプリケーションが一つしか構成されていない状態ではこのようなことは言われないのですが、G Suiteを複数インスタンス構成するとタマにこのエラーが出ます。
※ちなみに昔はもっとひどかった（構成するとユーザの割り当てが混ざったりしていた）ので、マシにはなったんですが・・・

実はこのエラーが出ると、Azure AD側ではどうしようもなく、強引に複数のG Suiteインスタンス間でEntityIDが絶対に重複しない様に構成を工夫するしかなくなります。
今回やったのは、片方のG Suiteについて、Google側でEntityIDにドメイン固有情報を含めるのを辞める、という苦肉の策です。
これで複数のG Suiteインスタンス間で必ず異なるEntityIDが使われるようになるので、問題が解決します。（本来はこんなことをしなくても必ず異なるEntityIDは使われるんですが）

まぁ、今回紹介したものは発生することもある、というレベルなので仕組みを理解した上で適度に使ってもらえれば、というレベルの話でした。

引き続きフォローアップをしていきますので、お楽しみに。

[Azure AD B2B]GoogleとのID連携によりユーザの招待が簡単になりました

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

Azure AD B2Bを使うと外部のユーザを招待し、組織のアプリケーションへのアクセスを付与することが出来ます。
この招待は
・Azure ADテナントを持っている組織の人
・Azure ADテナントを持っていない組織の人や個人
に対して送信することが出来、これまでAzure ADテナントを持っていない人は招待メールを受け取ったら、招待元のディレクトリにサインアップする際にログイン・パスワードを設定する必要がありました。

つまり、滅多にアクセスしない外部組織のアプリケーション専用にアカウントを作らなければならない、ということが発生するのでゲストユーザからすると非常に面倒くさい話ですし、パスワード忘れなども発生しやすいので管理上の問題も発生しやすい状況でした。

今回、Azure AD B2Bの新しく公開（現状パブリック・プレビュー）されたのが、Googleアカウントを持っている個人（G Suiteではなく、gmail.comのユーザ）を対象に、Google側の認証でAzure AD B2Bのテナントへログインできるようにする機能です。

　公式Blog）
　Azure AD B2B Collaboration support for Google IDs is now in public preview
　https://cloudblogs.microsoft.com/enterprisemobility/2018/08/28/azure-ad-b2b-collaboration-support-for-google-ids-is-now-in-public-preview/

やっていることは非常に単純でAzure ADに外部Identity ProviderとしてGoogleを設定、ゲストアカウントのドメインがgmail.comならGoogleにリダイレクトする、という仕組みです。

では、やってみましょう。
詳細は公式ドキュメントを参照してください。

◆GoogleにOAuthのクライアント登録を行う

結局のところ、Azure AD B2BがGoogleに対するOAuthクライアントとなるので、クライアント登録をしてあげる必要があります。

GoogleのDeveloper Consoleより作業を行います。
　https://console.developers.google.com/

必要な作業は、
・プロジェクトの作成
・OAuth同意画面

・OAuthクライアントの登録

の3点です。

ポイントは、OAuthクライアント登録時のリダイレクトURIの設定くらいだと思いますので、詳細は省きますが以下の通り設定を行います。

リダイレクトURIとしてセットする値

　https://login.microsoftonline.com

　https://login.microsoftonline.com/te/{Azure ADのテナントID}/oauth2/authresp

こんな感じで登録されますので、Client IdとClient Secretをメモしておきます。

◆Azure ADに外部Identity Providerを設定する

次は、Azure AD側の設定です。

ポータルからAzure ADを開くと、「Organizational relationships」という見慣れないメニューが出てきているので、こちらを開いていきます。

続いてIdentity ProvidersからGoogleを追加します。

すると、GoogleのClient IDとClient Secretを求められるので、入力して保存します。

これでおしまいです。

◆Googleアカウントを招待する

これは従来のAzure AD B2Bの操作と全く同じです。

Gmailのメールアドレスで招待するだけですね。

これで招待メールが飛んでくるのでディレクトリへアクセスします。

従来はココでゲストユーザにパスワードを登録する様に求められましたが、今回の機能を使っているとパスワードは不要なのでそのままユーザが作成されます。

上手くいくとアクセス・パネルが表示されます。

アプリケーションも使え、属性が取得できています。

ちなみに、自組織にAzure ADテナントが無いゲストユーザがアクセス・パネルにアクセスする時は、https://myapps.microsoft.com が使えません。どのテナントにユーザがいるのかが判別できない＆組織アカウントなのかマイクロソフト・アカウントなのかの判別が出来ないためです。（マルチテナントアプリケーションも同様です）

そこで、招待元のテナントを決めうちでアクセスする必要があるので、以下のように招待元ディレクトリのテナントIDをパラメータにつけてアクセスしてください。
https://account.activedirectory.windowsazure.com/r?tenantid={招待元のテナントID}

取り敢えず個人のGmailアカウントはこれで便利になりました。
ちなみにG Suiteの場合はこの機能ではなく、G SuiteをSAML IdPとして構成、ドメイン単位でのID連携を構成すれば動くはずです。（やってませんが。。また紹介します）

Microsoft Authenticatorアプリが設定のバックアップ・リカバリをサポート、しかし・・・

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

みなさん、多要素認証してますか？
アイデンティティは不正利用されている、という前提で運用しないといけない世の中になってきているので、IDとパスワードが盗難されても不正にログインされない様に多要素認証を有効にするのは大人のマナーです。もしくは、少なくともログイン・アラート（知らないログインがあったら通知してくれる機能）が使える認証システムを使う、くらいはいしないとダメな世の中です。
そういえば昨年のde:codeでもこんな話をしてました。

結局、ID盗難って本人が気が付きにくいところが一番の問題なんですよね。


と、言うことでMicrosoftもAuthenticatorアプリをiOS/Android/Windows Mobile向けに提供しており、私もAzure ADアカウント、Microsoftアカウントに加えてGoogleやFacebook、Amazonなどのアカウントの多要素認証をこのアプリでやっています。

が、機種変更などでアプリを再インストールすることになると実は非常に面倒です。全ての多要素認証設定を再度１からやり直さないといけないので、このアプリがないとログインできないような状態になってしまっているサービスがあると詰みます。

そこで登場したのが、ずっとリクエストが上がっていた多要素認証設定のバックアップとリカバリ機能です。

公式Blogでのアナウンス
　Microsoft Authenticator Account Backup and Recovery: Coming soon to an iOS device near you!
　https://cloudblogs.microsoft.com/enterprisemobility/2018/04/24/microsoft-authenticator-account-backup-and-recovery-coming-soon-to-an-ios-device-near-you/


機能を有効化するためには以下の条件を満たす必要があります。
・iOS版であること（残念ながらまだAndroid版では使えません）
・Authenticatorアプリのバージョンが5.7.0以降であること
・Microsoftアカウント（個人アカウント）があること


早速使ってみましょう。
と、その前に本ポストのタイトルに書いた「しかし・・・」の部分が気になりますよね？そう、実は組織アカウント（Azure AD/Office365）の多要素認証はリカバリできないんです。結局は再度QRコードの読み込みから開始なので、管理者にリセットしてもらう必要があります。
また、多要素認証設定済みのMicrosoftアカウントで設定をバックアップすると、リカバリ時に当該のMicrosoftアカウントでログインを求められますが、当然そのMicrosoftアカウントの多要素認証は今からリカバリしたい設定の中に入っているので、アプリで多要素認証は出来ません。他の方法（メールとかSMSでの回復）を設定していないとこれも詰みます・・・


こんな罠だらけの新Authenticatorですが、Googleなどの他の多要素認証はちゃんとリカバリしてくれる（はず）なので一応便利です。（Googleしか試してないのでAmazonとかFacebookが大丈夫かどうかは知りません）


とは言え、気を取り直して試してみます。
アプリを起動して、設定メニューを開くと「バックアップ」という項目が増えています。

おもむろに自動バックアップをONにするとMicrosoftアカウントが求められます。

この画面だけを見るとバックアップはOneDriveとかに保存されるのかな？と思うんですが、アプリを英語モードで起動すると実はこの画面の前にiCloudに保存する、というメッセージが出てきます。

これを見るとバックアップはiCloudにされ、リカバリする時にMicrosoftアカウントで認証することで保険をかけてる、ということなんだと思います。

Microsoftアカウントを追加すると回復アカウントとして表示されます。

後は、おもむろにアプリを消して再インストールしてみます。

まっさらの状態で起動してくるので、「回復の開始」からリカバリをしてみます。

回復に使うMicrosoftアカウントを選択し、ログインしましょう。
ここではアプリ内ブラウザが前に設定した時のMicrosoftアカウントを覚えてくれていたので選択するところから始まっていますが、機種変更などの場合はアカウントを追加するところからスタートですね。

と、ここで先ほど書いた通りのハマりポイントその１です。
このMicrosoftアカウントに多要素認証の設定をしていたので、ログイン時に多要素認証を要求されます。
運良く、実験した時は別のデバイスで多要素認証する様に構成していたので、難を逃れました。

しかし、別のデバイスで認証する構成にしていたが故に不思議なことが起きてしまいます。発生した現象は後述するとして先に進めましょう。

アカウントの回復完了、と表示されるのですが「セキュリティ上の理由から、一部のアカウントで追加の検証が必要です」と出て、Azure ADのアカウントに！マークがついています。

これが先ほど書いた微妙な点です。
Azure AD/Office365のアカウント（組織アカウント）のリカバリは出来ないんです。
回復するには再度QRコードをスキャンする必要があるので、別の方法で何とかログインするか管理者に多要素認証設定をリセットしてもらうしかありません・・・

今回は管理者でリセットしました。Azure ADのポータルからMFA設定を開いてユーザを検索、Manage user settingsを開きます。

再度ユーザが多要素認証設定を設定する様に要求します。

これで再設定をすると一応リカバリされます。
ちゃんとAzure ADアプリへの多要素認証ログインもできました。もちろんGoogleについてはGoogle側で何のリカバリ処理も必要なく、ちゃんと多要素認証ログインできます。

ちょっとおかしなことになってますよね？
気が付いた方いますか？




そうです、リカバリした端末側の多要素認証設定に、リカバリに使ったMicrosoftアカウントのエントリが勝手にできています。
私は別の端末でこのMicrosoftアカウントの多要素認証をしていますので、2つの端末に同じMicrosoftアカウントの多要素認証エントリが存在している状態になります。

試しに、このMicrosoftアカウントでサービスにログインしてみます。

すると、なんと2つの端末に通知が来ます・・・

はい、バグだと思います。
（と思いましたが、Microsoftアカウントの場合は複数の端末で多要素認証をさせることができるので、こういう仕様なんだと思います）

ちなみに、どちらで承認してもちゃんとログインできます。

うーむ・・・



と、若干微妙な感じではありますが、少なくともGoogleの多要素認証はちゃんとリカバリできたので、楽にはなりました。
皆さんも使ってみましょう。

Internet Weekの資料と動画を公開しました

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

遅くなりましたが、Internet Weekで使った資料を動画をアップロードしています。
（イベント直後にアップロードしてあったのですが、こちらに告知するのを忘れていました）


また、デモ環境の構築手順もまとめたので明日から順番に書いていこうと思います。


まずは資料です。

ID管理/認証システム導入の理想と現実 from Naohiro Fujie

続いてデモの動画です。

内容は

• OpenAMと社内ADをこっそり連携
• OpenAMでデスクトップSSO
• OpenAMとG Suite（Google Apps）を連携
• OpenAMと連携したG SuiteをAzure ADと連携
• G Suiteの連携を利用者に知られずにOpenAMからAzure ADへ切り替え

という内容です。

当日のデモとこの動画はOpenAM 12.0ベースで作っていますが、明日から公開する予定の環境構築手順はOpenAM 13.0ベースで作り直していますので、また参考にしてもらえればと思います。

安全!? #PokemonGo のログインと OpenID Connect と PokeIV

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

今回はもPokemon Goとアイデンティティのネタです。

前回、前々回とPokemon Goのログインの流れを見てきました。

　攻略！ #PokemonGo のログインと OpenID Connect
　http://idmlab.eidentity.jp/2016/07/pokemongo-openid-connect.html

　続！#PokemonGo のログインと OpenID Connect
　http://idmlab.eidentity.jp/2016/07/pokemongo-openid-connect_25.html


これまでのポストでは、主にGoogleでログインすることで、Googleサービスへの不要なアクセスができる状態になっていないか？という観点で調査をしてきましたので、Scopeパラメータを見る限りはメールアドレスくらいにしかアクセスしていないことが分かったので、ひとまず安心、という結論を出していました。

◆Pokemon Goのふりをするアプリの登場

しかし、逆にPokemon Go側から見ると、Pokemon GoのサービスへのアクセスはGoogleから取得したid_tokenを持っていることだけを条件にしているので、何とかしてPokemon Goアプリの”ふり”をしてid_tokenを取得してしまえば、あとは何とでもなる、という状態でもありました。

最初のポストを書く時に、OpenID ConnectでGoogleからid_tokenを取得する流れを見ていると、public clientにもかかわらずimplicitではなくcode flowを使っており、codeやclient_secretが丸見えな点にものすごく違和感を感じて、サードパーティ・クライアントでも作るつもりなのかな？？？など、色々と議論をしていたんですが、やはり出てきてしまいました。

　PokeIV : 個体値チェックサイト
　　https://pokeiv.net/

Gigazineでも紹介されていますが、Pokemon Goで使っているアカウントでGoogleにログオンし、codeを取得しPokeIVに貼り付けることでPokemon Goへアクセスして個体情報を取得するという仕組みなのですが、内部的には、Pokemon Goのclient_idとclient_secretを使ってPokemon Goのサービスへアクセスできるid_tokenを取得しているようです。

以下の同意画面を見るとクライアントがPokemon Goになっており、クエリパラメータの中のclient_idを見るとiOS版のPokemon Goで使っているclient_idと同じものが使われています。

Googleに登録されているredirect_uriがurn:ietf:wg:oauth:2.0:oobなので、redirect_uriにクエリでcodeを渡す代わりに、取得したcodeを手動（コピペ）で渡し、tokenエンドポイントを叩く、という実装はしていますが、色々とタチが悪いですね。

最近OpenID Foundation Japanの事務局長になったnov氏がoauth.jpで書いているようにcode置き換えもあるでしょうし、そもそもclient_secretが漏れている段階で今回のPokeIVのように単純にPokemon Goのふりをしてデータを取得するようなクライアントの開発が出来てしまいます。

今は集めたポケモンの情報をとってくるだけ、ということになっているので良いんでしょうが、例えば、今後Pokemon Goからユーザの位置情報の履歴を取得できたりすると、一気にホラーな話になってしまいますよね。。。

◆Pokemon Goはどうすれば良かったのか？

そもそも論、HTTPSを使っているにも関わらずFiddlerでトレースできてしまう段階でCertificate Pinningなどの対策が出来ていない、という話もありますが、ネイティブアプリ（パブリック・クライアント）として実装している段階で逆コンパイルや解析をされる前提でOpenID ConnectやOAuthの設計をすべきです。具体的にはimplicit flowを使ったり、Google Sign-In SDK for iOSを使って、client_secretを使わない方法で実装するのが一番簡単な対策だと思います。

簡単にまとめるとこんな感じかと。（他にもあるとは思いますが）

脅威	対策
通信トレースによるcodeやclient_secretの漏えい	Certificate Pinning
バイナリ解析によるclient_secretの漏えい	難読化（限界あり）
Proxyサーバの通信ログよりcodeの漏えい	PKCEの利用（Googleは既にPKCE対応してます）
client_secretの漏えいによるクライアントなりすまし	client_secretを使わないフローの採用（implicit/Google Sign-In SDKの利用）

◆現バージョンのPokemon Goはどうなっているのか？

最近バージョンが上がったクライアントはどうなっているのか？を見てみました。

Proxyを挟んだ状態でアクセスするURLなどを見て推測すると、Google Sign-In SDKを使っているみたいです。また間にfiddlerを挟んだ構成だとログオンに成功しないので、MITMもチェックもしているみたいです。（うまくトレースできなかったので深追いはしていませんが）

◆PokeIVなどのアプリを使ってしまった場合の対策

しかし、一度PokeIVなどのアプリを使ってしまった場合、id_tokenやrefresh_tokenがアプリ側に保管されている可能性もあり、勝手にPokemon Goへ不正にアクセスされてしまう可能性もゼロではありません。

このような場合は、Googleアカウントのページからアプリケーションからのアクセスを一旦取り消して、正規のPokemon Goで再度サインインをしましょう。

アクセスを許可しているアプリケーション一覧が以下のURLで確認できるので、Pokemon Goを探して、一旦削除してしまいましょう。

https://security.google.com/settings/security/permissions

Pokemon Goを起動すると再度Googleアカウントへのアクセス許可のページが表示されますので、ここで改めて許可をすることでid_tokenが取得できるので引き続きPokemon Goを楽しむことが出来ます。