重要なポイント：
InCommonやEduGAINなどの多者間フェデレーションフレームワークとOktaを連携するには、フェデレーションアダプター（Cirrus IdentityやShibbolethなど）を使用して、Oktaの二者間SAMLアーキテクチャとInCommonの動的メタデータレジストリを橋渡しする必要があります。
機関は、アウトバウンドアクセスにはOktaをInCommonのアイデンティティプロバイダー（IdP）として、インバウンドコラボレーションにはサービスプロバイダー（SP）として展開できます。
OktaとInCommonの統合の概要
高等教育機関や提携研究施設にとって、InCommonフレームワークの活用は不可欠です。従来、OktaはInCommonで使用される二者間フェデレーションモデルをサポートしていませんでした。しかし、解決策は存在します。このガイドでは、OktaテナントをInCommonやeduGAINなどの多者間フェデレーションモデルと統合するための技術的な概要とアーキテクチャパターンを解説し、InCommon Federationにアイデンティティプロバイダー（IdP）またはサービスプロバイダー（SP）として参加するための方法を紹介します。
主な統合ユースケース
このガイドは、Oktaを主要なアイデンティティプラットフォームとして使用しているものの、InCommon IDPまたはInCommon SPとしてInCommonを介して、より広範な研究教育（R&E）コミュニティとの相互運用性を必要とする機関のアイデンティティアーキテクトを対象としています。
ここでは、主なシナリオを2つ取り上げます。
- OktaをInCommonのIdPとして利用：Oktaを導入している教育機関で認証済みの学生に、サードパーティのInCommonリソースへのアクセスを許可します。
- OktaをInCommonのSPとして利用：Oktaで教育機関のアプリケーションのセキュリティを確保しながら、より広範なInCommonコミュニティからのアクセスを可能にします。
Oktaをトランザクションの両側に配置した構成を紹介しますが、これらのモデルは、その他のエンタープライズ向けアイデンティティとアクセス管理（IAM）ソリューションにも適用できます。
フェデレーション用語の整理：IdPとSP
アイデンティティプロバイダー（IdP）およびサービスプロバイダー（SP）という用語の使用は、適切ではあるものの、コンテキストに依存する場合があります。
- アーキテクチャパターン1（InCommon IdPとしてのOkta）：Oktaは、大学のアプリケーション用のIdPであり、フェデレーションアダプターであるCirrus Bridge用のIdPでもあります。このアダプターは、Oktaに対してSPとして機能します。ただし、このユースケースでは、Cirrus BridgeはInCommon IdPとしても機能し、学生や教職員はInCommon SPとして機能するサードパーティのリソースにSSOでアクセスできます。この場合、OktaはIdP、Cirrus BridgeはSP兼IdP、サードパーティのリソースはSPとなります。
- アーキテクチャパターン2（OktaをInCommon SPとして利用）：Oktaは、研究機関の学生と教職員の両方が使用する研究機関アプリケーションのIdPです。同時に、Oktaは外部のInCommonユーザーをアプリケーションにアクセスさせることができます。外部のInCommonユーザーの場合、OktaがSP、Cirrus ProxyがIdPとなります。しかし、Cirrus ProxyはInCommon SPです。
フェデレーションモデルの比較：二者間と多者間
Oktaの二者間フェデレーションモデル
Oktaは市場をリードするIAMサービスであり、SAML（Security Assertion Markup Language）、OIDC（OpenID Connect）、オンプレミスのヘッダーベースアプリケーションへのアクセスを提供します。多くの高等教育機関や研究機関がOktaを利用しており、場合によっては、1つの機関がIdPとSPの両方の役割を担うこともあります。Oktaのフェデレーションアーキテクチャは、単一のIdPと単一のSPの間に設定された、固有のポイントツーポイントの信頼関係に基づいています。
このポイントツーポイントのアプローチは二者間フェデレーションと呼ばれ、すべての主要な商用IAMベンダーが使用する標準モデルです。このモデルは、きめ細かい制御を可能にし、エンタープライズおよび商用アプリケーションの標準となっています。
InCommonの多者間フェデレーションモデル
Oktaでは、フェデレーションパートナーシップごとに、事前に構成された特定の接続を必要とする二者間アプローチを採用していますが、これとは対照的に、InCommonは多者間フェデレーションモデルで運用されています。これは、数千の参加機関が個別の二者間関係を構築することなく相互運用できる、多対多の信頼フレームワークです。
中央の信頼レジストリが、全メンバーのSAMLメタデータを含むメタデータサービスをホストすることで、この仕組みを実現しています。InCommonは、この信頼レジストリを「従来のSAMLメタデータアグリゲート（Legacy SAML Metadata Aggregate）」または「メタデータクエリ（MDQ）サービス（Metadata Query (MDQ) Service）」として提供しています。SPはInCommonフェデレーション全体を信頼し、このメタデータを取り込むことで、登録されている任意のIdPから認証を受け入れられます。
多者間フェデレーションとメタデータサービスは、商用モデルと研究・教育（R&E）コミュニティモデルとの最大の差別化要因ですが、違いはそれだけではありません。InCommonは、標準化された認証要件と属性要件も定義しています：
- REFEDS MFAプロファイルに準拠した、特定の多要素認証（MFA）アサーションを表します。
- 事前に定められた同意フレームワークに基づき、標準化されたユーザー属性バンドルをリリースします。
Oktaは、多者間フェデレーションに必要な動的なメタデータ消費をネイティブでサポートしていないため、仲介役としてフェデレーションアダプターを使用する必要があります。
フェデレーションアダプターのアーキテクチャ：統合の前提条件
Oktaの二者間モデルとInCommonの多者間モデルの間のギャップを埋めるには、接続のIdP側とSP側の両方で専用のアダプターを使用する必要があります。
- InCommon IdP（パターン1）として：このアダプターはInCommonメタデータフィードを処理し、標準的な二者間SAML接続を介してOktaと通信します。
- InCommon SP（パターン2）として：このアダプターは、ユーザーに所属機関を特定するよう求め、その機関のメタデータを検索し、その機関への正しい認証リクエストを生成した後、受信したSAMLアサーションを処理して検証します。
アダプターの選択：ShibbolethとCirrus Identityの比較
研究・教育（R&E）コミュニティでは、主に2つのアダプターソリューションが広く受け入れられています。Cirrus IdentityとShibbolethです。
Cirrus Identity：この目的のために特別に設計された、商用のSaaSベースのソリューションであり、導入と管理を簡素化できます。Cirrusは、異なる2つのソリューションを提供しています。ユースケース1（InCommon IdP）で使用するCirrus Bridgeと、ユースケース2（InCommon SP）で使用するCirrus Proxyです。Cirrusは、これらの統合に関する詳細なドキュメントを提供しており、主な参考資料として利用できます。
Shibboleth：R&Eコミュニティで広く利用されているオープンソースのソフトウェアプロジェクトです。オンプレミスまたはプライベートクラウドに展開できます。Shibboleth IdPソフトウェアは、アダプターコンポーネントとして機能します。主なリソース：
Cirrus IdentityとShibbolethは、OktaとInCommonアダプターを使用する場合のいずれの構成でも利用できます。どちらのソリューションを選択するかは、組織の方針や運用上の好みによって決まります。
| 機能 | Cirrus Bridge/Proxy | シボレス |
|---|---|---|
| 展開モデル | サービスとしてのソフトウェア（SaaS） | セルフホスト型（オンプレミスまたはクラウド仮想マシン） |
| 長所 |
|
|
| 短所 |
|
|
アーキテクチャパターン1：OktaをInCommonのアイデンティティプロバイダーとして利用する
このシナリオでは、ある大学が学生、教職員のためにOktaを利用しています。大学は、学生情報システムや人事システムからOktaに情報を提供し、Google Workspace、Microsoft Entra ID、Canvas、Blackboardなどのさまざまなアプリにプロビジョニング、シングルサインオン（SSO）、MFAを提供しています。OktaはActive Directoryへのユーザーのプロビジョニングも行います。大学のユーザーが、学術雑誌、サードパーティの図書館サービス、NSFアプリケーションなど、InCommonフェデレーションに参加している外部サービスにアクセスできるようにすることが目標です。
アーキテクチャ設定
- 大学がInCommonの信頼レジストリに、Cirrus Bridgeを正式なIdPとして登録します。
- Cirrus Bridgeは、信頼できるSAML IdPとしてアップストリームの大学のOktaテナントを参照するように構成されています。
- Oktaは、ユーザーのプライマリ認証、MFAの適用、および中核となるアイデンティティライフサイクル管理を処理します。
OktaをIdPとして利用する場合の認証フロー
IDP-initiated flowの場合は、オプションのログインから開始します
- 未認証のユーザーがOktaのエンドユーザーダッシュボードに直接ログインします。
- ユーザーが対象の外部InCommonアプリケーションへのリンクをクリックします。
- OktaはSAMLアサーションを生成し、Cirrus Bridgeに送信します。
- Cirrus Bridgeはアサーションを多者間形式に変換し、ターゲットリソースに渡します。
SP-initiated flowの場合は、オプションのログインは使用せず、必要に応じてログインします
- ユーザーは、ターゲットのサードパーティInCommonリソースに直接移動します。
- リソースは、InCommonメタデータルックアップを使用してユーザーをCirrus Bridgeにリダイレクトします。
- Cirrus Bridgeは、プライマリ認証情報の検証のためにユーザーをOktaにリダイレクトします。
- 認証に成功すると、OktaはCirrus Bridgeにトークンを発行し、Cirrus Bridgeはユーザーをリソースに転送して戻します。
アーキテクチャパターン2：OktaをInCommonのサービスプロバイダーとして利用する
このシナリオでは、研究機関がOktaを使用して、自機関のアプリケーションへのアクセスを保護します。各ユーザーに個別の認証情報を発行する代わりに、この研究機関はInCommon Federationのユーザーを受け入れることを希望しています。そうすれば、新しいアカウントを作成しなくても、ユーザーは所属大学の認証情報を使って研究機関のアプリケーションにアクセスできるようになります。また、この研究機関は、研究スタッフが直接ログインできるようにすることも希望しています。
アーキテクチャ設定
- Cirrus Proxyは、InCommon SPとして多者間レジストリに登録されています。
- Oktaは、二者間SAML設定を使用して、インバウンドIdPとしてCirrus Proxyを信頼するように構成されています。
- ターゲットアプリケーションは、アプリケーションの標準SSOとしてOktaと直接統合されたままになります。
アイデンティティのディスカバリーと認証フロー
InCommonによるOktaへのアクセスを有効にする際、ユーザーが適切なパスでログインするようにすることが重要な要素となります。
内部スタッフ向けの直接ログインフロー
- 社内の調査スタッフは、Oktaアカウントを通じてアプリケーションに直接アクセスします。
- Oktaは、外部のディスカバリーパイプラインを呼び出すことなく、内部ユーザーを直接認証します。
外部InCommonユーザー向けのSP-initiatedログインフロー
外部ユーザーは、アプリケーションに直接移動するか、所属大学のダッシュボードから移動します。この時点で、以下の2つの方法のいずれかを使用して、ユーザーに認証情報の入力を求めることができます。どちらの方法を使用するかは、機関の要件に基づいて決まります。
ユーザーがリソースにアクセスすると、OktaがCirrus Proxyのディスカバリー画面へのリンクを含むログインウィジェットを表示します。
ユーザーはOktaウィジェットから直接ログインするか、「Login with InCommon（InCommonでログイン）」を選択できます。後者を選択すると、Cirrus ProxyのIdPディスカバリー画面に移動します。
ユーザーがリソースにアクセスすると、Cirrus ProxyがOktaウィジェットへのリンクを含むログインページを表示します。
ユーザーには、Cirrus ProxyのIdPディスカバリー画面がすぐに表示されます。
スタッフはOktaウィジェットから直接ログインできます。
この例では、ユーザーは認証にInCommonを使用することを選択します。
- ユーザーはCirrus Proxyのディスカバリーインターフェイスにリダイレクトされ、所属機関を選択します。
- Cirrus ProxyはMDQサービスにクエリを実行して所属機関のSAMLメタデータを取得し、ユーザーを所属大学のローカルログインページにリダイレクトします。
- 所属大学でのログインが成功すると、所属大学のIdPからCirrus ProxyにSAMLアサーションが送信されます。
- Cirrus Proxyはアサーションを検証し、フォーマットされたアサーションをOktaに送信して、ユーザーにアプリケーションへのアクセスを許可します。
Oktaで多者間フェデレーションを効率化
Oktaと多者間フェデレーションの統合は、必ずしも複雑ではありません。OktaのCirrus Federation Bridge連携により、高等教育機関や研究機関のエンドユーザーの認証とプロビジョニングが可能になります。
他のアイデンティティ管理ツールキットとは異なり、Oktaでは、Webアプリケーションとユーザーディレクトリを手動で接続するために時間やリソースを費やす必要がありません。Oktaでは、アプリケーションをOktaのサービスに直接統合しているため、お客様はアプリケーションをユーザーに展開するだけで済みます。
アプリケーション接続をエコシステム全体で簡素化する方法について詳しくは、アプリケーション統合ホワイトペーパーをダウンロードしてください。
