Microsoft Entra ID でのシングル サインオンとは

シングル サインオン (SSO) を使用すると、ユーザーは 1 回サインインし、多くのアプリケーションにアクセスできます。 この記事では、SSO とは何か、ISV と組織に役立つ理由、Microsoft Entra IDの SSO オプション、サインイン プロセスのしくみについて説明します。

SSO を使用すると、ユーザーは 1 セットの資格情報でサインインします。 その後、割り当てられたすべてのアプリケーションを再度サインインせずに開くことができます。

SSO は 2 人の対象ユーザーにとって重要です。 独立系ソフトウェア ベンダー (ISV) は 、エンタープライズ顧客向けのアプリケーションを構築します。 組織は 、ユーザーのアプリケーション アクセスを管理します。 アプリをMicrosoft Entra IDと統合する開発者、または SSO ロールアウトを計画している管理者である可能性があります。 どちらのロールでも、SSO の基本は、セキュリティとユーザー エクスペリエンスの向上に役立ちます。

Microsoft Entra IDが ID プロバイダーの場合、ユーザーは職場の資格情報を使用して 1 回サインインします。 Microsoft Entra IDは、各ユーザーを検証し、アプリに対する ID を確認します。 アプリで個別のユーザー名とパスワードが管理されなくなりました。

シングル サインオンを使用する理由

SSO には、ISV とアプリを使用および管理するユーザーという 2 つのグループに明確な利点があります。

ISV アプリケーション プロバイダーの場合

ISV の場合、SSO を使用すると、アプリケーションの販売とサポートが容易になります。

  • エンタープライズ対応性: SSO により、アプリはエンタープライズ顧客に適しています。
  • オンボードの高速化: お客様は、追加の資格情報を管理せずにアプリをデプロイします。
  • 競争上の利点: エンタープライズ 購入者は多くの場合、SSO を必要とします。
  • よりシンプルなユーザー管理: アプリは、独自のユーザー データベースではなく、顧客の ID システムに依存します。

エンド ユーザーと組織向け

ユーザーと管理者の SSO により、毎日のアクセスとセキュリティが向上します。

  • ユーザー エクスペリエンスの向上: ユーザーが保持する資格情報の数を減らし、サインインの頻度を減らします。
  • セキュリティの強化: 一元的なサインインでは資格情報の公開が制限され、一貫性のあるポリシーが適用されます。
  • アクセス管理の容易さ: 管理者は、1 つの ID プロバイダーからのアクセスを制御します。
  • サポートのオーバーヘッドが少ない: パスワードのリセットとアカウント タスクがヘルプ デスクに届く数が少なくなります。

シングル サインオンのオプション

適切な SSO 方法は、アプリの認証方法と実行場所によって異なります。 Microsoft Entra IDでは、いくつかの方法がサポートされています。

フェデレーション ベースの SSO

フェデレーション ベースの SSO により、最も高度な統合が実現します。 Microsoft Entra IDは、ユーザーを認証し、標準プロトコルを使用して ID 情報をアプリに送信します。

セキュリティ アサーション マークアップ言語 (SAML) 2.0: 企業で広く使用されている成熟した XML ベースの標準。 SAML は、従来の Web アプリや、詳細なユーザー属性が必要なケースに適しています。

OpenID Connect (OIDC):JSON ベースのトークンを使用する OAuth 2.0 上に構築された最新のプロトコル。 OIDC は、認証と承認の両方を必要とする最新の Web アプリ、モバイル アプリ、API に適しています。

プロトコルに関する考慮事項:

  • ISV 開発者の場合:OIDC は通常、最新のフレームワークを使用して構築する方が簡単です。 SAML は、より広範なエンタープライズ互換性を提供します。
  • 管理者の場合: どちらのプロトコルも ID インフラストラクチャと連携しますが、SAML は確立されたエンタープライズ システムに適している可能性があります。

パスワードベースの SSO

パスワードベースの SSO は、ユーザー名とパスワードのサインインを使用するアプリで機能します。 Microsoft Entra ID資格情報を安全に格納し、アプリに再生します。 この方法は、フェデレーション プロトコルをサポートしていないアプリ、特にアプリケーション プロキシを使用するオンプレミス アプリに役立ちます。 アプリケーション プロキシは、セキュリティで保護されたリモート アクセスのためにオンプレミス アプリを発行します。

連携済みSSO

リンクされた SSO は、アプリの移行中に一貫したエクスペリエンスを維持します。 ユーザー ポータルにアプリ リンクが追加されますが、真のシングル サインオンは提供されません。 完全な SSO が後で提供される段階的な移行に使用します。

無効な SSO

SSO が無効になっている場合、ユーザーは各アプリに個別にサインインします。 テスト中、または統合サインインを必要としないアプリの場合は、この設定を使用します。

MICROSOFT ENTRA IDでの SSO のしくみ

SSO プロセスには、ユーザー、アプリ、ID プロバイダーとしてのMicrosoft Entra IDの 3 つの部分があります。

  1. ユーザーがアクセスを要求する: ユーザーがアプリを開きます。
  2. サインインへのリダイレクト: アプリはユーザーをMicrosoft Entra IDに送信します。
  3. ID チェック: Microsoft Entra IDは、ユーザーの作業資格情報を検証します。
  4. アクセス許可: Microsoft Entra IDはユーザーの ID を確認し、アプリはアクセス権を付与します。

この 4 段階のプロセスは自動的に行われるため、アプリはユーザー資格情報を直接管理しません。

SSO の導入を計画する

SSO ロールアウトの成功は、アプリのホスティング、ユーザーのニーズ、統合オプションによって異なります。 アプリは、オンプレミス、クラウドでサービスとしてのソフトウェア (SaaS)、またはハイブリッド環境で実行できます。 各ホスティング モデルは、SSO アプローチを形作っています。

  • クラウド アプリ では、通常、SAML や OpenID Connect などのフェデレーション プロトコルが使用されます。
  • オンプレミス アプリでは、アプリケーション プロキシを介してフェデレーション プロトコルまたはパスワードベースの SSO を使用できます。
  • ハイブリッド シナリオでは、 各アプリのニーズに基づいてアプローチが組み合わせられます。

包括的な計画ガイダンスについては、組織の シングル サインオン展開の計画 と、アプリケーション開発者 向けの ISV アプリケーションの SSO 統合の計画 に関するページを参照してください。

ユーザー エクスペリエンス: マイ アプリ ポータル

エンド ユーザーは、マイ アプリ ポータルを使用して SSO 対応アプリケーションにアクセスします。これにより、割り当てられたすべてのアプリケーションに一元的な場所が提供されます。 ユーザーは、複数の資格情報を覚えずにアプリケーションを見つけて起動できます。 詳細については、「マイ アプリ ポータルからアプリにサインインして開始する」を参照してください。

関連するコンテンツ

ロールに基づいて次のステップを選択します。

ISV アプリケーション開発者向け: SAML と OpenID Connect の違いについて説明します。これにより、アプリと顧客に適したプロトコルを選択できます。

IT 管理者と ID プロフェッショナル向け: 組織のアプリ全体に SSO をデプロイする方法を計画します。 アプリポートフォリオを確認し、統合アプローチを選択し、ロールアウト戦略を設定します。

  • Last updated on