シングル サインオンのデプロイを計画する

この記事では、Azure Active Directory (Azure AD) でのシングル サインオン (SSO) のデプロイを計画するために使用できる情報を提供します。 Azure AD でお使いのアプリケーションを使用した SSO のデプロイを計画する場合は、次の点を考慮する必要があります。

  • アプリケーションを管理するには、どのような管理者ロールが必要ですか?
  • 証明書を更新する必要がありますか?
  • SSO の実装に関連する変更を誰に通知する必要がありますか?
  • アプリケーションの効果的な管理を確保するためにどのライセンスが必要ですか?
  • アプリケーションへのアクセスに共有ユーザー アカウントが使用されますか?
  • SSO デプロイのオプションを理解していますか?

管理者ロール

必ず、Azure AD 内で必要なタスクの実行に使用できる最小限のアクセス許可を持つロールを使用してください。 使用できるさまざまなロールを確認して、アプリケーションの各ペルソナのニーズを満たすのに適したものを選択してください。 一部のロールは、一時的に適用され、デプロイが完了した後に削除する必要があります。

ペルソナ ロール Azure AD ロール (必要な場合)
ヘルプ デスク管理者 Tier 1 サポート なし
ID 管理者 Azure AD に関する問題が発生した場合の構成とデバッグ 全体管理者
アプリケーション管理者 アプリケーションでのユーザーの構成証明、アクセス許可を持つユーザーの構成 なし
インフラストラクチャ管理者 証明書のロールオーバー所有者 全体管理者
ビジネスの所有者/利害関係者 アプリケーションでのユーザーの構成証明、アクセス許可を持つユーザーの構成 なし

Azure AD 管理者ロールの詳細については、「Azure AD の組み込みロール」を参照してください。

証明書

お使いのアプリケーションのフェデレーション SSO を有効にする場合、既定では 3 年間有効な証明書が Azure AD で作成されます。 必要に応じて、その証明書の有効期限をカスタマイズできます。 有効期限前に証明書を更新するための適切なプロセスがあることを確認します。

Azure portal でその証明書の期間を変更します。 必ず有効期限を記録し、証明書の更新を管理する方法を把握してください。 署名証明書のライフ サイクルの管理に関係する適切なロールと電子メール配布リストを特定することが重要です。 次のロールが推奨されます。

  • アプリケーションでユーザーのプロパティを更新する所有者
  • アプリケーションのトラブルシューティング サポートに対応する所有者
  • 証明書関連の変更通知用の電子メールの配布リスト (常時注意深く監視)

次の方法を使用して証明書を管理できます。

  • 証明書の自動ロールオーバー - Azure AD では署名キーのロールオーバーをサポートしています。 署名キーのロールオーバーは証明書を管理するための推奨される方法ですが、すべてのアプリケーションでこのシナリオがサポートされているわけではありません。

  • 手動による更新 - すべてのアプリケーションには、定義された方法に基づいて有効期限が切れる固有の証明書があります。 アプリケーションの証明書の有効期限が切れる前に、新しい証明書を作成して、アプリケーション プロバイダーに送信します。 この情報は、フェデレーション メタデータから取得できます。 詳細については、「フェデレーション メタデータ」を参照してください。

Azure AD とお使いのアプリケーションの間で証明書の変更を処理する方法に関するプロセスを確立します。 このプロセスを実行することで、証明書の期限切れや強制的な証明書のロールオーバーによる停止を防止または最小限に抑えられます。 詳細については、「Manage certificates for federated single sign-on in Azure Active Directory」(Azure Active Directory でフェデレーション シングル サインオンの証明書を管理する) を参照してください。

通信

コミュニケーションは、新しいサービスの成功に必要不可欠です。 エクスペリエンスがどのように変化するかについて、ユーザーに事前に通知します。 いつ変化するか、および問題が発生したときにどのようにしてサポートを受けられるかについて連絡します。 ユーザーが、SSO が有効なアプリケーションにアクセスする方法に関する選択肢を確認し、お客様の選択に合わせてコミュニケーションを構築します。

コミュニケーションの計画を実装します。 変更が行われる予定であること、変更が行われる時期、および現時点で行う操作をユーザーに必ず通知します。 また、サポートを要請する方法に関する情報も必ず提供します。

ライセンス

アプリケーションが次のライセンス要件の対象となっていることを確認します。

  • Azure AD のライセンス - 事前統合されたエンタープライズ アプリケーション向けの SSO は無料です。 ただし、お使いのディレクトリ内のオブジェクト数とお客様がデプロイしたい機能によっては、追加のライセンスが必要になる場合があります。 ライセンス要件の詳細一覧については、「Azure Active Directory の価格」を参照してください。

  • アプリケーション ライセンス - お客様のビジネス ニーズを満たすためには、お使いのアプリケーションに適したライセンスが必要になります。 アプリケーション所有者と連携して、アプリケーションに割り当てられたユーザーに、アプリケーション内での自分のロールに適したライセンスが設定されているかどうかを判断します。 Azure AD で、ロールに基づいた自動プロビジョニングを管理している場合、Azure AD で割り当てられているロールの数は、アプリケーション内で所有されているライセンスの数と揃える必要があります。 アプリケーション内で所有されているライセンスの数が適切でない場合、ユーザー アカウントのプロビジョニングまたは更新時にエラーが発生する可能性があります。

共有アカウント

サインインの観点からは、共有アカウントを使用しているアプリケーションは、個々のユーザーのパスワード SSO を使用しているエンタープライズ アプリケーションと違いはありません。 ただし、共有アカウントを使用するようにアプリケーションを計画および構成する場合に必要な追加手順があります。

  • ユーザーと協力して、次の情報を文書にまとめます。
    • アプリケーションを使用する組織の一連のユーザー。
    • 一連のユーザーに関連付けられているアプリケーションの既存の資格情報セット。
  • ユーザーのセットと資格情報の組み合わせごとに、要件に基づいて、クラウドまたはオンプレミスにセキュリティ グループを作成します。
  • 共有の資格情報をリセットします。 Azure AD にアプリケーションがデプロイされると、個々のユーザーには共有アカウントのパスワードが不要になります。 パスワードは Azure AD で保存されるので、長く複雑なものに設定する必要があります。
  • アプリケーションがサポートしている場合は、パスワードの自動ロールオーバーを構成します。 この方法では、初期セットアップを行った管理者でさえも、共有アカウントのパスワードを知ることはありません。

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

SSO のためにアプリケーションを構成できる方法はいくつかあります。 SSO 方法の選択は、アプリケーションが認証についてどのように構成されているかによって変わります。

  • クラウド アプリケーションでは、OpenID Connect、OAuth、SAML、パスワードベース、またはリンクを SSO に使用できます。 シングル サインオンを無効にすることもできます。
  • オンプレミスのアプリケーションでは、パスワード ベース、統合 Windows 認証、ヘッダー ベース、リンクを SSO に使用できます。 オンプレミスの選択肢は、アプリケーションのアプリケーション プロキシが構成されている場合に機能します。

このフローチャートは、実際の状況に最適な SSO の方法を判断するのに役立ちます。

シングル サインオン方法の判断のフローチャート

次の SSO プロトコルを使用できます。

  • OpenID Connect と OAuth - 接続しているアプリケーションでサポートされている場合は、OpenID Connect と OAuth 2.0 を選択します。 詳細については、「Microsoft ID プラットフォームにおける OAuth 2.0 プロトコルと OpenID Connect プロトコル」を参照してください。 OpenID Connect SSO を実装する手順については、「クイック スタート: アプリケーションの OIDC ベースのシングル サインオンを設定する」を参照してください。

  • SAML - OpenID Connect または OAuth を使用しない既存のアプリケーションには、可能な限り SAML を選択してください。 詳細については、「シングル サインオンの SAML プロトコル」を参照してください。 SAML SSO を実装する簡単な概要については、「クイック スタート: アプリケーションの SAML ベースのシングル サインオンを設定する」を参照してください。

  • パスワードベース - アプリケーションに HTML サインイン ページがある場合は、パスワードベースを選択します。 パスワードベースの SSO はパスワード保管とも呼ばれます。 パスワードベースの SSO では、ID フェデレーションをサポートしない Web アプリケーションに対するユーザーのアクセスとパスワードを管理できます。 これは、複数のユーザーが 1 つのアカウント (組織のソーシャル メディア アプリ アカウントなど) を共有する必要がある場合にも便利です。

    パスワードベースの SSO では、サインインするためにユーザー名とパスワード以外のフィールドも必要とするアプリケーションのために、複数のサインイン フィールドを必要とするアプリケーションをサポートします。 ユーザーが資格情報を入力するときにマイ アプリに表示されるユーザー名とパスワードのフィールドのラベルをカスタマイズできます。 パスワードベースの SSO を実装する手順については、「パスワードベースのシングル サインオン」を参照してください。

  • リンク - アプリケーションが別の ID プロバイダー サービスで SSO 用に構成されている場合は、リンクを選択します。 リンク オプションを使用すると、ユーザーが組織のポータルでアプリケーションを選択するときにターゲットとなる場所を構成できます。 Active Directory フェデレーション サービス (AD FS) など、現在フェデレーションを使用しているカスタム Web アプリケーションにリンクを追加できます。

    また、ユーザーのアクセス パネルに表示する特定の Web ページや、認証を必要としないアプリへのリンクも追加できます。 [リンク] オプションでは、Azure AD 資格情報を使用したサインオン機能は提供されません。 リンクされた SSO を実装する手順については、「リンクされたサインオンの概要」を参照してください。

  • 無効化 - アプリケーションを SSO 用に構成する準備ができていない場合は、無効化 SSO を選択します。

  • 統合 Windows 認証 (IWA) - IWA を使用するアプリケーションまたは要求に対応するアプリケーションには、IWA シングル サインオンを選択します。 詳細については、「アプリケーション プロキシを使ったアプリへのシングル サインオン (SSO) の Kerberos の制約付き委任」を参照してください。

  • ヘッダーベース - アプリケーションが認証のためにヘッダーを使用する場合は、ヘッダー ベースのシングル サインオンを選択します。 詳細については、「ヘッダーベースの SSO」を参照してください。

次のステップ