米国 NSA デベロッパーとベンダーの課題：アイデンティティとアクセス管理

こんにちは、丸山満彦です。

NSAが、デベロッパーとベンダーの課題：アイデンティティとアクセス管理という報告書を公表していますね。。。

• 多要素認証
• SSOとフェデレーション

についての記載がありますね。。。

IAMは、技術＋運用の問題なので、実装にあたっては、特に設計が重要ですよね。。。

記載内容は基本的なことが中心ですが、だからこそ、復習も兼ねて読んでみるとよいと思います。

・2023.10.04 [PDF] ESF: Identity and Access Management: Developer and Vendor Challenges

目次...

Contents	目次
Executive Summary	エグゼクティブサマリー
Introduction	序文
Scope	範囲
Key Challenges	主な課題
Multi-Factor Authentication	多要素認証
MFA Definitional and Policy Challenges	MFAの定義とポリシーの課題
MFA Adoption Challenges	MFA導入の課題
MFA Sustainment and Governance Challenges	MFAの維持とガバナンスの課題
SSO and Identity Federation	SSOとアイデンティティ・フェデレーション
Complexity and Usability Challenges	複雑性とユーザビリティの課題
Standards Improvement Opportunities	標準改善の機会
Ecosystem Challenges	エコシステムの課題
Conclusions	結論
Appendix I: Key Recommendations for Vendors	附属書 I： ベンダーへの主な提言

内容...

Executive Summary	要旨
Since the introduction of multi-user computer systems, user authentication has primarily relied on the use of usernames and passwords. To strengthen the authentication process, Multi-Factor Authentication (MFA) requires the user to present multiple elements in different categories, or “factors”, as part of an authentication attempt. These factors are something you have, something you know, and something you are. Similarly, Single Sign-On (SSO) provides a risk mitigation capability by centralizing the management and control of authentication and access across multiple systems and from multiple identity providers. Implemented properly, it can raise the authentication assurance level required for initial sign on and can control and secure the authentication and authorization information passed between systems.	マルチユーザーコンピュータシステムの序文以来、本人認証は主にユーザ名とパスワードの 使用に依存してきた。認証プロセスを強化するために、多要素認証（MFA）は、認証試行の一部として、異なるカテゴ リの複数の要素、すなわち「要素」の提示をユーザに要求する。これらの要素とは、「持っているもの」、「知っているもの」、「自分であるもの」である。同様に、シングルサインオン（SSO）は、複数のシステムおよび複数の ID プロバイダから の認証およびアクセスの管理と制御を一元化することによって、リスク軽減機能を提供する。適切に実装されれば、初回サインオンに必要な本人認証保証レベルを引き上げ、シス テム間で渡される認証および認可情報を制御し、保護することができる。
Following on the work the Enduring Security Framework (ESF) published on identity and access management (IAM) best practices for administrators, targeted for administrators to make the best use of existing solutions, a working panel staffed by subject matter experts from both government and industry was tasked with assessing developer and vendor challenges relating to IAM. The working panel specifically identified the adoption and secure employment of MFA and SSO technologies as a key developer and vendor challenge that has been difficult to meet with the technology that is currently available.	ガバナンス・フレームワーク（ESF）が発表した、管理者のためのアイデンティティ・ アクセス管理（IAM）のベスト・プラクティスに関する作業（管理者が既存のソリューショ ンを最大限に活用できるようにすることを目標）に続き、政府と産業界の専門家で構成された ワーキング・パネルが、IAM に関する開発者とベンダの課題を評価する任務を負った。作業部会は、特に、現在利用可能な技術では満たすことが困難なMFAとSSO技術の採用と安全な利用を、主要な開発者とベンダーの課題として特定した。
Introduction	序文
Successful implementation of IAM in an organization involves both technology and processes; successful implementation of secure IAM capabilities depends on the vendor community to provide solutions to achieve secure outcomes. One key factor the vendor community must be cognizant of is the interoperability of IAM solutions since no single vendor can solve all IAM challenges an organization may face. Only by working together can these solutions enable successful and secure outcomes. IAM solutions must enable an organization’s staff to distinguish legitimate users conducting the organization’s mission from unauthorized entities attempting to access the infrastructure while also support a timely and effective response to indicators of compromise. Malicious actors are opportunistic and will attempt to impersonate, influence, or exploit legitimate entities to make this distinction harder, and they will take advantage of gaps in the ability to manage the entities and their accesses.	組織におけるIAMの実装を成功させるには、テクノロジーとプロセスの両方が必要である。セキュアなIAM機能の実装を成功させるには、セキュアな結果を達成するためのソリューションを提供するベンダーコミュニティに依存する。ベンダーコミュニティが認識しなければならない重要な要素の1つは、IAMソリューションの相互運用性である。これらのソリューションが連携することによってのみ、成功裏に安全な結果を得ることができる。IAMソリューションは、組織のスタッフが、組織のミッションを遂行する正当なユーザーと、インフラにアクセスしようとする無許可の事業体を区別できるようにしなければならない。悪意のある行為者は日和見主義であり、この区別を困難にするために正当な事業体になりすましたり、影響を与えたり、悪用しようとし、事業体とそのアクセスを管理する能力のギャップを利用する。
This document focuses on technical gaps and challenges related to adoption and secure employment of MFA and SSO technology. The expectation is to enable developers and integrators to refine their existing tools to address the gaps and, if necessary, develop new tools to address the challenges for their products and solutions. Further, this paper also touches on, to some degree, key non-technical challenges such as cost, staffing, and user experience impacts of employing these technologies.	この文書では、MFA と SSO 技術の採用と安全な運用に関する技術的なギャップと課題に 焦点を当てる。期待されることは、開発者とインテグレータが、ギャップに対処するために既存 のツールを改良し、必要であれば、彼らの製品とソリューションのための課題に対処 する新しいツールを開発することを可能にすることである。さらに本稿では、これらの技術を採用することによるコスト、人員配置、ユーザー・エクスペリエンスへの影響など、技術面以外の重要な課題にもある程度触れている。
Scope	適用範囲
While the working group recognizes the broad scope of the challenges relating to MFA and SSO, this paper specifically addresses challenges that are informed by an understanding of threats in the IAM space that are actively being exploited by adversaries. This paper is targeted at the challenges facing sophisticated organizations with substantial resources and high-end adversaries, though it also touches on some challenges (e.g., cost or ease of implementation) that inhibit less sophisticated organizations defending against more rudimentary adversaries.	ワーキンググループはMFAとSSOに関連する課題の広範な範囲を認識しているが、本稿は特に、敵対者によって積極的に悪用されているIAM空間における脅威の理解によってもたらされる課題を取り上げている。このペーパーは、相当なリソースを持つ洗練された組織とハイエンドの敵対者が直面する課題を対象としているが、より初歩的な敵対者から防御する洗練されていない組織を阻害するいくつかの課題（例えば、コストや実装の容易さ）にも触れている。
Key Challenges	主な課題
Multi-Factor Authentication	多要素認証
MFA is widely recognized as one, if not the most, important preventative security controls available today. It provides a strong defense against various adversarial attack techniques such as password spraying[1], compromised password reuse[2], and—in some instances— phishing[3] However, a key challenge is that it is notoriously difficult to deploy and many organizations, small and large, still have not done so even if they recognize the value. In this section, we will focus on three types of challenges related to MFA implementation: definitional and policy challenges in the vendor community, deployment and adoption related challenges, and sustainment and governance related challenges.	MFA は、今日利用可能な最も重要な予防的セキュリティ対策ではないにせよ、その 1 つとして広く認識されている。しかし、重要な課題は、MFAの導入が難しいことで有名であり、大小を問わず、多くの組織がその価値を認識しながらも導入していないことである。このセクションでは、MFA の実装に関連する 3 種類の課題に焦点を当てる。ベンダ ーコミュニティにおける定義とポリシーの課題、展開と採用に関連する課題、そして維持 とガバナンスに関連する課題である。
MFA Definitional and Policy Challenges	MFA の定義とポリシーの課題
MFA deployment is notoriously difficult for many organizations. One reason is due to confusing definitions and unclear policy around different variations of MFA. Indeed, organizations often turn to forms of MFA believed to be easy to deploy, such as those based on short messaging service (SMS), without careful evaluation of the relative security differences between MFA options. There is a need for clarity, interoperability, and standardization amongst MFA variations to allow organizations to make value comparisons and to integrate these solutions into their environment. This starts with basic steps such as using common terminology; terms like “2-step verification”, “two-factor authentication”, and “multi-factor authentication” are all widely used to describe similar capabilities. Although in some cases there are subtle technical differences between various market terms, the confusion on terminology across the vendor community makes it difficult to articulate best practices for organizations to follow. Furthermore, organizations with a desire, or mandate, for MFA often don’t know what types of authentication mechanisms are available in a particular identity solution, if the MFA solution is compatible with their existing systems, or if potential new IAM solutions are compatible with the MFA they already have. It is incumbent upon the IAM vendor community to work together to agree on terminology standardization when discussing MFA to avoid confusion amongst organizations making the decision to implement MFA within their respective. An architectures’ related problem is that generic vendor terminology such as ‘push notification’ does not map cleanly to technical security properties such as those articulated by the National Institute of Standards and Technology (NIST) Special Publication (SP) 800-63,[4] Digital Identity Guidelines. In the context of government systems, self-validation instructions are being developed by federal Identity, Credential, and Access Management (ICAM) groups.[5] However, vendors have not yet consistently documented the mapping of their products to NIST requirements and organizations have little evidence on which to evaluate the mappings that vendors do produce.	MFAの導入は、多くの組織にとって難しいことで知られている。その理由の1つは、MFAのさまざまなバリエーションをめぐる定義の混乱とポリシーの不明確さにある。実際、組織は、MFAオプション間の相対的なセキュリティの違いを注意深く評価することなく、ショート・メッセージング・サービス（SMS）に基づくものなど、導入が容易と思われる形態のMFAに目を向けることが多い。組織が価値を比較し、これらのソリューションを環境に統合できるようにするために、MFAのバリエーション間の明確化、相互運用性、標準化が必要である。これは、「2 段階認証」、「2 要素認証」、「多要素認証」といった用語が、類似の機能を表すた めに広く使われているように、共通の用語を使うといった基本的なステップから始まる。場合によっては、さまざまな市場用語の間に微妙な技術的差異があることもあるが、ベンダ ー・コミュニティ全体における用語の混乱は、組織が従うべきベスト・プラクティスを明 確にすることを困難にしている。さらに、MFA を望んでいる、または MFA を義務付けられている組織は、特定の ID ソ リューションでどのような種類の認証メカニズムが利用可能か、MFA ソリューションが既存のシス テムと互換性があるかどうか、または新しい IAM ソリューション候補がすでに持っている MFA と互換性があるかどうかを知らないことが多い。IAM ベンダ・コミュニティは、MFA を議論するときに用語の標準化に合意して、各組織で MFA の実装を決定する際の混乱を回避するために協力する義務がある。機構に関連する問題は、「プッシュ通知」などの標準的なベンダー用語が、国立標準技術研究所（NIST）特別刊行物（SP）800-63「[4] デジタル ID ガイドライン」で明示されているような技術的なセキュリティ特性 にきれいに対応しないことである。政府システムのコンテキストでは、連邦政府の ID、クレデンシャル、およびアクセス管理（ICAM）グループによって自己検証指示が作成されている[5]。しかし、ベンダは自社製品の NIST 要件へのマッピングを一貫して文書化しておらず、組織はベンダが作成したマッピングを評価する根拠をほとんど持っていない。
A second problem impeding adoption of MFA is the lack of clarity regarding the security properties that certain implementations provide. In SP 800-63, NIST articulates a set of “Authenticator Assurance Levels” (AALs) as one way of classifying the relative strength of authenticators based on the security properties that they provide.[6] According to NIST, MFA is required at “AAL2” and “AAL3”. At its core, MFA seeks to address two classes of threat: those related to password reuse and compromise, and those related to adversarial use of phishing.	MFA の採用を妨げている第二の問題は、特定の実装が提供するセキュリティ特性に関する明 確さの欠如である。SP 800-63 において、NIST は、認証者が提供するセキュリティ特性に基づいて認証者の相対的な強度を分類する一つの方法として、一連の「認証者保証レベル」（Authenticator Assurance Levels）（AALs）を明示している[6]。NIST によれば、MFA は「AAL2」および「AAL3」で要求される。MFA の中核は、パスワードの再利用と漏洩に関連する脅威と、フィッシングの敵対的な使用に関連する 脅威の 2 つのクラスに対処することである。
All forms of MFA provide some protection against password reuse and compromise, though with differing levels of security. For example, SMS-based MFA is vulnerable to a variety of attacks that may expose the one-time code to threat actors and is considered among the least secure MFA options. Other forms of MFA, using separate hardware storage (whether on a physically separate device or a separated embedded hardware module), are highly resistant to the extraction of the secret key. In addition to attacks related to password reuse and compromise, some forms of MFA are resistant to phishing attacks. For example, the more sophisticated phishing attacks, are capable of intercepting one-time codes in real time and relaying them to the system to which the user is attempting to authenticate. However, some types of MFA, such as those based on public key infrastructure (PKI) or FIDO2,[7] are resistant to such phishing attacks through the cryptographic binding of authentication to either the session with or identity of the system verifying the credential. Vendors have a real opportunity to lead the industry and build trust with product consumers with additional investments to bring such phishing-resistant authenticators to more use cases, as well as simplifying and further standardizing their adoption, including in form factors embedded into operating systems, would greatly enhance the market.	すべての形態の MFA は、セキュリティのレベルは異なるが、パスワードの再利用と危殆化に対してある程度の防御を提供する。例えば、SMS ベースの MFA は、脅威行為者にワンタイムコードを公開する可能性のある様々な攻撃に脆弱性 であり、最も安全性の低い MFA の選択肢の一つと考えられている。その他の形式の MFA は、（物理的に分離されたデバイス上であれ、分離された組込 みハードウェアモジュール上であれ）分離されたハードウェアストレージを使用し、秘密キーの 抽出に対して高い耐性を持つ。パスワードの再利用や漏洩に関連する攻撃に加えて、MFA の中にはフィッシング攻撃に耐性を持つものもある。例えば、より巧妙なフィッシング攻撃は、ワンタイムコードをリアルタイムで傍受し、 ユーザが本人認証を行おうとしているシステムに中継することができる。しかし、公開鍵基盤（PKI）や FIDO2 [7]に基づくものなど、いくつかのタイプの MFA は、認証がクレデンシャル を検証するシステムとのセッションまたはシステムの ID のいずれかに暗号学的にバインドされる ことによって、このようなフィッシング攻撃に対して耐性がある。ベンダーは、このようなフィッシングに耐性のある認証機能をより多くのユースケースに導入す るための追加投資によって、業界をリードし、製品消費者との信頼関係を構築する真の機会を持 っており、オペレーティング・システムに組み込まれるフォーム・ファクタを含め、その 採用を簡素化し、さらに標準化することは、市場を大いに強化することになる。
MFA Adoption Challenges	MFA 導入の課題
In addition to areas where vendors could aid in defining and articulating MFA security properties, vendors could also help advance other MFA deployment issues within large and complex organizations. One such issue is support for the strongest forms of MFA, such as those based on PKI and FIDO2 standards, in vendor products. Most IAM vendors offering SSO products support both PKI and FIDO2 authentication, but some do not. And even where such support exists, it is often incomplete. For example, PKI may not be treated as a “multifactor” authenticator within authentication policy because it is an authenticator that provides multiple “factors” due to the way its cryptographic keys are unlocked. Similarly, restrictions may exist on the types of FIDO2 authenticators that can be registered (e.g. those with exportable keys, those embedded in platforms, those using server side key storage) and the ability to define policy based on attestation may be lacking. Such enterprise features are critical to adoption. In the case of both FIDO2 and PKI, support on client platforms is also inconsistent. For example, iOS and Android phones/operating systems both support FIDO2 and PKI (enrolled through Mobile Device Management), but may not support all required security or protocol versions (e.g. device bound FIDO2 keys, key storage in embedded hardware modules, or external tokens). Additional vendor investment in supporting high assurance MFA implementations for enterprise use on both mobile and desktop platforms in a maximally user-friendly flow would substantially aid in MFA adoption by organizations of all sizes.	ベンダーが MFA セキュリティ特性の定義と明確化を支援できる分野に加え、ベンダーは、大規 模で複雑な組織内での MFA 導入に関するその他の課題の解決にも貢献できる。そのような問題の1つは、ベンダー製品におけるPKIやFIDO2標準に基づくような、最も強力な形態のMFAのサポートである。SSO製品を提供するほとんどのIAMベンダーは、PKI認証とFIDO2認証の両方をサポートしているが、中にはサポートしていないベンダーもある。また、そのようなサポートがある場合でも、不完全な場合が多い。たとえば、PKI は、暗号鍵のロック解除方法によって複数の「要素」を提供する認証機 能であるため、認証ポリシー内で「多要素」認証として扱われない場合がある。同様に、登録可能な FIDO2 認証者の種類（鍵のエクスポートが可能なもの、プラッ トフォームに組み込まれたもの、サーバ側の鍵ストレージを使用するものなど）には制限があ り、認証に基づくポリシーを定義する機能が欠けている可能性がある。このようなエンタープライズ機能は、普及に不可欠である。FIDO2とPKIの場合、クライアント・プラットフォームのサポートにも一貫性がない。例えば、iOSとAndroidの携帯電話／オペレーティングシステムは、どちらもFIDO2とPKI（モバイルデバイス管理を通じて登録）をサポートしているが、必要なセキュリティやプロトコルのバージョン（デバイスにバインドされたFIDO2キー、組み込みハードウェアモジュール内のキーストレージ、または外部トークンなど）をすべてサポートしているとは限らない。モバイルとデスクトッ プの両プラットフォームでエンタープライズが使用する高保証MFAの実装を、最大限のユーザーフレンドリ ーなフローでサポートするためのベンダーの追加投資は、あらゆる規模の組織によるMFAの採用を実質的 に支援するだろう。
These same ease of use challenges also apply to configuring systems such as SSO providers to consume MFA. An often-bewildering list of options is available to be combined in complicated ways to support diverse requirements. Vendors could offer a set of predefined default configurations, that are pre-validated end to end for defined use cases. For example, a flow designed around the use of PKI and FIDO2 for maximum security or a flow defined around the use of mobile push applications with number matching for supporting business to business use cases from unknown platforms where stronger forms of MFA are not currently possible. Diverse requirements do require the ability to tweak detailed configuration options but offering safe and secure default paths that are well validated end to end is also critical.	これらの同じ使いやすさの課題は、MFAを利用するためのSSOプロバイダなどのシステムを設定する場合にも当てはまる。多様な要求をサポートするために、複雑な方法で組み合わせられる、しばしば当惑させられるようなオプションのリストが利用可能である。ベンダーは、定義されたユースケースのためにエンドツーエンドで事前検証された、事前定義されたデフォルトコンフィギュレーションのセットを提供することができる。例えば、PKIとFIDO2の利用を中心に設計された最大限のセキュリティのためのフローや、より強力な形態のMFAが現時点では不可能な未知のプラットフォームからの企業間のユースケースをサポートするための番号照合を伴うモバイルプッシュアプリケーションの利用を中心に定義されたフローなどである。多様な要件には、詳細な設定オプションを微調整する能力が必要だが、エンドツーエンドで十分に検証された安全でセキュアなデフォルトパスを提供することも重要である。
MFA Sustainment and Governance Challenges	MFAの維持とガバナンスの課題
The final category of MFA related challenges addressed in this paper is governance and sustainment of MFA over time as employees join and leave the organization. All types of authentication credentials – including passwords – must be directly associated to user identities and their directory accounts. Robust management of this process, which is often called “credential lifecycle management”, is often lacking in available MFA solutions. PKI based MFA has a robust ecosystem of tools developed to register and issue PKI credentials, link them to accounts in a federated manner, and manage the revocation of credentials when they are either compromised or users are unenrolled, or both. However, many other types of MFA rely on user self-enrollment and some type of “one time enrollment code” flow which is itself a potential target of threat actors. Such flows often require the development of custom tools by organizations to align them with their business processes. The properties of these one-off flows vary widely and may be vulnerable to certain types of attacks that can compromise user credentials.	本稿で取り上げる MFA 関連の課題の最後のカテゴリーは、従業員の入退社に伴うガバナンスと MFA の維持である。パスワードを含むすべてのタイプの本人認証は、ユーザ・アイデンティティとそのディレク トリ・アカウントに直接関連付けられなければならない。しばしば「クレデンシャル・ライフサイクル管理」と呼ばれるこのプロセスの堅牢な管理は、利用可能な MFA ソリューションには欠けていることが多い。PKI ベースの MFA には、PKI クレデンシャルを登録および発行し、それらをフェデレートされた 方法でアカウントにリンクし、クレデンシャルが危殆化したとき、またはユーザが登録解除さ れたとき、あるいはその両方のときに、クレデンシャルの失効を管理するために開発されたツールの 堅牢なエコシステムがある。しかし、他の多くのタイプの MFA は、ユーザーの自己登録とある種の「ワンタイム・エンロールメント・コード」フローに依存しており、それ自体が脅威行為者の潜在的な標的 となっている。このようなフローは、多くの場合、組織のビジネスプロセスと整合させるために、組織によるカスタムツールの開発を必要とする。このような単発のフローの脆弱性は様々であり、ユーザー認証情報を侵害する特定のタイプの攻撃に脆弱である可能性がある。
There is room for the IAM vendor community to develop more secure enrollment tooling to support the more complex provisioning needs of large organizations. For example, organizations may need to be able to enroll a user with an authenticator on one network while allowing them access to systems on a separate network. Along similar lines, tools for automatically discovering and purging enrolled MFA authenticators that have not been used in a particular period, or whose usage deviates from the expected behavior of a user, could be enhanced. Many of the approaches that are currently used to analyze user behavior to determine sign-on and account-level risk could be enhanced to better support governance of MFA authenticators. This is important because strong governance over MFA authenticator lifecycle enables higher trust to be placed in the use of MFA when it is employed.	IAM ベンダーコミュニティには、大組織のより複雑なプロビジョニングニーズをサポートする、よりセキュアな登録ツールを開発する余地がある。例えば、組織は、あるネットワーク上の本人認証でユーザを登録する一方で、別のネットワーク上のシス テムへのアクセスを許可する必要があるかもしれない。同様に、特定の期間に使用されていない、または使用状況がユーザの期待される行動から逸脱 している、登録された MFA 認証を自動的に検出し、消去するツールも強化される可能性がある。サインオンおよびアカウントレベルのリスクを判断するためにユーザの行動を分析するた めに現在使用されている多くのアプローチは、MFA 認証子のガバナンスをより良くサポートするために 強化することができる。MFA 認証のライフサイクルに対する強力なガバナンスは、MFA が使用される際に、より高い 信頼を置くことを可能にするため、これは重要である。
For FIDO authenticators in particular, further enhancements are necessary to support attestation in the enterprise context. For example, the ability to determine that an authenticator was issued to a particular organization or person should be supported as a first-class capability in the market by IAM vendors. There is tension between FIDO’s privacy preservation properties and the desire of enterprises to track and manage authenticator registration. Enterprise attestation and registration of FIDO tokens to SSO providers can provide a way to navigate this tradeoff, but further refinement of the flows and support in the ecosystem is required to reach the necessary enterprise experience.	特に FIDO 認証子については、エンタープライズ・コンテキストにおける認証をサポートするため のさらなる機能強化が必要である。例えば、認証者が特定の組織または個人に発行されたことを判断する機能は、IAM ベンダーが市場で第一級の機能としてサポートする必要がある。FIDO のプライバシー保護特性と、認証者登録を追跡・管理したいというエンタープライズの願望との間には、緊張関係がある。エンタープライズ認証と SSO プロバイダへの FIDO トークンの登録は、このトレードオフを回避する方法を提供する。
SSO and Identity Federation	SSOとアイデンティティ・フェデレーション
Identity Federation and SSO are critical security capabilities. By SSO, we mean a situation where an identity provider (IdP) within an organization authenticates a user and then conveys proof of that authentication to a series of applications – called relying parties (RPs) – typically without requiring the user to re-authenticate for each application. SSO is built on top of identity federation protocols such as security assertion markup language (SAML) or Open ID Connect (OIDC) that specify how authentication may be conveyed from the IdP to the RPs. These capabilities are critical for security because they make more advanced authentication, such as multi-factor authentication, or contextual authentication policies[8],a problem to be solved once within an organization rather than handled differently for each application. However, to do this, they concentrate risk into the IdP as the source of trust for authentication to a swath of applications. This trade-off is typically worth it due to the previously mentioned benefits, but vendors developing SSO technologies need to design their systems to the highest of security standards given their critical role in securing the enterprise. There are numerous challenges we have identified that could be addressed by IAM vendors as well as the vendors of RP systems. The following types of challenges will be addressed below: complexity and usability challenges, standards improvement opportunities, and ecosystem challenges.	アイデンティティフェデレーションと SSO は、重要なセキュリティ機能である。SSO とは、組織内の ID プロバイダ（IdP）がユーザを認証し、その認証の身元確認を一連のアプリ ケーション（依拠当事者（RP）と呼ばれる）に伝達する状況を意味する。SSO は、セキュリティ主張マークアップ言語（SAML）やオープン ID コネクト（OIDC） などの ID フェデレーション・プロトコルの上に構築され、本人認証が IdP から RP に伝達される方法を指定する。これらの機能は、多要素認証やコンテキスト認証ポリシー[8]などのより高度な 認証を、アプリケーションごとに個別に処理するのではなく、組織内で一度解決すべき 問題にするため、セキュリティにとって重要である。しかし、これを実現するために、本人認証の信頼源としての IdP にリスクが集中する。このトレードオフは、先に述べたような利点があるため、通常はそれだけの価値があるが、SSO技術を開発するベンダーは、エンタープライズの安全確保における重要な役割を考慮し、最高のセキュリティ標準に従ってシステムを設計する必要がある。RPシステムのベンダと同様に、IAMベンダによって対処される可能性があ る、我々が特定した多くの課題がある。以下では、以下の種類の課題を取り上げる： 複雑性とユーザビリティの課題、標準改善の機会、エコシステムの課題である。
Complexity and Usability Challenges	複雑性とユーザビリティの課題
First, there is still a significant tradeoff between functionality and complexity.  Organizations can choose streamlined IdPs with simplified configurations that aren’t able to support all the use cases that they may face, or they may deploy sophisticated tooling that requires significant numbers of highly skilled personnel to operate in a secure way. For many organizations, this is a difficult tradeoff that results in the deployment of SSO technology that is impossible to securely manage, undermining the security benefits of SSO. For example, it is critical to maintain the security of the key material used in identity federation protocols. Doing so may require the deployment of dedicated hardware security modules (HSM) and robust operational practices as well as significant amounts of skilled personnel to successfully integrate and sustain such systems. Choosing instead to store keys less securely (i.e. on disk) opens the door to adversaries compromising the keys and thus gaining access to systems across the enterprise. The growth of cloud-based identity tools delivered as software-as-a-service (SaaS) has eased the burden of deploying SSO significantly for organizations of various sizes, but such tools are not available to all market segments (e.g., operational technology (OT)) or OT networks in critical infrastructure. There is room for the development of a secure-by-default, easy to use, SSO system to address these gaps in the market. RP vendors could provide security configuration recommendations and their impacts. For example, the management of lifetime tokens such as ID tokens, Access Tokens, and Refresh Tokens should come with a reasonable secure default value which prevents wider abuse scenarios. It would allow the business to reduce the risk while providing a seamless user experience to restricted resources.	第一に、機能と複雑さの間には依然として大きなトレードオフがある。 組織は、直面する可能性のあるすべてのユースケースをサポートできない簡素化された構成の合理的なIdPを選択することもできるし、安全な方法で運用するために相当数の高度なスキルを持つ人材を必要とする洗練されたツールを導入することもできる。多くの組織にとって、これは難しいトレードオフであり、その結果、セキュア に管理することが不可能なSSOテクノロジーを展開することになり、SSO のセキュリティ上の利点を損なうことになる。たとえば、ID フェデレーション・プロトコルで使用されるキーマテリアルのセキュリティを 維持することは非常に重要である。そのためには、専用のハードウェア・セ キュリティ・モジュール（HSM）の配備と堅牢な運用慣行、さらにそのようなシステ ムをうまく統合し維持するための大量の熟練要員が必要になるかもしれない。その代わりに、あまり安全でない（つまりディスク上の）鍵の保管を選択すると、敵が鍵を危殆化し、エ ンタープライズ全体のシステムにアクセスできるようになる可能性がある。SaaS（Software-as-a-Service）として提供されるクラウドベースのIDツールの 成長により、さまざまな規模の組織でSSOを展開する負担が大幅に軽減されたが、そのよう なツールは、すべての市場セグメント（たとえば、運用技術（OT））や重要インフラの OTネットワークで利用できるわけではない。このような市場のギャップに対処するために、セキュアバイデフォルトの、 使いやすいSSOシステムを開発する余地がある。RPベンダーは、セキュリティ設定の推奨とその影響を提供できるだろう。たとえば、IDトークン、アクセストークン、リフレッシュトークンのようなライフタイ ムトークンの管理には、より広範な悪用シナリオを防ぐ合理的でセキュアなデフォルト 値が付属すべきである。これによって企業は、制限されたリソースへのシームレスなユーザー体験を提供しながら、リスクを低減することができる。
Second, tooling for understanding trust relationships and the impact to changes in the configuration could be improved.  Changes to identity configurations often have organization-wide impact and thus need to be carefully controlled and managed. For example, a known threat vector for exploiting identity federation leverages compromising an on-premises IdP and pivoting to administrative accounts in the cloud that trust the onpremises IdP. Such identity federations are often set up unintentionally and could be automatically detected by IAM vendors by correlating data between the RP and the IdP. Similarly, identity federation protocols, such as SAML, support a variety of different configuration profiles. Some uses of SAML are known to be less secure than others. IAM vendors could aid in the detection of insecure implementations of these protocols and work with the ecosystem to build awareness around these issues as well as improve the adoption of the more secure uses of the standards.	第 2 に、信頼関係と構成の変更に対する影響を理解するためのツールを改善することができる。 ID 構成の変更は組織全体に影響を及ぼすことが多いため、注意深く制御および管 理する必要がある。たとえば、ID フェデレーションを悪用する既知の脅威ベクトルは、オンプレミスの IdP を侵害し、オンプレミスの IdP を信頼するクラウドの管理アカウントにピボットすることを利用している。このような ID フェデレーションは意図せずに設定されることが多く、RP と IdP 間のデータを相関させることで IAM ベンダーが自動的に検知できる可能性がある。同様に、SAML などの ID フェデレーション・プロトコルは、さまざまな異なる構成プロファイルを サポートしている。SAML の一部の用途は、他の用途よりも安全でないことが知られている。IAM ベンダーは、これらのプロトコルの安全でない実装の検知を支援し、エコシステムと協 力してこれらの問題に対する認識を構築し、標準のより安全な用途の採用を改善することができる。
Finally, there is the issue of ensuring SSO can enable secure MFA across all use cases, including privileged access use cases. As discussed above, the best path to MFA is through support in an SSO platform. Most SSO platforms in use today, both on-premises and in the cloud, support a variety of MFA options. However, there are often accounts that are not federated through SSO. For example, this is frequently true of high-level admin accounts as these accounts need to configure the setup of SSO itself in relying parties. Such accounts are attractive targets for threat actors and need to be protected with MFA. Some RPs support the ability to configure the privileged roles for these high-level admins so that they trust separate, dedicated IdPs for “privileged access management” (PAM), however this capability is not particularly widespread in RPs. Other RPs natively support some level of MFA for administrative users, but the types of MFA options available varies and is rarely as complete as a dedicated SSO platform.	最後に、SSOが特権アクセスのユースケースを含むすべてのユースケースにわたってセキュアなMFAを実現できるようにするという問題がある。上述したように、MFAへの最良の道は、SSOプラットフォームでのサポ ートである。今日使われているほとんどのSSOプラットフォームは、オンプレミスでもクラウドでも、様々なMFAオプションをサポートしている。しかし、SSOを通じて連携されないアカウントがしばしば存在する。例えば、これは高レベルの管理者アカウントによく当てはまり、これらのアカウントはSSOのセットアップそのものを依存者に設定する必要があるからだ。このようなアカウントは脅威行為者にとって魅力的な防御対象であり、MFAで保護する必要がある。一部のRPは、「特権アクセス管理」(PAM)のために別の専用IdPを信頼するように、高レ ベル管理者の特権ロールを設定する機能をサポートしているが、この機能はRPでは特 に普及していない。他のRPは、管理ユーザーのためにある程度のMFAをネイティブにサポートしているが、利用可能なMFAオプションのタイプは様々であり、専用のSSOプラットフォームほど完全であることはまれである。
In the cloud context, key software as a service (SaaS) vendors should either organically support a spectrum of MFA options, including phishing resistant MFA options, for their administrative roles or should provide the ability to segregate trust (e.g. a separate federation configuration) for administrative roles. Furthermore, for any break glass accounts that are required to configure such trusts or not protected by MFA, RPs should ensure that these accounts can be protected with best practices, such as being vaulted and configured to alert on all usage.	クラウドの文脈では、SaaS（Software as a Service）ベンダーは、管理ロールのためにフィッシングに強いMFAオプションを含む様々なMFAオプションを有機的にサポートするか、管理ロールのためにトラストサービスを分離する機能（個別のフェデレーション・コンフィギュレーションなど）を提供する必要がある。さらに、このようなトラストを設定する必要がある、あるいは MFA で保護されていないブ レークグラス・アカウントについては、RP は、これらのアカウントが保管庫に保管され、すべての 使用について警告を発するように設定されるなど、ベストプラクティスで保護できることを保証す べきである。
Today, a commonly used pattern is to employ PAM tooling that effectively functions as a password vault (often with one-time use passwords) and a session monitoring tool. Users authenticate to such a tool via SSO and the tool mediates administrative access to platforms. Such solutions ultimately frequently rely on secrets shared between the PAM tools and the RP system, including long-lived secrets used to reset the passwords of administrative accounts. There is an opportunity for more robust privileged authentication flows that leverage modern federation protocols in a way avoids the need to maintain peruser passwords for administrative users. Wider support in the industry for such approaches would reduce the risk of privileged account compromise.	今日、一般的に使用されているパターンは、パスワード保管庫（多くの場合、ワンタイムパスワードを使用）およびセッション監視ツールとして効果的に機能する PAM ツールを採用することである。ユーザーはSSO経由でそのようなツールに認証され、ツールはプラットフォームへの管理アクセスを仲介する。このようなソリューションは、最終的に、管理アカウントのパスワードをリセットするために使用される長期間のシークレットを含め、PAMツールとRPシステム間で共有されるシークレットに依存することが多い。最新のフェデレーション・プロトコルを活用することで、管理者ユーザの本人パスワー ドを保持する必要性を回避する、より堅牢な特権認証フローを実現する機会がある。このようなアプローチが業界で広くサポートされるようになれば、特権アカウントの漏洩リスクは低減される。
Standards Improvement Opportunities	標準改善の機会
Open standards are a critical part of the identity ecosystem, however, there is room for improvement. This paper focuses on several identity standards topics, but it is not meant to be a comprehensive list of such issues.	オープン標準は ID エコシステムの重要な部分であるが、改善の余地もある。本稿ではいくつかの ID 標準のトピックに焦点を当てるが、そのような問題の包括的なリストではな い。
One example is that there is not yet a universally adopted standard for communicating the strength of MFA between IdPs and RPs. Current standards such as RFC 8176[9] do not cover all use cases and are not adopted by all vendors. Competing standards based on NIST SP 800-63 are also in use, as are proprietary implementations of these concepts.  Standardization of these MFA types would aid in driving adoption of MFA in enterprise environments, especially in complicated use cases requiring different types of MFA strength for different user populations. Improvements in the terminology and understanding of the security properties of MFA, as discussed in the previous section, would aid in providing a basis for this type of standard.	一例として、IdP と RP 間で MFA の強度をコミュニケーションするための普遍的に採用され ている標準がまだ存在しないことが挙げられる。RFC 8176[9]のような現在の標準は、すべてのユースケースをカバーしているわけではなく、すべてのベンダが採用しているわけでもない。NIST SP 800-63 に基づく競合標準も使用されており、これらの概念の独自実装もある。 これらの MFA タイプの標準化は、エンタープライズ環境における MFA の採用を促進する一助となるであろう。特に、ユーザ集団ごとに異なるタイプの MFA 強度を必要とする複雑なユースケースにおいてはそうである。前のセクションで議論したように、MFA のセキュリティ特性の用語と理解の改善は、この種の標準の基礎を提供するのに役立つだろう。
A second topic is around the standardization of federation configurations themselves. The OpenID foundations Fast Federation (FastFed) standard specifies an approach to exchanging metadata required by identity federation protocols. Such standards are critical for simplifying and scaling the adoption of SSO technologies and should be supported broadly in the ecosystem. Their continued development and adoption is important to lower the burden to integrating SSO with applications and systems, thus enabling enhanced authentication.	第二のトピックは、フェデレーション構成自体の標準化である。OpenID 基礎の Fast Federation（FastFed）標準は、ID フェデレーション・プロトコルが必要とするメタデータを交換するためのアプローチを規定している。このような標準は、SSO テクノロジーの採用を簡素化し拡大するために不可欠であり、エコシステムで広くサポートされるべきである。それらの継続的な開発と採用は、SSO をアプリケーショ ンとシステムに統合する負担を軽減し、本人認証の強化を可能にするために重要である。
Another issue around standards concerns the strength of identity federation assertions themselves. Many identity federation protocols use bearer assertions that are vulnerable to theft and replay. The validity of bearer assertions, which can be significant, can increase this risk. It is important that IAM vendors and RPs carefully consider issues such as assertion lifetime, assertion reuse, and assertion scope (e.g. issuer and audience) and provide tools for system owners to easily manage this risk. Furthermore, the use of identity federation protocols such as OAuth2 that leverage direct network “back channel” between the RP and the IdP rather than simply passing data through the user’s browser (the “front channel”) provides some security benefit by avoiding the exposure of a long-term credential to the user’s browser. Broader support of back-channel federation protocols would thus enhance security. Similarly, efforts such as the IETF OAuth2 DPoP token binding work are important to reduce the risks associated with bearer tokens that can be stolen and be reused. Broad industry support for these efforts is important.	標準をめぐるもう 1 つの問題は、ID フェデレーション主張自体の強度に関係する。多くの ID フェデレーション・プロトコルは、盗用やリプレイに脆弱なベアラ・ アサーションを使用している。ベアラ・アサーションの妥当性は重要である可能性があり、このリスクを増大させる。IAM ベンダおよび RP は、アサーションの有効期間、アサーションの再利用、およびアサーション の範囲（発行者および利用者など）などの問題を慎重に検討し、システム所有者がこのリスクを 容易に管理できるツールを提供することが重要である。さらに、単にユーザのブラウザ（「フロント・チャネル」）を介してデータを渡すのではなく、RP と IdP 間の直接ネットワーク「バック・チャネル」を活用する OAuth2 などの ID フェデレーション・プロトコルの使用は、ユーザのブラウザへの長期的なクレデンシャルのエクスポージャを回避す ることによって、ある程度のセキュリティ上の利点を提供する。したがって、バックチャネルのフェデレーション・プロトコルをより広範にサポートすることで、セキュ リティが強化される。同様に、IETF OAuth2 DPoP トークン・バインディング作業のような取り組みは、盗まれて再 利用される可能性のあるベアラ・トークンに関連するリスクを低減するために重要である。これらの取り組みに対する業界の幅広いサポートが重要である。
Finally, there are early-stage standards activities around sharing of within-session risk. These protocols (RISC and CAEP) enable identity providers and relying parties to exchange signaling around risk of particular sessions. Broad support for and development of these standards in the enterprise ecosystem will enable a variety of security use cases, ranging from limiting access to managed devices to quickly revoking access when accounts are compromised.	最後に、セッション内リスクの共有に関する初期段階の標準化活動がある。これらのプロトコル（RISC および CAEP）により、ID プロバイダと依拠当事者は特定のセッ ションのリスクに関するシグナリングを交換することができる。エンタープライズのエコシステムにおけるこれらの標準の広範なサポートと開発により、 管理対象デバイスへのアクセスの制限から、アカウントが侵害された場合の迅速なアクセス の取り消しまで、さまざまなセキュリティ使用事例が可能になる。
Ecosystem Challenges	エコシステムの課題
Beyond complexity and standards, integration of SSO into the enterprise is still often difficult for a variety of reasons. For one, architectures designed for leveraging open standard based SSO together with legacy applications are not always widely understood. For example, in some organizations it is still difficult to integrate applications with an organizational IdP due to lack of talent or knowledge of architectural options (e.g. proxy, application server module, managed proxy service, etc.). Many organizations have developed robust practices for solving these challenges, but their work is not widely known outside of that organization. Community development by the IAM vendor ecosystem of a shared, open-source repository of open standards-based modules and patterns to solve these integration challenges would aid in adoption. Some vendors have created such repositories, but they are typically not widely embraced by multiple vendors and sometimes leverage proprietary integration points rather than open standards.	複雑さと標準を越えて、エンタープライズへのSSOの統合は、様々な理由でまだしばしば困難である。ひとつには、レガシー・アプリケーションとともにオープン標準ベースのSSOを活用するために設計されたアーキテクチャは、必ずしも広く理解されていない。たとえば、いくつかの組織では、アーキテクチャのオプション(たとえば、 プロキシ、アプリケーションサーバモジュール、マネージドプロキシサービ スなど)に関する才能や知識の不足のために、アプリケーションを組織の IdP と統合することはまだ難しい。多くの組織が、これらの課題を解決するための強固なプラクティスを開発しているが、その成果は組織の外には広く知られていない。IAMベンダーのエコシステムによる、これらの統合の課題を解決するためのオープン標準ベースのモジュー ルとパターンの共有オープンソースリポジトリのコミュニティ開発は、採用の助けになるだろう。そのようなリポジトリを作成したベンダーもあるが、一般的に複数のベンダーに広く受け入れられているわけではなく、オープン標準ではなく独自の統合ポイントを活用している場合もある。
In addition to these capability gaps, there are several business practices in the market that merit attention. In numerous RP applications, SSO capabilities are bundled with other high end “enterprise” features in such a way to make them inaccessible to small and medium organizations. This business practice deprives these organizations of the security benefits of MFA and other critical capabilities that come from adoption of SSO and is based on a flawed assumption that SSO is an “enterprise” feature. In today’s market, SSO is a table stakes feature for organizations of all sizes and should be included in any pricing plans that are targeted at business customers, regardless of size. Along a similar vein, when SSO is supported, SAML is often the only supported protocol option. SAML has a number of security pitfalls and complexities that require careful configuration to avoid. For similar reasons, it is prone to implementation mistakes in RP applications. As discussed in the standards opportunities section, RP vendors should add support for OAuth2 and OIDC as an alternative federation protocol. OIDC was designed to fix several of the technical problems with SAML and broader support would aid in reducing security issues related to SAML misconfiguration or improper implementation.	このような能力格差に加えて、市場には注目に値するビジネス慣行がいくつかある。数多くのRPアプリケーションにおいて、SSO機能は、中小組織にとっ てアクセスしにくいように、他のハイエンドの "エンタープライズ "機能とバ ンドルされている。このビジネスプラクティスは、これらの組織からMFAのセキュリ ティ上の利点とSSOの採用から生まれる他の重要な機能を奪う。今日の市場では、SSOはすべての規模の組織のためのテーブルステークス 機能であり、規模に関係なく、ビジネス顧客をターゲットにしたすべての 価格プランに含まれるべきである。同じような流れで、SSOがサポートされているとき、SAMLは多くの場合、 サポートされている唯一のプロトコルオプションである。SAMLには多くのセキュリティ上の落とし穴と複雑さがあり、それを避けるには慎重な設定が必要である。同様の理由で、SAMLはRPアプリケーションで実装ミスを犯しやすい。標準の機会のセクションで説明したように、RPベンダーはOAuth2とOIDCのサポートを、代替のフェデレーション・プロトコルとして追加すべきである。OIDC は、SAML の技術的問題のいくつかを修正するために設計されたものであり、より広範なサ ポートは、SAML の誤設定または不適切な実装に関連するセキュリティ問題の軽減に役立つ。
Additionally, identity lifecycle management through open standards (e.g. SCIM) is still not viewed as a core part of the development of business software. Identity vendors often write custom integrations against proprietary APIs to manage the lifecycle of identities in RP systems, if such management is possible at all. Lifecycle management is a critical security capability. For example, it helps to implement the idea of least privilege and aids in detection of unexpected activity such as the creation of an account in a relying system that is not associated with a validated identity of the organization. SCIM and related standards should be adopted as table stakes by the RP ecosystem (both SaaS and on-premises software).	さらに、オープン標準（SCIM など）を介した ID ライフサイクル管理は、まだビジネスソフ トウェア開発の中核部分と見なされていない。ID ベンダーは、RP システムで ID のライフサイクルを管理するために、独自の API に対してカスタム統合を作成することが多い。ライフサイクル管理は重要なセキュリティ機能である。たとえば、最小特権の考え方の実装を支援し、組織の検証された ID に関連付け られていないアカウントを依存システムで作成するような予期しない活動の検知を支援する。SCIMと関連標準は、RPエコシステム（SaaSとオンプレミス・ソフトウェアの両方）によって、テーブルステークスとして採用されるべきである。
Conclusions	結論
The challenges in the employment of MFA and SSO technologies in enterprise environments require further work by IAM vendors and further development of RP applications. These challenges span the spectrum from developing new product offerings to broadly adopting key ongoing standards activities. MFA and SSO are both critical security technologies that need to be adopted securely to address key threats all enterprises face, but doing so in a secure manner today is more difficult than in the past. Through public-private partnership, this situation can be improved, and the security of all organizations further enhanced.	エンタープライズ環境における MFA および SSO 技術の採用における課題は、IAM ベンダーによるさらなる作業と RP アプリケーションのさらなる開発を必要とする。これらの課題は、新製品の開発から、現在進行中の主要な標準化活動の広範な採用にまで及ぶ。MFAとSSOはどちらも重要なセキュリティ技術であり、すべてのエンタープライズが直面する主要な脅威に対処するために安全に採用される必要があるが、今日、安全な方法でそれを行うことは過去よりも困難になっている。官民のパートナーシップを通じて、この状況を改善し、すべての組織のセキュリ ティをさらに強化することができる。
Appendix I: Key Recommendations for Vendors	附属書 I： ベンダーへの主な提言
Key Challenge: Ambiguous MFA terminology	主な課題：曖昧なMFA用語
•       Create standard MFA terminology that provides clear, interoperable, and standardized definitions and policies allowing organizations to make value comparisons and to integrate these solutions into their environment.	・明確で,相互運用可能で,標準化された定義とポリシーを提供する標準的な MFA 用語を作成し,組織が価値を比較し,これらのソリューションを環境に統合できるようにする。
•       Map products to NIST requirements such as those articulated in NIST SP 800-63[10].	・NIST SP 80063[10]に明示されているような NIST の要件に製品を対応させる。
Key Challenge: Lack of clarity on security properties that certain MFA implementations provide.	主な課題：特定の MFA 実装が提供するセキュリティ特性が明確でない。
•       Additional investment by the vendor community in bringing more phishingresistant authenticators to more use cases to provide greater defense against sophisticated attacks. Further, simplify and standardize their adoption, including in the form factors embedded into operating systems would greatly enhance the market.	・よりフィッシングに強い本人認証をより多くのユースケースに導入し,高度な攻撃に対する防御を強化するために,ベンダ ーコミュニティによる追加投資が必要である。さらに,オペレーティングシステムに組み込まれるフォームファクタを含め,MFA の採用を簡素化し,標準化することで,市場を大きく拡大することができる。
•       Additional vendor investment in supporting high assurance MFA implementations for enterprise use on both mobile and desktop platforms in a maximally user-friendly flow to promote higher MFA adoption across all sizes.	・あらゆる規模の MFA の普及を促進するために,モバイルとデスクトップの両プラット フォームでエンタープライズが使用する高保証 MFA の実装を,最大限のユーザフレンドリ なフローでサポートするための追加投資をベンダーが行うこと。
Key Challenge: MFA reliance on self-enrollment by the user and “one time enrollment code flow” exposes itself as a potential threat actor.	主な課題：ユーザーによる自己登録と「ワンタイム・エンロールメント・コード・フロー」に依存するMFAは、潜在的な脅威行為者であることを露呈している。
•       Develop more secure enrollment tooling to support the complex provisioning needs of large organizations.	・大規模組織の複雑なプロビジョニング・ニーズをサポートするため,より安全な登録ツールを開発する。
•       Develop tools for automatically discovering and purging enrollment MFA authenticators that have not been used in a particular period of time or whose usage deviates from the expected behavior of a user could be enhanced.	・特定の期間に使用されていない登録 MFA 本人認証や,ユーザの期待される行動から逸脱した使用方法を自動的に検出してパージするツールを開発する。
Key Challenge: The significant tradeoff between SSO functionality and complexity.	主要課題：SSO 機能と複雑性の間の大きなトレードオフ。
•               Research into the development of a secure-by-default, easy to use, SSO system to address these gaps in the market. For example: Relying Party vendors could provide security configuration recommendations and their impact. Additionally, management of lifetime tokens such as ID token, Access Token, and Refresh Token should come with a reasonable secure default value which preventing abuse scenarios.	・このような市場のギャップに対処するために,セキュア・バイ・デフォルトで使いやすい SSO システムの開発に関する研究を行う。例えば 依拠当事者ベンダーは,推奨されるセキュリティ構成とその影響を提供することができる。さらに,IDトークン,アクセストークン,リフレッシュトークンのようなライフタイム トークンの管理は,悪用シナリオを防ぐ合理的でセキュアなデフォルト値を伴うべきである。
•       IAM Vendors can aid in the detection of insecure implementations of identity federation protocols and work with the ecosystem to build awareness around these issues as well as improve the adoption of more secure uses of standards.	・IAM ベンダーは,ID フェデレーション・プロトコルの安全でない実装の検知を支援し,エコシステムと協 力してこれらの問題に対する認識を高めるとともに,標準のより安全な利用の採用を改善することができる。
Key Challenge: Need to improve the currently deployed open standards throughout the identity ecosystem.	主な課題：ID エコシステム全体で現在展開されているオープン標準を改善する必要がある。
•       Implement broader support for and development of identity standards in the enterprise ecosystem. This will enable a variety of security use cases, ranging from limiting access to managed devices to quickly revoking access when accounts are compromised.	・エンタープライズのエコシステムにおいて,ID 標準の広範なサポートと開発を実施する。これにより,管理対象デバイスへのアクセス制限から,アカウントが侵害された場合の迅速なアクセ ス取り消しまで,さまざまなセキュリティ使用事例が可能になる。
Key Challenge: Architectures for leveraging open standard based SSO together with legacy applications are not always widely understood.	主な課題 オープン標準ベースのSSOをレガシー・アプリケーションとともに活用するためのアーキテクチャは、必ずしも広く理解されていない。
•       Create a shared, open-source repository of open standards-based modules and patterns to solve these integration challenges to aid in adoption.	・これらの統合の課題を解決するために,オープン標準ベースのモジュールとパターンの共有されたオープンソースリポジトリを作成し,採用を支援する。
Key Challenge: SSO capabilities are bundled with other high end enterprise features in such a way that makes the inaccessible to small and medium organizations.	主な課題: SSO機能は、中小組織にはアクセスできないような方法で、他のハイエ ンドのエンタープライズ機能とバンドルされている。
•       Include organizational SSOs in any pricing plan that are targeted at business customers, regardless of size.	・規模に関係なく,ビジネス顧客をターゲットにしたあらゆる価格プランに,組織のSSOを含める。