大規模な組織内でIDプロバイダーの代わりに専用のユーザー/パスワードを使用する客観的な理由はありますか？
私は大規模な組織（何千人もの従業員+内部情報の一部に部分的にアクセスできる数万人の外部ユーザー）で働いており、これらの人々の多くはユーザー名/パスワード（定期的に有効期限が切れます）を使用して認証します。
ただし、これらの人々のほとんど（従業員は、Windows、Linux、またはiOSで一般的に働いているかどうかに関係なく確実です）にActive Directoryアカウント（内部電子メールアドレス）が提供され、すべてのシステムでAFAIKを使用してサインインできます [〜＃〜] adfs [〜＃〜] /Active Directory/LDAP IDプロバイダー。
ADFSが許可されていない場合は、アクセスが非常に制限されている外部ユーザー（一部のレポートなど）でも、主要なIDプロバイダー（たとえば Google Identity provider ）を使用してソリューションを実装できます。
ユーザー名/パスワードを持つことはユーザーに負担をかけ、多くはセキュリティ上のリスクをもたらすそれらを保存するためにExcelファイルと電子メールを使用しています。また、ユーザー共有について聞いたことがありますので、実際に誰が特定のユーザーを利用したかはわかりません。
したがって、Windows資格情報とおそらく他のIDプロバイダーのみを排他的に使用することにより、ユーザーはすべての会社のシステムを扱うときに資格情報の1つのペアのみを処理する必要があります。また、資格情報の共有が消えます。
質問：大規模な組織内でIDプロバイダーの代わりに専用のユーザー/パスワードを使用する客観的な理由はありますか？
ほとんどの組織にとって、包括的な統一IDシステムは前向きなものです。これを行わない理由があるかどうか尋ねました。さまざまな組織で有効な場合とそうでない場合があるいくつかを挙げます。
システムはIDプロバイダーをサポートしていません。 ADへのリンクが容易ではないレガシーのターミナルベースのメインフレームシステムを使用している可能性があります。レガシー製品をIDシステムにリンクする多くの商用製品がありますが、これらは高価になる可能性があります。あるいは、統合に苦労しているクラウドベースのシステム（Salesforceなど）があるかもしれません。
システムは機密性が高く、IDシステムの違反が発生した場合にシステムを公開したくありません。これは少数の非常に機密性の高いシステムに有効ですが、この引数はエンタープライズ環境では過剰に使用されます。 IDプロバイダーがADの場合、ADの違反は、人々がこれらのシステムを管理するために使用するすべてのワークステーションの違反を意味する可能性が高いため、分離はセキュリティシアターにすぎません。
IDプロバイダーにシステムからアクセスできません。一般的な例は、DMZ内のインターネット接続システムで、ファイアウォールによって内部ADにアクセスできないようにブロックされています。私は、DMZシステム。同様の問題が開発システムと本番システムで発生する可能性があります。
一部のユーザーは、IDプロバイダーの一部ではありません。古典的な例は、内部システムにアクセスする数人の外部ユーザーがいる場合です。システムに複数の認証方法をサポートさせるか、適切な制限付きで外部ユーザーがIDプロバイダーに所属できるようにすることで、これに対処できます。
システムとIDプロバイダーを統合することの難しさがメリットに見合うかどうかは、バランスを取ることです。ほとんどのIT管理者は、大量の資格情報の管理が仕事の一部であることを受け入れています。
まず、Active Directoryは独自仕様のプロトコルであり、Windowsの世界以外では最も簡単に使用できるとは限りません。そのため、少なくとも2つの認証があり、1つはWindowsの世界用、もう1つは他のシステム（通常はUnix/Linux）用です。これは、認証プロバイダーの1つが他の1つで同期されている場合、ユーザーに対してほぼ透過的にすることができます。
これは通常、認証のニーズのほとんどを解決できます。まだ残っている可能性があるのは：
- 独自のプライベート認証システムを持つことを主張する独自のソフトウェア。それは私たちが望むよりもさらに一般的です...
- 低レベルのシステムアカウント（例：Unixシステムではroot、データベースではdbaアカウント）。 normalユーザーアカウントに特権またはSudoを介してそれらを取得する機能を与えることができますが、問題が発生したとき。しかし、それは標準的なユーザーにとっては問題ではありません。
- 開発アカウント。開発フェーズでは、アプリケーションがメイン認証プロバイダーにプラグインされていない可能性があります。したがって、開発者とテスターは専用アカウントを使用する必要があります。
これはacceptableユースケース用です。しかし、さらに別のカテゴリがあります。SSOシステムの決済には、時間とお金の面でコストがかかります。一部の組織は、価値がないと考えているため、または場合によっては利益の可能性を認識していないため、そこに行かないことを選択する場合があります。後者のユースケースでのみ、非常に興味深いと直接マネージャーに提案できますが、時間を節約したりエラーを防止したりするrealのユースケースを見つける必要があります。 誰もがそれを行うは、大きなボスを説得するには十分ではないかもしれません...
Active Directoryは安全ではありません（デフォルト）
ADFSはADに依存しているため、適切にセキュリティを確保するために多少の労力が必要です。
Active Directoryをまったく使用している場合、特に重要なシステムへのアクセスを制御している場合は、深刻なセキュリティの欠陥に対処するように環境を設計する必要があります。
少なくとも、 階層化された管理モデル に従ってMicrosoftの レッドフォレスト設計 を実装して、パスザハッシュを軽減する必要があります（PtH）、パスザチケット（PtT）、およびゴールデンチケット攻撃。
フェデレーションは未来
外部ユーザーを扱う場合、ADFSは、ドメインにアカウントを作成したり、AD信頼を確立したりするよりもはるかに優れています。 ADFSを使用できる場合は、絶対に使用してください。
特にGoogle Identityについて言及しているため、これらはOAUTHに基づいており、 OAUTHはADFS と相互運用する必要があります。
ADFSは単にMicrosoftによるSAML IDプロバイダーの実装であるため、時間の経過とともにADFSはより有用になるはずです。企業用語では、SAMLはまだかなり新しいものですが、成長しています。
引き続き複数のアカウントが必要
管理ユーザーは引き続き複数のアカウントを必要とします。その必要性を合理的に排除することはできません。インターネットにアクセスできるアカウントには、インフラストラクチャを管理したり、開発/テスト環境を変更したりするための特権アクセスがあってはなりません。
管理者が2〜3個の個別のADアカウントを持っている必要がある場合でも、引き続き統合できる場合があります。たとえば、OracleとMS SQLの両方がWindows資格情報による認証をサポートしているため、DBAと開発者は各インスタンスで一意のユーザー/パスアカウントを必要としません。
以前は多くの良い答え/コメントがあるので、短くしておくようにしています：
私にとって、さまざまな資格情報でさまざまなユーザーアカウントを使用する主な理由は、パスワード（LDAPなど）、共有シークレット（Kerberos、TOTPなど）、非対称署名スキーム（例：SSHキー）。
パスワードの簡単な例：
ユーザーが自分の携帯電話に保存した同じパスワードを受け入れて、すべての顧客データを含むロックダウンされたバックエンドデータベースサーバーへの管理アクセスを許可する電子メールを読む必要はありません。
別のSSHキーの別の例：
SSHシステムのサブセットでは、SSHキーエージェント転送の使用を余儀なくされたり、さらに悪いことに、個人の秘密キーをジャンプホストにコピーしたりする必要があります。したがって、この同じ秘密鍵を、セキュリティ要件が異なる他のシステムの承認済み鍵として使用することは望ましくありません。
はい、Excelファイルなどで個別のアカウントを維持することは悪夢であり、ほとんどのIAMシステムとプロセスが1人あたり複数のアカウントをうまく処理できないことを示しています。この問題は、まともなIAMシステムを選択することで解決できます。
（システムごとに異なる認証スキームの組み合わせが必要になる場合もありますが、それだけでも悪夢です。）
CAS、SAML、OpenID（Connect）などのあらゆる種類のシングルサインオンメカニズムについて：
中央のログインサービスよりも安全でない可能性のあるシステムを長期間の認証情報が通過しないため、可能であればこれらを使用することは立派な目標だと思います。今日では、Webアプリケーションの統合はかなり簡単です。それらが複数のIDセッションを処理できるかどうか、または異なるSSOインスタンスをセットアップできるかどうかを確認する必要があります。
しかし、例えばSSHログインまたは802.1xでのネットワークアクセス制御の場合、現在、簡単に使用できるSSOまたは2FAソリューションはありません。これらのユースケースの場合、短期証明書（OpenSSH証明書またはX.509証明書）を発行することは、実行可能なソリューションになる可能性があります。
TLDR：どちらか一方の罠に陥らないでください。まともなIAMシステムを使用し、対処する必要があるシステムやアプリケーションに適切な認証フロントエンドを提供します。
私が提起する1つの問題は、ID管理システムのリアルタイムの攻撃にアクセスできないことです。たとえば、誰かがID管理サーバーを攻撃して侵入に成功した場合、気がついたらすぐに行動を起こすことができます。第三者のアイデンティティプロバイダーを侵害しているユーザーの場合、違反を開示することを決定したのはいつか、または数か月間わからない可能性があります。
まず第一に、私はいくつかのシステムがそのような「シングルサインオン」システムを持つことさえ望まないかもしれません。コメントで、データベースやその他のシステムについて言及しました。技術者として、サーバーに接続するための個別のSSHキー（パスワード保護）、データベースにアクセスするためのパスワードなどを好みます。そのため、集中IDプロバイダーのソリューションはすべてのニーズに適しているわけではありません。特に、このアプローチでは、認証のために到達可能でなければならない別のシステム（IDプロバイダー）が追加されることを考慮してください。これはほとんどの場合に当てはまる可能性が高いですが、それでも、覚えておかなければならない要件です。
さらに、システムはIDプロバイダーと連携できる必要があります。一般に、データベースへのアクセスは、ユーザー名/パスワードの代わりにそのようなIDプロバイダーを使用して承認できるとは思えません。 IDプロバイダーを使用するようにすべてのシステムを移行すると、予想外の問題が発生する可能性があります（もちろん、そうなるでしょう）。ユーザー名/パスワードの方が実装が簡単なので、時間とお金をかけて変更する必要はないでしょう。
資格情報を書き込むユーザーが解決しようとしている問題であると想定して、パスワードマネージャーの使用を大幅に促進します（デフォルトのOSイメージで出荷される可能性がありますか？）1つのパスワード allとユーザーはすべてのサービスのパスワードを解読するのは難しいまま維持できます。一部のユーザーはキーボードの下にあるテープにそれらを書き続けるでしょうが、それは普通のことです（残念ながら）。
明確にするために、私は一元化されたIDプロバイダーのアイデアが好きです。それらはすべてそれに反対する点です、私は今考えることができます。追加は歓迎します（興味深い質問です）。