What Is IPSIE? Dick Hardt @ AuthCon 2025 (JA)

• Dick Hardt
  • こんにちは。私の名前はDick Hardtです。今日はIPSIEについて、そしてIPSIEによって“oopsie”を減らす方法についてお話しします。
  • 私のバックグラウンドを少し紹介します。私はシリアルアントレプレナーで、いくつかの会社を創業してきました。Perl 5をWindowsに移植した後にActiveStateを創業し、その後Sxip IdentityでIdentity領域に深く関わるようになり、そして直近ではHellō Identityを創業しました。Microsoftでの勤務経験もあり、AWSとAlexaでもしばらく働きました。OAuth 2とJSON Web Tokensの設計をリードし、現在はOAuth 2.1、IPSIE、そしてOpenID Provider Commands（OP Commands）に取り組んでいます。
  • では、IPSIEとは何でしょうか？なぜ気にするべきなのでしょうか？Enterprise identity and access managementにおける現在の課題は何で、IPSIE profilesはそれをどう解決するのでしょうか？そして最後にQ&Aを行います。
  • IPSIEはOpenID Foundationのworking groupで、Interoperability Profiling for Secure Identity in the Enterpriseの略です。最終的にはSAML、OpenID Connect（OIDC）、SCIM、OP Commandsといったもののprofilesが用意されます。IPSIEの目的は、EnterpriseでIdentity系のことを行う際に、それをどうすればよりsecureにできるか、ということです。

• Dick Hardt
  • かなりacronym soup（略語だらけ）だったので、もう少し詳しく説明します。
  • single sign-on（SSO）があります。これは2つの異なるprotocol、SAML（Security Assertion Markup Language）とOIDC（OpenID Connect）で実現されます。OIDCはOAuth 2の上に成り立っています。OAuthとOpenID Connectを同じように話す人もよくいますが、もし「ログインしてID Tokenを受け取る」話をしているなら、それは本当はOpenID Connectの話をしています。
  • Enterprise identity and access managementのもう一つの側面はdirectory synchronizationです。これを行うためのprotocolの一つで、広く導入されているのがSCIM（System for Cross-domain Identity Management）です。そして私が他の多くの人たちと一緒に取り組んでいる新しいものがOP Commands、つまりOpenID Provider Commandsです。OP Commandsが何なのかについては、この後の話でさらに詳しく説明します。

• Dick Hardt
  • では、これらのEnterprise identity and access management protocolsがどうつながっているかを説明します。上にいるのはuser、つまり従業員です。従業員はenterprise（しばしばIdentity Provider、あるいはOpenID Providerとも呼ばれます）でログインし、そこからapplicationへ行きます。その際、tokenのようなもの、あるいはassertionを提示して自分が誰かを確立します。そうするとapplication（別名Service Provider（SP）、別名Relying Party（RP））は、そのuserが誰かを把握できます。
  • そのtokenには、userに関するclaims、例えばemail address、name、所属するgroupsなどが含まれることがあります。またSAMLのようなものではdepartmentやlocationが含まれることもあります。
  • identity service（enterprise）とapplicationの間には、application内のusersを直接管理するためのprotocolがあります。その一つがSCIMで、もう一つがOP Commandsです。

• Dick Hardt
  • では、なぜenterpriseはこれを求めるのでしょうか？彼らはcentralized identity managementを求めています。これにより、usersは1か所でログインできますが、enterprise側はusersがどうログインするかを制御できます。つまりstrong authenticationを行えて、それが本当に自社のuserであるというhigh confidenceを持てます。enterpriseが管理できない別のcredentialsでuserがapplicationにログインしてしまう状況とは対照的です。
  • centralized identity managementがあると、変更を1回行うだけでそれがどこにでも反映されます。またdirectoryを見て（一般に、いくつか注意点はあるものの）complianceとsecurityの観点で「誰が何にアクセスできるか」を把握できます。つまり、特定の情報や機能にアクセスできるべき人だけが実際にアクセスできている、という確信を持てます。
  • centralized managementはonboardingとoffboardingも簡単にします。現代の組織では数百のapplicationを持つことがあり、userのroleに応じて、異なる権限や異なるapplicationへのアクセスを持ちます。centralに管理することで、userを追加したり削除したりすると、その変更が全てのapplicationに反映されます。

• Dick Hardt
  • ここには、enterpriseがapplicationをどう使うかという成熟度（maturity curve）があります。最初はPLG（product-led growth）から始まります。ここでは一部のusersが、まだ組織に管理されていないapplicationにセルフサービスでサインアップします。この場合、usersはusername/passwordやsocial login（例えばGitHub accountやGoogle account）を使うかもしれません。
  • 次に、enterpriseがuserを管理し始める段階に進み、basic single sign-onになります。この場合applicationはuserが誰かを把握でき、userが従業員でなくなったらログインできなくなります。これにより、退職時にアクセスを剥奪でき、またstrong authenticationを確保できるのでaccount takeoverの防止に役立ちます。
  • 次の段階はjust-in-time provisioningです。ログイン時のtokenにemail address、name、所属するgroupsなどが含まれます。applicationがそのuserを初めて見たときに、そのuserがprovisionされます。これが第3フェーズです。
  • そして最後のフェーズは、central directoryとapplicationの間でsynchronizationを行うところです。directoryに変更があるたびに、それが全てのapplicationに反映されます。

• Dick Hardt
  • SAMLによるEnterprise SSOについて、業界ではよく「choose your own adventure（選べる選択肢が多すぎる）」と言います。SAMLはframeworkで、作られた当時に多様な要件があったため、非常に多くのことができます。特定の情報を含めるように設定したり、異なるcredentialsを含めたり、名前の付け方も自由にできます。例えばnameやmanagerなどに別のlabelを付けることもできます。
  • これは多くの意味で強力で、何でもできるようなところがあります。しかし欠点は、何でもできてしまうことです。security teamは起こりうる悪いことを心配するので、悪いことが起きないようにするための様々な要求を作り出します。
  • 結果としてenterpriseは「これが我々のsecurity profileだ。applicationを我々のenterpriseに接続したいなら、こうしなさい」と決めます。そしてenterpriseごとにかなりユニークで、security requirements同士が一貫していないこともあります。なので最終的に、enterpriseごとにかなり“変な”形のものになります。
  • さらに、developerとしてこれを実装・デプロイする際、requirementsにギャップがあることもよくあります。ここでは何をすべきか、あそこでは何をすべきかが明確ではありません。選択肢が多すぎて、場合によってはそれがspecifyされていないので、何をすべきかがはっきりしません。
  • そのため、構築・デプロイが難しくなります。各enterpriseごとにcustomであり、しかもSAMLにはconformance testがありません。できることが多すぎるので、テストを走らせて「正しくできた」と言うことができません。
  • そうすると、システムやプロセスの間にギャップや穴が生まれ、全体にholesができてしまいます。そして時にはそれが“oopsie”につながり、unauthorizedな人が何らかの形でresourcesにアクセスしてしまいます。

• Dick Hardt
  • では、IPSIEがそれをどう解決するのかを話します。IPSIEにはprofilesがあります。これはprofileの図として私が思いついたベストなイメージです。profilesは、applicationとenterpriseの間のsecurityとinteroperabilityに関する現在のbest practicesです。
  • これらは非常にopinionatedなspecで、「これをやりなさい」という形で必要事項を明確にします。profilesにはconformance testingが用意され、applicationとenterpriseが正しいことをしているかテストできます。さらにcertificationsも可能で、他者に対してconformしていることを証明できます。そしてenterpriseとapplicationの要件に応じた、異なるmaturity levelsがあります。

• Dick Hardt
  • 一つの軸はsession lifecycleです。つまり、ログインしてログアウトするようなことです。session lifecycleには3つのレベルがあり、SL1、SL2、SL3です。それぞれのレベルで、applicationが何をすべきか、identity serviceが何をすべきかが定義され、両者がきちんと対応し、session lifecycleにおける一定のsecurityレベルを満たすようにします。
  • IPSIEのもう一つの軸はidentity lifecycleです。これはaccountを管理し、誰が何をできるかを扱います。IL1では、usersを管理して削除するだけです。IL2ではgroupsが入ってきて、より細かい制御ができます。groupのmembershipを変えると、それがapplicationsに反映され、誰が何をできるかが変わります。
  • application側では、enterpriseの水平概念であるgroupを、application内で何ができるかという垂直概念にマッピングします。つまり、application内の機能（またはroles）とgroupsのマッピングはapplication側で行われます。
  • IL3はさらに一段深く、applicationが自分のrolesを公開し、identity serviceがそのrolesと、特定userに関する全ての情報を見て、各userがそのapplicationでどのrolesを持つべきかを決めます。
  • 現時点ではIPSIEにはまだ初期draftがいくつかあるだけです。OpenID ConnectのSL1のdraftと、SCIMのIL1のdraftの初期段階があります。

• Dick Hardt
  • では先ほど触れたOpenID Provider Commandsについて話します。SCIMは、applicationがSCIM APIを管理するためにOAuth serverなどを立てる必要があります（SCIM APIはapplicationのusersを管理するためのREST呼び出しの集合です）。それに対してOP Commandsはかなりシンプルです。
  • commandを含んだtokenを生成し、そのtokenはID Tokenと同じように検証されます。つまり、すでにenterpriseとOpenID Connectをサポートしているなら、OP Commandsをサポートするのは小さなステップで、account lifecycleの機能を提供できるようになります。
  • そして重要なのは、これはeventsではなくcommandsだということです。OP（enterprise）が「あなた（application）にこれをしてほしい」と、特定のことを要求するのです。
  • 最初のcommandはmetadata commandで、OPがRP（application）がどんなcommandsをサポートしているかの一覧を取得します。これによりOPは「私のsecurity policiesに準拠するために、あなたは私が求めるcommandsを全部サポートしているか？」と判断できます。
  • もしRPがサポートしていないなら、OPは「ではユーザーがログインするためのID Tokensをあなたには発行しない。必要なことをサポートしていないからだ」と決められます。例えば、その次に出てくるunauthorized commandはその一例です。
  • この機能は、現在のstandardsではうまく表現されていません。unauthorized commandは、OPが全てのRPに対して「この1人のuserが持つアクセスを全てunauthorizedにしてほしい」と伝えることを可能にします。
  • その理由は、breachesの増加により、OPが「悪意ある者がdeviceやユーザーアカウントを乗っ取ったかもしれない」と疑う状況があるからです。そして全てがクリーンアップされることを確実にしたい。特に今日では、mobile appや長期間生存するsessionがあり、web sessionに紐づいていないこともあります。攻撃者がresourcesにアクセスしてしまっている場合、単なるlogoutではそれが片付かないことがあります。unauthorized commandは、それを一掃するのに役立ちます。
  • 今それをやる方法は、SCIMでのかなり力技なアプローチで、accountをdisableしてしまうことです。これは、全部をクリーンアップするためにコンピュータの電源を入れ直すようなものです。
  • 次のcommandはaudit commandです。これはOPが「あなた（application）は私のためにどのusersを持っている？それらusersの状態はどうなっている？」を把握して、同期が取れていることを確認するのに役立ちます。
  • またmigrationでも非常に有用です。enterpriseが最初からusers管理を始めることは稀で、最初はPLG usersがいて、enterpriseのemailでサインアップしログインしていたかもしれません。そこからenterpriseが管理したくなる。audit commandによりOPは「私のusersをあなたはどれだけ持っている？」と確認でき、「それらのaccountsの管理を引き継ぐ」と言えるようになります。
  • そしてさらに、SCIMにあるような単なるenable/disableよりも、はるかに豊かなaccount lifecycle managementを可能にする複数のcommandsがあります。
  • それらは、標準化されたISO account lifecycleに従って、異なるstate間を遷移します。deletedとactiveだけではなく、archiveやsuspendなどもできます。これは、多くのenterpriseが持つより豊かなlifecycleによりよく対応します。

• Dick Hardt
  • まとめです。今日何を話したでしょうか？
  • もしあなたがB2B SaaSをやっているなら、顧客はいずれenterprise integrationを要求するようになります。最初の段階では、early adoptersはそれがなくても使ってくれるかもしれません。でもいずれenterprise readyである必要が出てきます。そしてenterpriseは「これらのcapabilitiesがないとあなたのapplicationは使えない」と言うでしょう。特に、applicationがenterpriseにとってより重要になるほど、その要求は強まります。
  • 次に学んだのは、SSOというだけでは非常に曖昧だということです。人は「SSOが欲しい」と言い、別の人は「SSOを提供します」と言う。でもその意味はenterpriseごとに大きく異なります。
  • IPSIEは、明確でsecureな異なるlevelsを提供します。だからあなたは「IPSIE SL2をサポートしています」と言え、enterpriseは「それが必要なんだ」と言えます。これにより、販売コストが劇的に下がり、デプロイが簡単になります。enterpriseごとにバラバラだったものではなく、複数のlevelsとして標準化されるからです。
  • そしてもちろん、IPSIEの大きな利点の一つは、“oopsie”が減ることです。
  • IPSIEについてもっと知りたければ、openid.netのこのURLにあるworking groupを見てください。既存のstandardsを見ながら追うこともできます。興味がある人には、working groupに参加してフィードバックを提供してほしいと思っています。public forumなので、issuesを登録できます。
  • そして、Hellōで私がやっていることについてもっと知りたければ、dickhardt@hello.com までメールをください。
  • ありがとうございました。