サービス比較の記事一覧

AIで顧客対応・サポート業務を自動化したい

サービス比較の記事一覧

AIで顧客対応・サポート業務を自動化したい

大学の統合認証基盤とは?SSO・ID管理・学認連携の仕組みと導入事例・選び方

大学の統合認証基盤とは?SSO・ID管理・学認連携の仕組みと導入事例・選び方のサムネイル画像
IDaaS(ID管理システム)比較表(2026年版)のプレビュー

主要6サービスの料金・機能を無料で一覧比較

IDaaS(ID管理システム)比較表(2026年版)

大学では、教務システムや学習管理システム(LMS)、大学メール、図書館の電子リソースなど、利用するシステムごとにIDとパスワードが分かれていることが少なくありません。利用者からのパスワード忘れの問い合わせが絶えず、学生の入学・卒業のたびにアカウントを大量に発行・停止する作業にも追われがちです。

統合認証基盤は、こうしてばらばらになったIDとログインを一つにまとめる仕組みです。一度のログインで複数のシステムを使えるようにし、IDの管理を一元化します。

本記事では、大学の統合認証基盤が何を・どうやってまとめるのかという構成の全体像から、他大学の導入事例、学術認証フェデレーション(学認、GakuNin)との連携や学生のID管理といった大学ならではの論点、構築にかかる費用の目安、そして頼める製品の種類と選び方までを解説します。

IDaaS(ID管理システム)の関連サービス資料
PR
料金や機能は各社の資料でまとめて比較できます 【無料】IDaaS(ID管理システム)の資料を
一括ダウンロードする
本セクションにはプロモーションが含まれており、表示順は当社独自の基準や提携状況に基づいています。

大学の統合認証基盤とは?構成の全体像

ここからは、統合認証基盤が何を・どうまとめる仕組みなのか、その構成要素と全体像を解説します。

大学の統合認証基盤とは、学生・教職員が使う複数のシステムのIDとログインを一つにまとめ、本人確認(認証)とアカウント管理を集約する基盤のことです。教務システムや大学メール、図書館の電子リソースなど、それまで個別に管理していたログインを一箇所に集め、利用者は一度の認証で複数のサービスを使えるようになります。

統合認証基盤を構成する要素(ID管理・IdP・SSO・多要素認証・学認)

統合認証基盤は、いくつかの機能が組み合わさってできています。それぞれの役割を押さえると、全体像がつかみやすくなります。

  • ID管理:学生・教職員のアカウント情報を一元的に登録・更新・削除する機能です。人事システムや学籍のデータをもとに、入学・異動・退職にあわせてアカウントを管理します。
  • IdP(アイデンティティ・プロバイダー):利用者が本人かどうかを確認し、その人の属性(学生か教職員かなど)を各システムに伝える、認証の中心となる役割です。
  • SSO(シングルサインオン):一度ログインすれば、連携した複数のシステムを追加のログインなしで使える仕組みです。
  • 多要素認証(MFA):パスワードに加えて、スマートフォンアプリのワンタイムパスワードや生体認証など、別の要素を組み合わせて本人確認を強める仕組みです。
  • 学術認証フェデレーション(学認、GakuNin):大学や学術コンテンツの提供機関が相互に認証を連携する、大学に固有の枠組みです。自大学のIdPで認証した利用者が、他機関の電子ジャーナルなどを使えるようになります。

認証の技術的な土台には、SAMLやOpenID Connectといった標準規格が使われます。大学で広く使われている学認は、米国Internet2が開発したShibboleth(シボレス)という仕組みを基盤にしています。Shibbolethは、認証を担うIdPと、保護対象のサービス側に置くSP(サービス・プロバイダー)などから成るSSOの仕組みです。

学認そのものについては、国立情報学研究所(NII)が次のように説明しています。

学術認証フェデレーションとは、学術e-リソースを利用する大学、学術e-リソースを提供する機関・出版社等から構成された連合体のことです。各機関はフェデレーションが定めた規程(ポリシー)を信頼しあうことで、相互に認証連携を実現することが可能となります。学術認証フェデレーション「学認」は、技術的には米国Internet2が開発したShibbolethを使用して実現しています。

出典:フェデレーションとは|学認(GakuNin)・国立情報学研究所

どう繋がって一つの基盤になるか

これらの要素は、それぞれが独立して動くのではなく、一つの流れでつながっています。まず、人事・学籍のデータをもとにID管理の仕組みがアカウントを整えます。利用者がログインしようとすると、認証の中心であるIdPがパスワードや多要素認証で本人を確認します。

確認が済むと、IdPは「この人は在学生です」といった属性を各システムに伝え、利用者は教務システムや大学メールなどを追加のログインなしで使えます。学外の電子ジャーナルなどを使う場合は、学認を通じて自大学のIdPでの認証結果が提供機関側に伝わります。

このように統合認証基盤は、「ID管理でアカウントを整える」「IdPで本人を確認する」「SSOと学認で各システムに認証結果を渡す」という役割分担で、ばらばらだったログインを一本化します。

ここまでの流れを一つの図にまとめると、次のようになります。

大学の統合認証基盤がつながる流れの図解。ID管理が人事・学籍データをもとにアカウントを発行・更新・停止し、IdPがパスワードや多要素認証で本人を確認して属性を各システムに伝え、SSOで学内の教務システムや大学メールに、学認で学外の電子ジャーナルなどに認証結果を渡すことを示す。

大学が統合認証基盤を導入するメリット

統合認証基盤を整えると、運用・セキュリティ・利便性のそれぞれで効果が見込めます。

運用面では、アカウントの発行・停止を一元管理できるため、システムごとに同じ作業を繰り返す手間が減ります。導入事例でも、問い合わせで最も多いのは利用者のパスワード忘れだったと報告されており、ログインの一本化はこうした問い合わせ対応の負担軽減につながります。

この問い合わせ対応の負担が実際にどの程度軽くなるのかについて、IDaaSを提供する株式会社インターナショナルシステムリサーチは、独自インタビューでパスワードレス認証を導入した企業の事例を次のように説明しています。

平澤氏
株式会社インターナショナルシステムリサーチ 営業本部マーケティング部
平澤氏
独自インタビューより

導入と同時にパスワードレス認証に切り替えた企業では、IT部門の業務の約20%を占めていたパスワード関連のヘルプデスク業務が「0%」になったという事例があります。

大学でも、パスワード忘れの問い合わせは情報システム部門の負担の多くを占めます。ログインの一本化や認証方式の見直しは、こうした問い合わせ対応の負担を軽くすることにつながります。

セキュリティ面では、認証を一箇所に集めることで、多要素認証やアクセス制限といった対策をまとめて適用できます。利用者ごとのパスワードの使い回しや、退職・卒業後もアカウントが残り続けるといったリスクを抑えやすくなります。

大学における情報セキュリティ対策の枠組みとしては、国立情報学研究所が、認証関連を含む規程の雛型として「高等教育機関の情報セキュリティ対策のためのサンプル規程集」を公開しています。自大学の認証やアカウント管理のポリシーを定めるときの土台として活用できます。

利便性の面では、学生・教職員が覚えるパスワードが減り、一度のログインで必要なシステムに入れるようになります。

出典・参考資料(1件)

他大学の統合認証基盤の導入事例

ここからは、実際に統合認証基盤を構築した大学の事例を、採用した構成・製品とともに見ていきます。自大学の導入や更改を検討する際の参考材料として整理します。

以下に、構成や採用製品が公開されている大学の事例をまとめます。

← 横にスクロールできます →
大学名京都産業大学鶴見大学・鶴見大学短期大学部東京農工大学帝京大学(八王子キャンパス)
規模・時点中規模私立大学(2011年頃の発表資料)2学部5学科+短大(2014年5月時点)国立大学(公式案内による現行構成)私立大学(公式案内による現行構成)
抱えた課題大学間共用eラーニングシステムとの認証連携システムごとにID・パスワード管理が分かれ、パスワード忘れの問い合わせが多発複数のクラウドサービスのログイン統合と学外アクセスの保護教務システム・LMS・大学メールなど複数システムのログイン統合
採用した構成・製品OpenLDAP(認証情報の集約)+Shibboleth(学認連携)+MoodleLDAP Manager(ID管理)+OpenAM(SSO)+AXIOLE(学認用)+認証ネットワーク統合認証システムによるSSO(Google・Microsoft・Zoom・学認など)学認対応の国産IDaaS「Extic」を基盤にCampusSquare・LMS・大学メールを連携
ポイントオープンソースで内製すれば低コスト。IdPの設定変更やソフトのアップデートなど運用作業が継続的に発生ID管理・SSO・学認・ネットワーク認証を組み合わせて構築。学認はテスト接続を経て運用準備メール認証のワンタイムパスワードを全ユーザー必須とし、アプリ認証を任意で追加学外ネットワークからのログイン時のみ多要素認証(Microsoft Authenticator)を要求

※各大学の公開資料・公式案内による。年次の記載がある事例はその時点の構成です。

事例を読む際は、年次に注意が必要です。京都産業大学(2011年頃)や鶴見大学(2014年)は年次が古く、現在のクラウド前提・多要素認証を標準とする構成とは前提が異なります。一方で、オープンソースでの内製や、ID管理・SSO・学認用サーバーを組み合わせるという構成の考え方そのものは、今でも参考になります。

東京農工大学と帝京大学は、クラウドサービスのログイン統合と、学外アクセス時の多要素認証を公式に案内しています。いずれも、クラウド利用を前提に認証を強化している現行の構成です。

出典・参考資料(4件)

大学ならではの論点(学認・IDライフサイクル・非常勤講師・学外MFA)

ここからは、一般的なSSOの説明にとどまらない、大学の統合認証基盤に固有の論点を整理します。更改仕様や要件定義で見落としやすい点ばかりなので、順に確認していきましょう。

学認(GakuNin)との連携は自動か、別に設定が要るか

統合認証基盤を作れば学認に自動でつながる、というわけではありません。学認はShibbolethを使ったフェデレーション(連合体)であり、参加するには自大学でShibbolethによるIdPを用意し、フェデレーションに加わる手続きが必要です。NIIは参加の流れを次のように案内しています。

学認に参加してIdPやSPを構築する際には、まずテストフェデレーションに参加して動作確認を行った後で、運用フェデレーションへ参加して下さい。

出典:参加するには|学認(GakuNin)・国立情報学研究所

このように学認連携は、IdPの構築に加えて、テスト環境での動作確認から運用環境への参加という段階を踏む工程になります。製品を選ぶ際は、この学認のIdP機能に対応しているか、あるいは別途Shibbolethを立てる必要があるかを確認しておくと、後の工数の見積もりがずれにくくなります。

学生の入学・卒業に伴うIDの大量発行・失効(IDライフサイクル)

大学のID管理が企業と大きく違うのは、年度や学期の節目にアカウントが一斉に動く点です。入学時には新入生のアカウントをまとめて発行し、卒業時には大量のアカウントを失効させます。留年・休学・復学といった状態の変化も反映しなければなりません。

これを手作業で行うと負担が大きいため、学籍・人事のデータと連携し、在籍状態の変化に応じてアカウントを自動で作成・更新・停止する仕組みが重要になります。製品選びでは、こうした人事・学籍データと連動したアカウントの自動管理(プロビジョニング)に対応しているかが、運用負担を左右します。

非常勤講師・兼任教員のIDをどう扱うか

大学には、専任の教職員のほかに、非常勤講師や複数の役割を兼ねる兼任教員が多く在籍します。こうした利用者は、契約期間が学期単位で限られていたり、学生と教員の両方の立場を持っていたりすることがあります。

そのため、立場に応じて使えるシステムや権限を分け、契約の終了にあわせて確実にアカウントを停止する運用が求められます。IDライフサイクルの設計では、専任教職員だけでなく、こうした立場の利用者を含めてアカウントの発行・権限・失効のルールを決めておくことが欠かせません。

具体的には、契約期間に合わせてアカウントを自動で失効させる設定や、学生とTA(ティーチングアシスタント)のように複数の立場を持つ利用者の属性・権限をどう設計するかを、あらかじめ決めておくと運用が安定します。

学外アクセス時の多要素認証(MFA)

在宅や出張先など、学外のネットワークからシステムにアクセスする場面は珍しくありません。学外からのアクセスは不正ログインのリスクが高まるため、多要素認証を組み合わせる大学が増えています。

運用の仕方は大学によって異なります。東京農工大学はメール認証のワンタイムパスワードを全ユーザーに必須とし、アプリ認証を任意で追加する形をとっています。帝京大学は、学外ネットワークからのログイン時のみMicrosoftのアプリによるMFAを要求する運用です。

学内からの通常利用では追加認証を求めず、リスクの高い学外アクセスに絞って多要素認証を適用するという設計は、利便性とセキュリティの両立を図る一つの考え方といえます。

出典・参考資料(2件)

統合認証基盤の構築にかかる費用・導入期間・工数の目安

ここでは、統合認証基盤の構築にかかる費用・導入期間・工数の考え方を整理します。これらは互いに関係する数字なので、分けて見るよりまとめて捉えるのが現実的です。

はじめに前提として、大学の統合認証基盤の費用・期間・工数を一般的な相場として示す公開情報は限られています。構成(オープンソースの内製か、製品の導入か、外部委託か)や、連携するシステムの数、学認対応の要否によって大きく変わるためです。ここでは公開されている事例と製品の料金の範囲で、費用感の捉え方を示します。

費用の目安は、実現する手段によって大きく異なります。クラウドのSaaS型製品を使う場合は、月額150〜600円程度/ユーザー(ID)が一つの目安です。製品やプラン・ID数によって変わり、教育機関向けにはさらに低い割安プラン(1ユーザーあたり月額60円程度から)を用意する製品もあります(具体的な料金は後述のサービス比較表を参照してください)。

オープンソースで内製する場合は、ソフトのライセンス費用はかからず、サーバーなどのインフラ費と、構築・運用にかかる人の手間が主なコストになります。外部に委託する場合の費用は公開情報が少なく一概に示せませんが、構成の規模に応じて相応の金額になります。

導入期間も手段によって変わります。SaaS型は比較的短期間で始められる一方、学認への参加やオープンソースの内製・外部委託では、設計・構築や接続試験の工程が加わるぶん期間は長くなります。

京都産業大学の学会発表資料(2011年頃)では、オープンソースを用いた構築のコスト感について次のように述べられています。

ハードウェアは通常のサーバ/ソフトウェアはオープンソースなので構築を内部の人間が対応できれば低コスト/「学認」の方からの強力な支援もあります/(必要に応じて)LDAPの属性追加/業者に委託すると…x百万?

出典:中規模私立大学における統合認証基盤の構築(構築コスト)|京都産業大学 情報センター(SINET/NII)

これは当時の概算であり確定額ではありませんが、費用の大枠は「内製できれば低コストに抑えられるが、外部委託すると相応の金額になる」という傾向で捉えられます。工数は、学認への参加(テスト環境での確認から運用参加までの工程)や、既存システムとの連携の数で変わります。

SaaS型を軸に検討する場合、各製品の月額・初期費用・オプション費用を公式の料金ページにもとづいて横並びで比較した記事もあります。導入費用を具体的に見積もる際の参考になります。

費用・工数が膨らむ要因=既存システム連携でつまずきやすいポイント

費用や工数が見積もりより膨らむ主な要因は、既存システムとの連携にあります。教務システムや図書館システムなど、大学には長く使われてきた独自のシステムが多く、それぞれがSSOの標準規格(SAMLなど)に対応しているとは限りません。

規格に対応していないシステムは、連携のための追加の作り込みや、代替の接続方式の検討が必要になります。また、運用が始まってからも、連携するサービスが増えるたびにIdPの設定変更や証明書の更新といった作業が発生します。構築時の費用だけでなく、こうした継続的な運用工数も見込んでおくと、導入後の負担を見誤りにくくなります。

誰に頼めるか:製品・サービスの種類と選び方

ここからは、統合認証基盤を実現する手段の種類と、大学の状況に合わせた選び方を整理します。大きく分けて、オープンソースを使った自前構築、クラウドで提供されるSaaS型の製品、そして外部のシステム開発会社への委託(SI委託)という選択肢があります。

統合認証基盤を実現する3つの手段を比較した図解。オープンソースの自前構築はライセンス費用がかからず運用体制がある大学向け、SaaS型の製品は月額利用で短期間に導入でき人員が限られる大学向け、SI委託は外部に設計から運用まで任せ専門人員を確保しにくい大学向けであることを示す。

オープンソースによる自前構築は、ソフトウェアのライセンス費用がかからない点が利点です。一方で、構築と運用を自大学の人員で担う必要があり、継続的な設定変更やアップデートに対応できる体制が前提になります。学認の標準基盤であるShibbolethもこの方式にあたります。

SaaS型の製品は、クラウドで提供される認証基盤を月額で利用する方式です。自前でサーバーを構築・保守する必要がなく、比較的短い期間で導入できます。学認への対応や多要素認証、人事データと連動したアカウントの自動管理といった機能が製品側に用意されているため、情報システム部門の人員が限られる大学でも運用しやすい選択肢です。学認対応の有無は製品によって異なるため、要件に含める場合は対応状況を確認します。

SI委託は、構成の設計から構築・運用までを外部の開発会社に任せる方式です。費用は大きくなりますが、学内に専門の人員を確保しにくい場合に現実的な選択肢になります。

選び方の軸としては、まず自大学の情報システム部門に構築・運用を担える人員がいるか、次に学認への対応が必要か、そして教務システムなど既存システムとの連携がどの程度必要かを整理すると、どの方式が合うかが見えてきます。予算の制約と運用にかけられる手間のバランスで判断するとよいでしょう。

料金や機能は各社の資料でまとめて比較できます 【無料】IDaaS(ID管理システム)の資料を
一括ダウンロードする

大学の統合認証基盤に使えるサービス

ここからは、大学の統合認証基盤を実現する具体的なサービスを紹介します。学認への対応、SAML 2.0による連携、SSO、多要素認証、アカウントの自動管理(プロビジョニング)といった観点で、代表的な製品を見比べられるように整理しました。

製品によって学認(GakuNin)への対応状況は異なります。学認連携が必須の大学は、まず比較表の「学認(GakuNin)対応」の列を確認し、対応が明記された製品を中心に検討するとよいでしょう。

← 横にスクロールできます →
サービス名CloudGate UNOExtic(エクスティック)KeycloakSeciossLink
提供形態クラウド(国産IDaaS)クラウド(国産IDaaS)/オンプレ連携オープンソース(セルフホスト)クラウド(国産IDaaS)
学認(GakuNin)対応要確認
公式に学認対応の記載なし
●学認IdP対応・アカデミックプランあり△自前構築が前提(公式の学認対応表明なし)●学認SPテンプレート・Educationプランあり
SSO・対応規格SSO対応/SAML 2.0・OpenID ConnectSSO対応/SAML 2.0・フォームベース認証SSO対応/SAML 2.0・OIDC・OAuth 2.0SSO対応/SAML・OpenID Connect
多要素認証(MFA)FIDO2・パスキー・生体認証・OTPFIDO2(パスキー)・TOTP・メールOTPパスキー・TOTP/HOTP・リカバリコードFIDO認証・OTP(アプリ/メール/Web OTP)・証明書認証
プロビジョニング●全プラン標準搭載●人事情報起点のID自動生成△SCIM連携はプレビュー段階●SCIM対応・ライフサイクル管理
料金の目安月額400〜600円/ユーザー(税抜)
初期費用は要問い合わせ
月額150円/ID〜(コース・ID数で変動、税別)
教育・学認向け特別プランあり
ソフトは無償(OSS)
インフラ・運用費は自己負担
月額150円/ユーザー〜(Standard・税抜)
教育機関向けEducationプラン60円/ユーザー
詳細情報公式資料を見るサービス詳細を見るサービス詳細を見る公式サイト

1. CloudGate UNO(株式会社インターナショナルシステムリサーチ)

CloudGate UNOのウェブサイト

CloudGate UNOは、ゼロトラストの考え方にもとづくシングルサインオンを提供する、株式会社インターナショナルシステムリサーチの国産IDaaSです。SAML 2.0に対応したクラウドサービスとの連携に対応し、SSOを中心にアカウント管理の基盤として使えます。

アクセス制限や、パスキーに対応した多要素認証、人事情報などと連動してアカウントを自動で作成・更新するプロビジョニング機能が、すべてのプランに標準で搭載されている点が特徴です。学生・教職員のアカウントを一元管理しつつ、学外アクセス時の認証を強化したい大学にとって、運用の負担を抑えやすい構成といえます。

2. Extic(エクスジェン・ネットワークス株式会社)

Extic(エクスティック)のウェブサイト

エクスジェン・ネットワークス株式会社が提供するExticは、学認に対応した国産のIDaaSです。学認のIdPとしても利用できるため、大学の統合認証基盤に求められる学認連携を製品側でまかなえます。帝京大学など、実際に大学の認証基盤として採用されている事例があります。

SAML 2.0に対応したクラウドサービスへのSSOに加え、TOTP・メールOTP・パスキーといった多要素認証で本人確認を強化できます。人事情報をもとに認証用・認可用のID情報を自動生成する機能も備えており、学籍データと連動したアカウント管理に向きます。料金は1ID単位の月額で、ID管理と認証をそろえたコースや、認証中心・ID管理中心のコースから選べる体系です。

3. Keycloak(Keycloakプロジェクト/OSS)

Keycloakのウェブサイト

Keycloakは、オープンソースで提供されるID・アクセス管理ソフトウェアです。特定の営利企業が販売する製品ではなく、CNCF(Cloud Native Computing Foundation)配下のプロジェクトとしてコミュニティ主導で開発され、Apache License 2.0で公開されています。ライセンス費用がかからないため、自前構築の選択肢として検討されます。

認証には、OpenID ConnectやSAML 2.0といった標準規格を用います。アプリケーションへの認証追加やユーザー管理を自前で作り込まずに実現できる点が特徴です。一方で、構築と運用を自大学で担う必要があるため、対応できる人員や体制がある大学に向いた選択肢といえます。

SeciossLink(セシオスリンク)のウェブサイト

株式会社セシオスが提供するSeciossLinkも、学認に対応したIDaaSです。SAML・OpenID Connect・OAuthによるシングルサインオンに対応し、学認のSP連携に使えるテンプレートや、教育機関向けのライセンスが用意されています。

学認への対応を前提に、大学・教育機関での利用を想定した機能構成となっている点が特徴です。学認連携を含めて統合認証基盤を整えたい大学にとって、候補の一つになります。

また、以下の記事では、大学に限らずIDaaS全般について、メリットや選び方、導入事例を詳しく解説しています。製品の比較を本格的に進める際の見取り図としてご覧ください。

まとめ

大学の統合認証基盤は、ID管理・IdP・SSO・多要素認証・学認という要素を組み合わせ、ばらばらだったIDとログインを一本化する仕組みです。

導入の検討では、まず構成の全体像を押さえることが出発点になります。そのうえで、学認連携が自動ではなくShibbolethによるIdP構築とフェデレーション参加を要する点に注意します。あわせて、学生の入学・卒業に伴うIDの大量発行・失効や非常勤講師のIDといった大学固有の運用、学外アクセス時の多要素認証をどう設計するかが要点です。

実現の手段は、オープンソースの自前構築・SaaS型の製品・SI委託に分かれます。自大学の人員体制・学認要否・既存システムとの連携の多さを整理して、予算と運用の手間のバランスで選ぶとよいでしょう。各製品の学認対応やSAML 2.0連携、プロビジョニングの対応状況は、資料で具体的に見比べて、自大学に合う方式を選んでください。

料金や機能は各社の資料でまとめて比較できます 【無料】IDaaS(ID管理システム)の資料を
一括ダウンロードする

よくある質問(FAQ)

Q. 統合認証基盤とは何ですか?

A. 統合認証基盤とは、学生・教職員が使う複数のシステムのIDとログインを一つにまとめ、本人確認(認証)とアカウント管理を集約する基盤です。教務システムや大学メール、図書館の電子リソースなどのログインを一箇所に集め、利用者は一度の認証で複数のサービスを使えるようになります。ID管理・IdP・SSO・多要素認証・学認(GakuNin)といった機能の組み合わせで実現します。

Q. 統合認証基盤とIDaaSは何が違うのですか?

A. 統合認証基盤は大学が実現したい「仕組み・状態」を指すのに対し、IDaaSはその仕組みをクラウドで提供する製品・サービスの一形態です。統合認証基盤はオープンソースの自前構築やSI委託でも実現でき、IDaaS(Identity as a Service)はその選択肢の一つとして、ID管理・SSO・多要素認証などを月額で利用できる形にまとめたものです。

整理すると、「統合認証基盤を作る手段」の一つとしてIDaaSがある、という関係になります。

Q. 統合認証基盤とシングルサインオン(SSO)は同じものですか?

A. 統合認証基盤とSSOは同じではなく、SSOは統合認証基盤を構成する機能の一つです。SSOは一度のログインで複数システムを使えるようにする仕組みで、統合認証基盤はそこにID管理(アカウントの一元的な発行・失効)やIdPによる認証、多要素認証、学認連携などを加えた、より広い仕組みを指します。SSOだけでは、学籍データと連動したアカウント管理や学認への参加までは実現できません。

Q. 学認対応のIDaaSを使えば、Shibbolethを自前で立てずに学認へ参加できますか?

A. 学認に対応したIDaaSを選べば、自前でShibbolethサーバーを構築・運用しなくても、学認のIdP機能を製品側でまかなえる場合があります。学認はShibbolethを使ったフェデレーションのため参加にはIdPが必要ですが、学認のIdPに対応した製品を使えば、その部分を製品で代替できます。

ただし対応状況は製品によって異なり、いずれの場合もテストフェデレーションでの動作確認を経て運用フェデレーションへ参加する工程は必要です。製品選定の際は、学認のIdP機能に対応しているか、別途Shibbolethを立てる必要があるかを確認しておくと、工数の見積もりがずれにくくなります。

Q. 情報システム部門の人員が少ない大学でも統合認証基盤は導入できますか?

A. 人員が限られる大学では、構築・運用を自前で抱え込まずに済むSaaS型のIDaaSが現実的な選択肢になります。学認対応や多要素認証、人事・学籍データと連動したアカウントの自動管理(プロビジョニング)が製品側に用意されているため、少人数の体制でも運用しやすくなります。

一方、オープンソースの自前構築は継続的な設定変更やアップデートに対応できる体制が前提となります。人員に余裕がない場合は、SaaS型やSI委託(外部のシステム開発会社への委託)と比較して検討するとよいでしょう。

Q. 統合認証基盤の導入にはどのくらいの期間がかかりますか?

A. 統合認証基盤の導入期間は、構成(自前構築かSaaS型か)、連携する既存システムの数、学認対応の要否によって大きく変わり、一律の目安を公開情報で示すのは難しいのが実情です。特に学認へ参加する場合は、テストフェデレーションでの動作確認から運用フェデレーションへの参加という段階を踏むため、その分の期間を見込む必要があります。

一般的な傾向として、SaaS型の製品は比較的短期間で始められ、学認への参加やオープンソースの内製・外部委託は、設計・構築や接続試験の工程が増えるぶん期間が長くなります。

SaaS型の製品は、自前でサーバーを構築する方式より短期間で導入しやすい傾向があります。スケジュールを組む際は、教務システムなど既存システムがSSOの標準規格(SAMLなど)に対応しているかを早めに確認しておくと、見積もりのずれを抑えられます。

統合認証基盤・ID管理システムの料金・資料を一括チェック

MCB FinTechカタログでは、大学の統合認証基盤に使えるSSO・多要素認証・ID管理サービスの最新資料を無料で一括請求できます。学認対応やSAML連携、プロビジョニングの対応状況を見比べられます。

料金や機能は各社の資料でまとめて比較できます 【無料】IDaaS(ID管理システム)の資料を
一括ダウンロードする

MCB FinTechカタログに掲載しませんか?

MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。

監修者

マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト

松嶋真倫

都市銀行にて金融実務を経験後、暗号資産関連スタートアップの創業期に参画し、市場分析・業界調査に従事。2018年にマネックスグループ入社。以降、ビットコインをはじめとするデジタルアセットからマクロ経済環境まで、金融市場を横断した調査・分析および情報発信を担う。FinTech・次世代金融領域のリサーチ統括、各種レポートや書籍の執筆、日本経済新聞など国内主要メディアへのコメント・寄稿、イベント登壇などを行う。2021年3月より現職。
記事内でご紹介している製品・サービスは監修者が選定したものではなく、編集部が独自に選定したものです。
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。

関連記事

新着記事