Microsoft は、多くの場合、アプリケーションがクラウドベースまたはオンプレミスでホストされているハイブリッド環境で動作する研究大学と話します。 どちらの場合も、アプリケーションではさまざまな認証プロトコルが使用される可能性があります。 これらのプロトコルは、サポート終了が間近であったり、必要なレベルのセキュリティを提供していなかったりする場合があります。
さまざまな認証プロトコル、さまざまな ID 管理 (IdM) メカニズムに対するニーズは、その多くがアプリケーションによって生じています。
研究大学の環境では、多くの場合、研究アプリによって IdM についての要件が生じます。 大学は、Shibboleth などのフェデレーション プロバイダーをプライマリ ID プロバイダー (IdP) として使用することがあります。 その場合、Microsoft Entra ID は Shibboleth とフェデレーションするように構成されていることがよくあります。 Microsoft 365 Apps も使用している場合は、Microsoft Entra ID を使用して統合を構成できます。
研究大学で使用されるアプリケーションは、IT フットプリント全体のさまざまな部分で動作します。
調査アプリケーションや多国間フェデレーション アプリケーションは、InCommon と eduGAIN を通じて使用できます。
ライブラリ アプリケーションは、電子ジャーナルやその他の電子コンテンツ プロバイダーへのアクセスを提供します。
一部のアプリケーションでは、Central Authentication Service などのレガシ認証プロトコルを使用してシングル サインオンを使用できるようにしています。
学生と教職員のアプリケーションで、複数の認証メカニズムが使用されている場合があります。 たとえば、Shibboleth や他のフェデレーション プロバイダーと統合されているものもあれば、Microsoft Entra ID と統合されているものもあります。
Microsoft 365 アプリケーションは、Microsoft Entra ID と統合されています。
Windows Server Active Directory が使われて Microsoft Entra ID と同期されている場合もあります。
ライトウェイト ディレクトリ アクセス プロトコル (LDAP) は、外部 LDAP ディレクトリまたは ID レジストリを持つ多くの大学で使用されています。 これらのレジストリは、多くの場合、機密属性、ロール階層情報、さらには申請者などの特定の種類のユーザーを格納するために使用されます。
オンプレミス Active Directory または外部 LDAP ディレクトリは、多くの場合、Web 以外のアプリケーションやさまざまな Microsoft オペレーティング システム以外のサインインについてシングル資格情報サインインを有効にするために使用されます。
ベースライン アーキテクチャの課題
多くの場合、ベースライン アーキテクチャは時間の経過と共に進化し、それにより設計に複雑さと剛性がもたらされ、更新機能が導入されます。 ベースライン アーキテクチャを使用する場合の課題には、次のようなものがあります。
新しい要件に対応するのは難しい: 複雑な環境では、最新の規制や要件に迅速に適応して対応することが困難になります。 たとえば、アプリが多数の場所にあり、これらのアプリがさまざまな IDM でさまざまな方法で接続されている場合は、多要素認証サービスを配置する場所と多要素認証を適用する方法を決定する必要があります。
高等教育では、サービス所有権の断片化の問題も生じます。 エンタープライズ リソース プランニング 、学習管理システム、部門、部署ソリューションなどの主要なサービスを担当する担当者は、運用するシステムを変更したり修正したりする作業に抵抗する可能性があります。
アプリによっては、Microsoft 365 の機能を活用できない (たとえば、Intune、条件付きアクセス、パスワードレスなど): 多くの大学がクラウドに移行し、Microsoft Entra ID への既存の投資を活用したいと考えています。 しかしながら、別のフェデレーション プロバイダーがプライマリ IdP として使用されていると、大学としてはその他のアプリについて、Microsoft 365 機能で使用できなくなるものが生じてくることがあります。
ソリューションの複雑さ: 管理するコンポーネントは多数あります。 クラウド内にあるコンポーネントもあれば、オンプレミスまたはサービスとしてのインフラストラクチャ (IaaS) インスタンスにあるコンポーネントもあります。 アプリはさまざまな場所で動作します。 ユーザーの観点からは、エクスペリエンスに連続性が欠けているように感じられる可能性があります。 たとえば、ユーザーには Shibboleth サインイン ページが表示されることもあれば、Microsoft Entra サインイン ページが表示されることもあります。
これらの課題を解決すると同時に、次の要件にも対処できる 3 つのソリューションを提示します。
InCommon や eduGAIN などの多国間フェデレーションに参加する機能
すべての種類のアプリ (レガシ プロトコルを必要とするアプリも含む) をサポートする機能
外部ディレクトリと属性ストアをサポートする機能
これら 3 つのソリューションは、上から推奨度が高い順に提示されています。 それぞれが要件を満たしますが、複雑なアーキテクチャにおいて想定されるトレードオフの決定を行う必要があります。 要件と開始点に基づいて、お使いの環境に最適なものを選択してください。 この決定に役立つデシジョン ツリーも用意されています。
次のステップ
多国間フェデレーションに関する次の記事を参照してください。
多国間フェデレーション ソリューション 1: Microsoft Entra ID と Cirrus Bridge
多国間フェデレーション ソリューション 2: セキュリティ アサーション マークアップ言語 (SAML) プロキシとしての Shibboleth を使用した Microsoft Entra ID
多国間フェデレーション ソリューション 3: AD FS を使用した Microsoft Entra ID と Shibboleth