≡

• HOME
• ソリューション
• 製品情報
• 導入事例
• イベント情報
• 企業情報
• リクルート
• 

統合認証基盤（学校法人明治大学 様）

37,000名もの大規模なアカウントを管理する明治大学の認証基盤
悩みや課題も多かったID管理やシステム連携を短期間で“最適化”できたその理由

大規模総合大学の代表格 - 明治大学。以前より独自に作り上げた認証基盤で各システムへの連携や認証ネットワークの環境を利用しているが、運用における悩みも多い。 現状分析をしっかりと実施し、改善策を検討した結果、たどり着いた結論は「足し算」ではなく「引き算」の考え？

国内屈指の総合大学

国内有数の学生数を誇る明治大学大学本部は都内の駿河台、御茶ノ水地区にある。周辺はパリの文教地区になぞらえ“日本のカルチエ・ラタン”と呼ばれるほど、 多くの文化・文教施設が集積されている。2016 年1 月に創立135 周年を迎えたこの歴史ある学び舎は「駿河台キャンパス」、「和泉キャンパス」、「生田キャンパス」を 有し、さらに近年、第四のキャンパスである「中野キャンパス」も開設された。都内に複数キャンパスを持ち、学部や大学院及び多くの研究機関を展開している明治大学は まさに“都心型”ともいえる総合大学である。
新システム稼働開始のお忙しい中、明治大学ご担当部門様に今回のシステム導入の背景や特徴などをインタビューさせていただいた。

改修前の学内連携システムの状況

明治大学では中高、大学、大学院の学生ならびに教職員、嘱託職員を含めて、約37,000 名のアカウントが存在する。大規模キャンパス内には数多くのシステムがあり、 それらは人事基本システムと学籍システムの情報を集約した基幹データベース（基幹DB）を源泉として連携されている。
改修前においてこれらをまとめるシステムは、学内ウェブサービスへのシングル・サイン・オン（SSO）を実現する「共通認証システム」と、学内の各サービス用の アカウントを発行する「アカウント管理システム」の二つが存在していた。学生や教員が利用する“Meiji Mail”のアドレスなどもこの「アカウント管理システム」から 登録される仕組みであった。二つのシステムには基幹DBから専用のビューを用いてデータを取りこみ、独自に開発されたプログラムによりアカウントを生成していた。 また、各キャンパスには各種LDAPサーバならびにWindows Active Directory（AD）等が、学内システムにはローカルのデータベース（ローカルDB）で管理されるシステムが 存在していた。一方、図書館システム等は基幹DBと連携しているが、学外のユーザアカウントは手動で作成され、システム独自の画面からパスワード変更がなされていた。
すなわち、既存システムは独自の作り込みにより連携されており、それぞれのシステムが連携参照する先、保有するID やパスワード、パスワード変更の為のWeb 画面、 反映同期の仕組みなどは個々に開発されている状況であった。

乱立した学内IDとパスワード

利用者側の視点から見ると、学生・教職員は利用対象のシステムに合わせて、複数のIDとパスワードの組合せを使用しており、その利便性が問題となっていた。 また、既存の共通認証システムではクラウドサービスに対応しておらず、将来におけるシステム増などに対しても不安を抱えていた。さらにアカウントのライフサイクルや パスワードポリシーに関してもシステム毎に異なっていた為、全学で統一したポリシーで運用し、安全性を強化する必要があった。
こうした課題が学内で検討され、新たな統合認証基盤としての現行のシステムの改修に向けたプロジェクトがスタートした。プロジェクトでは、 プロトタイプの構築に始まり、慎重に検証を重ねながらシステム設計・テストが進められた。

将来性のある統合認証基盤に向けて

現行のシステム課題を解決するためには、利便性向上のためのSSO 導入に加え、学内のアカウントを統合的に管理するID 管理システム（IDM）が新たに必要であるという 結論に達した。SSOシステムにおいては日本ヒューレット・パッカード社の“IceWall SSO”が、IDM においてはエクスジェン・ネットワークス社の“LDAPManager”が 採用された。構築導入の全体取り纏めとSSOシステム構築をSCSK 社が、IDMシステム構築をアクシオが担う体制で臨んだ。両社とも豊富な構築経験・導入実績を有しており、 お互いの強みを生かしあう協業体制で臨んだ。

「足し算ではなく引き算」の見極め

今回アクシオが提案した内容は従来の提案型とは全くアプローチが異なっていた。一般的には要件を満たすための要件定義を実施し、実現したい動作や機能要件を精査し、 それを実現するための開発要素（プログラム作成）が盛り込まれて開発設計を進めていく場合が多い。利用者のIDやイベントに関連する属性の更新や変更のロジック、 申請や承認のワークフロー開発と絡めて、顧客の運用スタイルに合わせる上で、製品以外での開発要素は欠かせないことでもある。すなわち製品機能でできないことを “足し算する”発想である。
インタビューにおいて、「私達には長く使っていくシステムの将来性として、開発コスト低減や共通化、標準化推進の狙いがありました。したがってできる限り、 特別な作り込みをせず製品の機能で共通的なシステムを目指すべきと判断し、検討を進めました。」とご担当者は話す。
独自開発を減らす、まさに“引き算する”という発想。ここで重要なのは製品機能でどこまでを実現でき、理想のシステムに近づけるのかを見極めることである。 設計の検討段階においては、アクシオから要件と製品の持つ機能を照らし合わせ、実現の可否を判断し提案をおこなった。数多くの国内外のID 管理製品を扱い、 製品の特長を熟知しているからこそ、あえて“足し算をしない”という確かな製品選択の“目利き”が活かされる提案となった。こうして新たな統合認証基盤では LDAP Manager の機能に集約し、共通化と最適化が図られた。アクシオのプロジェクト担当も以下のメリットが出たと話す。
「要件定義と設計がしっかりとまとまってくると、構築作業に関しては従来必要とされるプログラムの開発・作成が無い分だけ、非常に短期間で 実施できました。その分でテストや移行、本稼動に時間を費やすことが出来たと感じています。」

管理の姿が見えてきた

今回の統合認証基盤ではこれまでのID 体系を踏襲しつつ、新たな仕組みづくりを実現した。さらに、将来的なID 体系の見直しの可能性を考慮し、 全体的なログインID の洗い替えも可能な仕組みとした。「最終目標は学内で利用されているアカウントを一つに統合することですが、今回のプロジェクトでは その前段階の準備ができたと思っています。 パスワード連携もIDMから最新のパスワードが各システムに連携できるようになり、個別システムでパスワード変更機能を 準備する必要はなくなった。また導入のSSOシステムは、クラウド上とアイデンティティ情報をやり取りするSecurity Assertion MarkupLanguage （SAML）連携を サポートする、いわゆる”フェデレーション“も準備されており、クラウドサービス上のシステムとも認証連携が可能となる。「学内だけでなく学外においても SSO 環境を維持して、将来における必要なシステムを一元的な認証基盤のID 体系配下で運用できる基盤を整備でき、将来の管理の姿が見えてきました。」と話す。

お客様の声

「プロジェクトでは大変お世話になりました。メンバーのみなさまには、豊富な経験と十分な製品知識に基づくご提案のみならず、本学の環境 に合わせて慎重に調査を重ねていただくことにより、正確な設計と構築を実現していただきました。またリリース直前での急な仕様変更などに も迅速に対応していただき、おかげさまでリリース後は大きなトラブルもなくスタートすることができました。」ご担当者からも若手の励みになるお言葉をいただいた。

関連製品

ユーザプロフィール