食べログのFacebook連携の終了とトラッキングの許可問題

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

みんな大好き食べログですが、しばらく前からFacebook連携でログインしようとするとトラッキング許可を求められるようになっていました。（アプリ利用の場合のみ）

なんだか微妙だなぁ、と思ってアプリの利用を諦めていたんですが、こんな記事を見つけました。

【改善済み】（iOS）Facebookログインを利用していると、トラッキングに関するエラーメッセージが表示される

https://community.pikminbloom.com/t/ios-facebook/1814

この記事をみると「FacebookアカウントPikmin Bloomに連携していると、突然トラッキングに関するエラーメッセージが表示されるという問題が報告されています。」とありますのでアプリは異なれど似たような話に見えます。

ただ、このアプリではiOS 17.5.1にしたら解消されたとありますが、食べログアプリでは解決されていませんでしたが。。。

と思っていたら、以下のお知らせが。

【重要】Facebookログイン機能終了のお知らせ

https://tabelog.com/support/announcement?id=913

8月4日までに他のログイン方法でログインできるようにしておかないといけませんね。

準備をしておきたいと思います。

京都大学 学術情報メディアセンターセミナー「デジタルIDの最新動向」でお話します

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

来週6月25日に京都大学の学術情報メディアセンターでデジタルIDについてお話しさせていただきます。

告知・申込サイト

https://www.media.kyoto-u.ac.jp/accms_web/event/3115.html

会場はもちろん京都大学ですが、ハイブリッド形式での開催となるのでリモート視聴も可能です。

旧来のSAMLをベースとしてアカデミックフェデレーションの話からOpenID Connectへの道筋の話や、学術機関におけるトラストフレームワークの今後の話、学位・学修歴などのデジタルクレデンシャルの利活用へのシナリオの話など、80分でまるっとお話ししようと思います。

ぜひご参加ください。

こちらがアジェンダです。

◆16時30分～16時35分　オープニング

◆16時35分～17時05分

講演者：清水 さや子（国立情報学研究所アーキテクチャ科学研究系　助教）

講演題目：Persistent IDの可能性とオンライン本人確認システムの紹介

講演概要：組織で提供されるIDは、通常、入学や採用時に発行され、卒業や離職時には無効化されます。そのため、所属組織が変更されると、その時点で、新しいIDを利用することになります。一方で、研究データ基盤サービスなど、所属組織の異動に関係なく継続利用が求められるサービスも存在します。このようなケースに対しては、オンラインでの本人確認を利用したスムーズなID移行が期待されています。本セッションでは、Persistent IDの活用や、スムーズにID移行を支援するためのオンライン本人確認システムについて紹介します。

◆17時05分～18時25分

講演者：富士榮 尚寛（伊藤忠テクノソリューションズ株式会社・みらい研究所長）

講演題目：学術機関におけるデジタルIDとトラストのこれから

講演概要：従来の学生や教員のアカウント管理や認証など、各種情報システムへのセキュアなアクセスを行うためのID管理・認証という世界観から、デジタル学修歴やデジタル学生証など新たなデジタルツールの利活用を行うためのデジタル・トラストをいかにして構築するか？が近年着目されています。本講演では従来のデジタルIDやトラストのあり方を踏まえた上で、今後のデジタル社会の発展に向けたデジタルIDとトラストのあり方について議論します。

◆18時25分～18時30分　クロージング

自己主権型IDとフェデレーション型IDに関する議論

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

今日はちょっと前の記事ですが、SSIとFederationについてHeather Flanaganさんが考えを書いているので紹介しようと思います。IDProや古くはKantaraやREFEDSなどで活動されている方ですね。しかしSSIがいいのかFederationがいいのかっていうのは色々なところで色々な人たちが議論をしていますが、明快な答えってないですよね。まぁそれもそのはず「時と場合による」話でしかないのと、一番大きいのが技術の話をしているのか思想の話をしているのか、みなさんMixしているのでクリアな議論にならないっていうのがあるからですね。

ということでちょっと見ていきましょう。

Federated Identity and SSI – YMMV

https://sphericalcowconsulting.com/2023/11/17/federated-identity-and-ssi-ymmv/

ご本人もYMMV（your mileage may vary）って書かれているように、「どう受け取るかはみなさん次第」ということです。

また冒頭にも記載されていますが、そんなに世の中単純じゃないので全てにフィットするものなんてないよね、ということを書かれています。

There is no “one size fits all,” though passionate proponents of various technologies may beg to differ. Alas, the world is not that simple:

そして、こうとも書かれています。

誰もが SSI という用語を好むわけではないことを認識しましょう。デジタルウォレットテクノロジーがこのカテゴリーに該当するかどうかは不明です。そうだと言う人もいれば、そうでない人もいます。 SSI の初期の支持者たちがほぼブロックチェーン技術だけに焦点を当てていたことに、すぐに嫌悪感を抱く人もいます。

すみません。技術としてブロックチェーンの良し悪しを述べるつもりはありませんが、私もSSIアレルギーっぽくなってしまってきているのはこの点なのかもしれません。

そして、色々な切り口でSSIとFederated Identityを比較していっています。

Dicsovery

まずはDiscoveryです。

どちらのモデルでも、個人がどの資格情報を使用するかを選択できる必要があります。これは、Federated Identity 内で、リストから ID プロバイダー (IdP) を選択するか、その ID をダイアログ ボックスに入力できることを意味します。 SSI モデルでは、これは、ローカルに保存された資格情報のリストから選択できること、または適切な資格情報を保存するために使用される適切なコンテナ (別名デジタル ウォレット) を選択できることを意味します。

FederatedモデルではいわゆるNASCAR問題を引き起こす原因でもあるのがこのDiscovery問題ですね。先日ポストしたWebfingerによるDiscoveryや学術機関で使っているDiscovery Service（DS）なんかはこの課題に対応するためのソリューションとして考えられましたが、まだ完全に解決しているとは言えない状態です。

共有される情報の制御

次に触れられているのがIdPとRPの間で共有される情報の制御に関する相違点です。

When talking about federated identity models, protocols like the Security Assertion Markup Language (SAML), OAuth, and OpenID Connect are what describe (and constrain) everything including the claims, the assertions used, the structure of the attributes shared, the way identity provider discovery is handled, and more. A great deal of control is given to both the RP and the IdP, and there is a coarse level of control for the individual (generally in the form of “you can either choose to log in or not, but you aren’t guaranteed control over what information is shared as a result”).

とあるようにやり取りされる情報の内容や構造についての制御の大半はIdPとRPが行うことになり、ユーザが制御できるのは「ログインするのか、しないのか？」程度になってしまいます。

その点、SSIのモデルではユーザによる選択（特にSD-JWTやmDLなどの選択的開示）が中心となっています。

（個人的な意見）これはどうなんだろうなぁ・・・。Federatedだからユーザに選択権がないっていうのは既存のIdPの実装の問題なんじゃないかな？とも思います。本来は属性の選択的開示をするように属性提供同意画面でオプトアウトできるようになっているべきだし、先ほどのNASCAR問題はあるものの使うクレデンシャル（あえてクレデンシャルと言いますが使うIdPのこと）も自分で選ぶことができるようにDiscoveryの設計をするのがRP側の仕事だったのでは？とも思います。これはSSIだったとしてもVerifierが何を求めるのか、Issuerが何を発行するのか、Walletがその情報をどう扱うのか、、など本当にユーザに制御権ってあるんでしょうかねぇ。。とは言え、Federatedモデルではそのあたりの実装有無をIdPやRPが握ってしまっているのは事実ではあります。

横道にそれました。

クロスデバイスのサポート

もう一つのSSIの特徴としてパスワードからの脱却の文脈を含めクロスデバイスの話が出てきます。

(たとえば) 複数のデバイスにパスワードを記憶したりコピーしたりする必要があるのではなく、1 台のモバイル デバイスに保存されている資格情報を、デスクトップやタブレットなどの別のデバイスの認証または認可プロセスで使用できます。

CIBAとかDevice Code Flowがあるじゃないか、とかパスキーでよくない？という話もありそうですが、まぁ確かに特徴の一つではあります。

一方で課題も

これ、本当に大切な問題だと思います。UXとプライバシー。

UX の課題は非常に重大です。 SSI モデルを前進させるために開発中のテクノロジーは、単なる ID をサポートするものではありません。また、支払いシステム、交通チケット、図書館カード、保険カード、ホテルのキー、車のキーなど、リストはさらに続きます。このモデルを、これらすべてのカードを物理的な財布に入れているのと似ていると比較することはできますが、カードが多すぎて、必要なときに適切なカードを見つけることができないという点が生じます

先ほどのNASCAR問題にも通じますが、これまでIdP側で発生していた問題が手元（Wallet）に移動してきただけです。

プライバシーの問題も重大です。

プライバシーへの配慮が使いやすさをさらに難しくしています。資格情報はデジタル ウォレットに保存されることが多く、そのウォレットはランダムなリクエストから資格情報を保護します。おそらく、物理的なウォレットが保持するカードと何の関係もないのと同じように、ウォレットは、保持する認証情報と何の関係も持つべきではありません。ここでの複雑さの可能性を最大限に高めるために、さまざまな認証情報を保持するウォレットが複数ある可能性があります。 

これ、本当に難しい問題でWallet提供者は、そのWalletの中にユーザが何を入れるのか？を把握できたらFederated時代のIdPによる行動把握の比較にならないくらいヤバい話になると思います。この辺りは特に政府が提供するWallet、なんて話も出ていますが十分すぎるくらいの透明性を持たせないといけないと思います。

Digital Identity Wallet（DIW）に関するPoC開発・調査について

https://trustedweb.go.jp/public-offering/2023/trusted_web2023_diw

さらに、どこまでユーザに責任を押し付けるのか、という問題もあります。

人々が正しい選択をする可能性は低いと想定し、さまざまな自由や技術革新を制限することで国民を守るパターナリスティックな国民国家に誰もが住みたいわけではない。とはいえ、その行動の影響が明らかかどうかにかかわらず、自分の行動に責任を個人に負わせる完全な自由主義的な環境での生活を誰もが望んでいるわけではありません。

この辺りは先日ポストした「自己主権型アイデンティティは本当か？情報銀行からの学びはあるのか？」にも書きましたが、本当の意味での情報銀行的な役割をWalletプロバイダが追うことになる日も来るのかもしれません。

https://idmlab.eidentity.jp/2024/03/blog-post_11.html

まとめ

結局結論なんて言うものは出ないわけですが、彼女の以下の3つの言葉が重要だっていうことです。

従来のフェデレーション ID モデルと新しい SSI アーキテクチャは相互に排他的ではありません。彼らはさまざまな問題を解決することだけに集中します。 

現在見られるテクノロジーは完全に完成したわけではなく、技術者が望むすべてを解決するにはまだ成長する必要があります。

これらのテクノロジーの開発と展開の指導に確実に貢献するために、ディスカッションに参加することです。 

これからもコントリビューションしていきましょう。

ログインさせたいユーザを指定してIdPへFederationする（SAML/OpenID Connect）

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

SAMLでもOpenID ConnectでもFederation構成をしているとService Provider（SP）やRelying Party（RP）側であらかじめIdentity Provider（IdP）側で認証させたいユーザ名を指定したいケースがしばしばあります。

典型的なケースの一つは多要素認証をオンデマンドで実行させた場合で、普通のページには第１要素であるユーザ名とパスワードで認証、決済ページには追加要素で認証を要求する、というシナリオは結構あり得るシナリオです。この場合、第１要素で認証されたユーザと追加要素で認証されたユーザをSP/RP側で比較することで同じ人であることを検証することももちろん可能なのですが、できればあらかじめ追加要素で認証させたいユーザの識別子をSP/RPからIdPに渡してあげることで利用者が再度ユーザIDをIdP側で入力する必要がなくなるのでUXも向上します。

この様なシナリオは当然のことながらSAMLでもOpenID Connectでもサポートされています。

SAMLの場合

SAMLを使う場合、SPからのSAML Requestの中にSubjectを指定することができます。

OASISのSAML2.0 coreの仕様の3.4.1のAuthnRequestのエレメントの章に記載があるSubjectが該当します。

SAML 2.0 core仕様

https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

 こんな感じのリクエストになります。

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

                    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"

                    ForceAuthn="false"

                    ID="a133c62aafc8dcee7a69481de5af763c4ee370494"

                    IssueInstant="2024-01-03T03:28:40Z"

                    Destination="https://idp.example.jp/sso/login"

                    AssertionConsumerServiceURL="https://sp.example.com/acs"

                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

                    Version="2.0"

                    >

    <saml:Issuer>https://sp.example.com/sp</saml:Issuer>

    <saml:Subject>

        <saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">test@example.jp</saml:NameID>

    </saml:Subject>

</samlp:AuthnRequest>

実際の動作は上記リクエストを受け取ったIdP側の実装に依存するので利用するIdPの仕様を確認してださい。ちなみにEntra ID（Azure AD）の場合はこの方法ではなくクエリパラメータにlogin_hint=test@example.jpという形で付加してリクエストを投げる形になります。（この辺りを参照：https://learn.microsoft.com/ja-jp/entra/identity-platform/single-sign-on-saml-protocol#subject）ただし、Entra IDが外部IdPとFederationしている時はlogin_hintではなくusername=test@example.jpという形でパラメータ名が異なるので要注意です。

また、Azure AD B2Cでは要求リゾルバという仕組みでSubjectの情報を取得することができるので、このサブジェクトに応じた処理を書けば割と自由に実装ができます。

Okta CIC（旧Auth0）はSAML RequestのSubjectをちゃんと判別してくれそうです。（この辺りを参照：https://community.auth0.com/t/pass-login-hint-to-saml-provider/92546）

OpenID Connectの場合

こちらはシンプルにlogin_hint属性をクエリパラメータに付加することで実現できます。（仕様はこちらを参照；https://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html）こんな感じでAuthentication Requestにパラメータをつけるだけです。

HTTP/1.1 302 Found

  Location: https://server.example.com/authorize?

    response_type=code

    &scope=openid%20profile%20email

    &client_id=s6BhdRkqt3

    &state=af0ifjsldkj

    &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb

    &login_hint=test@example.jp

こちらもSAMLと同様にIdPの実装に依存するので実際の動作はIdPの仕様を確認してみてください。ちなみにAzure AD B2Cの場合はSAMLと同じく要求リゾルバで属性の取得ができます。

ちなみに他にもヒント系のパラメータは色々とあります。

また、SP/RPから認証コンテキストを指定したい場合もあるのですが、現在SAMLについてはAuthnContextClassRefというパラメータがありますが、OpenID Connectについてはacr/amrをclaimsパラメータで渡す方法はありますが、レベルの指定方法の共通化をどうするべきか？についてはPam Dingleさんを中心にIntenet Identity Workshopで議論が続けられているので今後の注目ポイントかもしれません。

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

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

[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連携を構成すれば動くはずです。（やってませんが。。また紹介します）

[SAML]IdPの動作テストに使えるテストSPサイト

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

Azure Active Directory（Azure AD）を含むSAML IdPを構築していると、どうやってテストするかに悩みますよね。

以前、simpleSAMLphpをAzure Web Appにデプロイしてテストする方法を紹介しましたが、今回はもっと簡単な方法を紹介したいと思います。

使うのは、RSAが提供しているSAML 2.0 Test Service Providerです。そのまんまの名前です。
　RSA SAML 2.0 Test Service Provider
　https://sptest.iamshowcase.com/

サイトの説明を読んでいると出来ること、出来ないことはあるようですが簡単なテストであればすぐで出来そうです。

出来ることは以下の通りです。

• IdP Initiated SSO
• SP Initiated SSO
• AuthenticationContextClassRefを指定することによる認証方式の指定
• アサーション内の属性の表示
• 認証状態の表示
• 特定ユーザに指定した認証方式を要求する

逆に出来ないことは、こちらです。

• 署名付きの認証リクエストを送る
• 暗号化されたSAMLアサーションを受け取る

普通にテストする分には十分です。


ということで使ってみました。IdPはAzure ADを使っています。試したのはSP Initiated SSOです。

◆SPの情報を確認する

まずはテストサイト側でシナリオを選びます。
InstructionメニューからSP Initiated SSOを選択します。

するとDOWNLOAD METADATAというボタンが表示されるので、ダウンロードしておきます。これはSP側のMetadataなので、この中にあるSP EntityIDやAssertion Consumer Service（ACS）のURLを、IdPであるAzure AD側へ設定します。

ダウンロードしたMETADATAを開くとこんな感じでEntityIDとACSのURLがありますのでコピーしておきましょう。

◆Azure ADにアプリケーション（SP）を登録する

Azure ADを開き、エンタープライズ・アプリケーションよりギャラリーにないアプリケーションを選択してアプリケーションを作成します。
（SAML系のアプリケーションは、アプリケーション登録のメニューではなく、エンタープライズ・アプリケーションを使いますので注意してください）

適当な名前でアプリケーションを作り、シングルサインオン設定でモードにSAMLベースのSSOを設定、Identifierに先ほどのSP Metadata内のEntityIDを、Reply URLにACS URLを張り付けます。

次に、同じ画面の中からAzure AD側のMETADATA（IdP Metadata）をダウンロードしておきます。

これでAzure AD側のSAML設定はおしまいです。

◆SPにIdP（Azure AD）の情報を登録する

このファイルを先ほどのテストサイトへアップロードします。

アップロードが上手くいくと、ログイン用のURLが払い出されます。

SAML関係の設定はこれで完了です。
本当に簡単です。

◆テストする

あとは先ほど表示されたURLへアクセスすればAzure ADへリダイレクトされるのでログインすればOKなんですが、初期状態のAzure ADはアプリケーションを使えるユーザを割り当てないとログインできないので、アプリケーションへのユーザ割り当てを無効化しておきます。（もちろん明示的にユーザを割り当ててもOKです）

これで本当に準備OKです。
早速先ほど生成されたログインURLへアクセスしてみます。するとAzure ADへリダイレクトされてログインできます。

上手くいくとログインしたユーザのIDが表示されます。

画面をスクロールしていくとSAMLアサーション内の情報が順番に表示されるので意図した通りの情報がSP側へ伝わっているかどうかの確認ができます。

Subjectの情報

認証状態の情報

属性の情報

もちろんアサーション全体を表示することも可能です。

本当に簡単にテストが出来てしまうので非常に便利です。
IdPを構築してもSPがないのでテストがやりにくい、、、という方はぜひお試しください。

Office365のSAML脆弱性に見るマルチテナントSP実装時の注意点

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

しばらく前に世間を騒がせたOffice365のSAML SP実装に関する脆弱性の話が色々と解説されているので、ちょっと動きを細かく見ていきたいと思います。

　騒動の元ネタ
　　The road to hell is paved with SAML Assertions
　　http://www.economyofmechanism.com/office365-authbypass.html

　OAuth.jpでのnov氏による解説記事
　　Office 365 SAML Implementation Vulnerability
　　http://oauth.jp/blog/2016/05/14/office-365-saml-implementation-vulnerability/

　John Bradley氏による解説
　　Azure AD security issue
　　http://www.thread-safe.com/2016/05/azure-ad-security-issue.html

　Internet2での解説
　　Scoped User Identifiers
　　https://spaces.internet2.edu/display/InCFederation/2016/05/08/Scoped+User+Identifiers


まぁ、起きていた事象と根本的な原因はIdPが発行したクレームを無条件に信じてしまっていたことにより他のテナントのユーザになりすましてしまうことが出来たよ、ということなので、ちゃんとVerifyしようよ、という話になっています。

◆何が起きていたのか再現してみる

と、言ってもすでにOffice365の脆弱性は修正済みなので、起きていたであろうことをAD FSとGoogle Appsを使って再現してみました。

AttackerとVictimの2つのIdPをAzure ADが収容して、共通のアプリケーションを利用する、という構図をGoogle AppsとAD FSを使って再現したのが以下の図のようなシステム構成になります。

Azure AD相当のAD FSが各IdPから渡ってきたEmailアドレスをストレートにNameIDに変換してアプリケーション（Google Apps）へ渡してしまうので、VictimにもAttackerにも同じメールアドレスのユーザが存在するとAttackerもGoogle Appsへログインできてしまいます。
（もちろん実際のOffice365/Azure ADではもう少し複雑な動きのはずですが、解説のためものすごく簡略化しています）

◆実際の動作

まず、各IdPに同じメールアドレスを持ったユーザを作成します。これは簡単ですね。Active Directoryのユーザとコンピュータからユーザのメールアドレス属性を編集してあげるだけです。

この状態でGoogle AppsへアクセスするとAzure ADに相当するAD FS（今回はHUBと呼びます）へリダイレクトされ、IdPの選択をするホームレルムディスカバリ画面が表示されます。これは、Office365の場合、メールアドレスのドメインパートで自動的に振り分けるような仕組みになっていますよね。

まずは正常系です。
ここでvictimを選択するとvictim側のAD FSへ再度リダイレクトされ、victim側のユーザでの認証が行われます。

もちろんここでログインすると問題なくGoogle Appsへアクセスできます。


今度は先ほどのIdP選択画面でattackerを選択してみましょう。
同じくattackerのログイン画面が表示されるので、attackerのユーザでログインしてみます。

すると、意図しないユーザであるにも関わらずGoogle Appsへのログインができてしまいます。

右上のユーザ名を見るとvictimのユーザとしてログインできていることがわかります。

これが問題です。

◆構成を見てみる

では、この環境がどのように構成されているのか見ていきましょう。

まずはHUBとなるAD FSの構成です。

Relying Partyには当然Google Appsが構成されています。

HUBとなっているので、IdPから渡ってくるEmailアドレス属性をNameIDへマッピングして出力を行うクレーム・ルールが設定されています。

次に、HUBのIdP（Claim Provider）設定を見てみます。マルチテナントで構成されているので当然victimおよびattackerがIdPとして登録されています。

そして、各IdPのクレーム・ルールを見ると単純に各IdPから渡ってくるEmailアドレスをパススルーしています。ここが大きな問題です。

取り敢えず問題は置いておいて、次に行きます。

次は各IdP側のRP設定を見ていきます。
当然、victim側にもattacker側にもRPとしてHUBが登録されています。

こちらがvictim側です。

こちらがattacker側です。

この辺りは特に不思議なところはありません。
クレーム・ルールも共通で以下の通り、ADのEmailアドレスをそのまま発行しています。

構成はこれで終わりです。
次はSAML Tracerを使って動きを見てみます。

◆SAML Assertionの中身の確認

まず、正常パターンです。victimで認証されてSAML ResponseがHUBへ返ります。

属性ステートメントにメールアドレス属性が正しく入っていることがわかります。

同様にattackerも見てみます。

先のルールだとattackerからもメールアドレス属性をそのまま発行することになるので、HUBへのSAML Responseにはメールアドレスが入ります。これは正常な動きです。

では、attackerからのResponseを受けたHUBがGoogle Appsへ返すSAML Responseを見てみます。

いけませんね。NameIDにvictimのメールアドレスが入ってしまっています。

Google Appsから見るとこのResponseはあくまでHUBから返ってきており、AssertionのIssuer（HUB）および署名（HUBのAD FS Token Sign）の検証が出来てしまうので、正しいAssertionだと認識してしまい、ログインが完了してしまいます。

◆どうやってなりすましを防ぐか？

では、ここからが対策です。
要するにHUBが配下のIdPから飛んでくるクレームを無条件に上位のアプリケーションへ発行してしまっているのが問題なので、フィルタリングを入れておきたいと思います。

具体的には、victimから飛んでくるメールアドレスはvictimの、attackerから飛んでくるメールアドレスはattackerの固有のドメインパートを持っている、という暗黙の前提の通りになっているかどうか？を確認し、正しければスルーしますし、異なっていたらフィルタリングしてしまいます。

AD FSにおいて、この設定はClaim Providerのクレーム・ルール設定で行います。

以下がvictim側の設定です。

次にattacker側の設定です。

この状態における実際のAssertionはどうなっているでしょうか？

まずは正常系（victim）です。メールアドレスがvictimorg.xyzで終わっているのでスルーされてAssertionに値が入ります。

しかし、attacker側ではメールアドレスがattackerorg.xyzで終わることが期待されるところにvictimorg.xyzが入ってきているのでフィルタされ、Assertionに値が入りません。

こうなるとGoogle Appsへのログインは失敗し、なりすましはできなくなりました。

◆対策とまとめ

結局のところは、「外部のIdPとフェデレーションを行う際はIdPの信頼性の担保が出来ているかどうかを確認すべし！」という話なんですが、「じゃあ、どうやって？」というところで例えばメールアドレスを使うOffice365やGoogle Appsなんかの場合は、暗黙の前提となっているドメインパートに正しい値が入ってくるであろう、という部分を排除してきっちりとフィルタリングをするという対策が必要になりますし、他の属性を使う場合でも、その属性に入ってくる値は当該のIdPで正しさが保証されているものなのか？を中間IdPやRP側でも確認をすることは必須である、ということが出来ます。

オンプレミスのActive Directoryの信頼関係でも同じですが、技術的につながるからと言って無条件につなぐと当然セキュリティ・ホールが出来上がるので、文字通り「信頼」をするためには必要な対策をちゃんとしましょう、ということです。

また、これはSAMLでもws-federationでもOpenID Connectでも全く同じことですので、うちのサービスはSAMLじゃないから大丈夫、と言ってスルーしないでください。

参考までに、ですがAD FSでは外部IdPから発行されたクレームを無条件にパススルーしようとすると以下のワーニングが表示されます。

ワーニングにはちゃんと意味があるので、みなさん従いましょうね。