Comments
Description
Transcript
2010年度学術情報研究センタープロジェクト報告書 2011/3
2010年度学術情報研究センタープロジェクト報告書 2011/3 戦後障害児教育・福祉実践記録映像のデジタル化 中学校における校内⾼速ネットワークの管理・運営に関する研究 教育資料館特別展・企画展の恒例化と出張展⽰等の試⾏ 有機化学３次元デジタル教材の開発 SSO(Single Sign On)の試⾏ 2010年度 プロジェクト報告 学術情報研究センター研究報告 ■プロジェクトの概要 テーマ：戦後障害児教育・福祉実践記録映像のデジタル化 研究組織： 玉村公二彦 学校教育講座 実践映像のデジタルアーカイブの作成 越野和之 学校教育講座 戦後特別支援学級実践資料の収集と整理 根來秀樹 学校教育講座 医療的立場からの解説 井上洋平 学校教育講座 発達心理学の立場からの解説 小嶋照子 附属小学校 特別支援学級実践の総括的検討 佐野直樹 附属小学校 特別支援学級の実践の検討 プロジェクトの目的： 戦後における障害児教育・福祉、障害児保育、障害者福祉関係映像のデジタル化につい ては、2008 年度以降の本プロジェクトによって、『光の中に子どもたちがいる』『続光の中 に子どもたちがいる』『光の中に子どもたちがいる総集編』 『夜明け前の子どもたち』『保育 元年』 『続保育元年』 『続々保育元年』を関係者の了解のもと、デジタル化を行い、DVD を 作成した。その後、継続して資料の探索を行った結果、滋賀県の重症心身障害児施設にお いて、『夜明け前の子どもたち』未使用フィルムを中心とした多くの未公開の映像が発見さ れた。また、京都府での資料調査によって京都府立与謝の海養護学校等での教育実践の記 録フィルムが発掘された。本プロジェクトでは、それらの未使用フィルム、本学附属特別 支援学級の初期映像などを関係者の了解の下、デジタル化し、DVD として保存する試みを 行うものである。 ■実施状況と課題 １．びわこ学園、近江学園、あざみ寮・もみじ寮などの映像資料の発掘・データ化につい ては、『夜明け前の子どもたち』未使用フィルムのデジタル化、「1 次元の子どもたち」 をはじめとする知的障害児施設近江学園の初期のフィルムのデジタル化をおこない、記 録を DVD として作成した。 ２．京都府立与謝の海養護学校（1970 年開校）の開校 10 年記念映画「ぼくらの学校」の 未使用フィルムテレシネし、DVD を作成した。また、与謝の海養護学校の開校以後の 学校紀要を PDF 化し、記録として蓄積するとともに、DVD を関係者に配布した。 ３．大阪市立貝塚養護学校の実践資料の PDF 化に着手した。 ４．本学附属小学校特別支援学級（19 クラス）の実践フィルムについては、8 ミリフィル ムを中心として、そのデータ化を行った。 ■今後の課題 １． 滋賀県関係の資料のデータ化の進展を受けて、時系列にそくした編集や解説を行うこ とが課題である。映像資料を関係者の間で、検討する場を持つことが必要であるが、幸 い、2 年後はびわこ学園の創立 50 周年でもあり、それにむけた素材を提供できればと 考えている。 ２．京都府立与謝の海養護学校の実践の記録映画については、ほぼ作業は終わることが出 来たと考える。しかし、京都府が障害児教育の広報用フィルムとして作成した「人」 （16 ミリフィルム）があることがわかったが、その現物を確認するまでにはいたっていない。 ３．学校や施設の実践記録については、デジタル化は着手したばかりであり、今後も進め ていく必要がある。 ４．映像資料をどのように、アーカイブとして蓄積し、公開するかについても検討するこ とが課題となった（図書館での DVD コレクション化など）。 ■特記事項 映像として残すのみならず、公開する場合の倫理的な問題も解決する課題である。今後 は、貴重な資料のデジタル化と公開に向けて、外部資金の獲得も含めて学校や施設等との 連携などを進めていきたい。 中学校における校内高速ネットワークの管理・運営に関する研究 西仲則博 大室敦志 谷口義昭 井村 健 松田孝史 附属中学校 附属中学校 附属中学校校長 附属中学校副校長 附属中学校 １．はじめに 平成 21 年度補正予算で行われた「スクール・ニューディール」構想関係では、（1）学 校耐震化の早期推進、太陽光パネルをはじめとしたエコ改修の拡大、（2）学校 ICT 環境 整備の二本柱で実施された。特に ICT 環境の整備については、1.地上デジタルテレビ(電 子黒板を含む)の整備、2.学校のコンピュータ、校内 LAN の整備（公立学校）で、校内LA 1） N及び超高速インターネット接続等の環境整備の推進が行われている。 文部科学省（2011） の調査によると中学校の PC 教室のうち、97.9%が LAN の整備がなされて、普通教室 LAN 2） 整備率 においても平成２０年度 60.8%に対して、平成２１年度は 69.0%と LAN の整備 が学校教育の中で、急速に進んでいることが示されている。あわせて、地域センター（教 育センター等）を中心に各学校を結ぶ、教育用イントラネットの構築を推進されている。 ネットワーク環境がこうのように教育現場で整ってきている中、その管理・運営につい ては、充分に機能しているとは言い難い現状である。ICT を活用した授業の日常化が進行 していく中で、校内 LAN はその基盤を担うものである。システムダウンや不安定性は授 業の進行において大きなダメージを与えるものである。そのため、ICT を活用した日常の 授業でのシステムダウンや不具合などを回避するためにも、日常のメンテナンスを確実に 行うことが、益々重要視される。しかし、運営・管理には専門的な知識が必要なため、京 都市 3）のように専門的な知識を有した「校内 LAN サポーター」の制度を設けておられる ところもあるが、一部の教師が、授業や校務以外で行っている場合が多い。または、整備 した後にもコンピュータや周辺機器、サーバ等の保守管理（メンテナンス）など引き続き 運用のための経費（ランニングコスト）が必要であるため、予算上経費をかけることがで きずに、設定時のままの場合もある。このような校内 LAN の管理･運営の現状に対して、 本研究では、できる限り低予算で、校内 LAN の管理・運営行うために、GNU General Public License (GPL)の元配布されている、サーバー、ネットワーク、アプリケーションを監視 するためのソフトウェアである zabbix の導入を提案する。 また、附属中学校の校内 LAN の高速化に伴い、基幹 HUB 等の整備も行った。 ２．管理ツール zabbix の検討 総務省がまとめた「校内 LAN 導入の手引～校内 LAN モデルプラン集～」4）では、校内 LAN を構築後、必要な管理業務としては以下のものが挙げられている。 ・プログラムレベルアップモジュール適用作業 ・バックアップ作業 ・システムセキュリティアップ作業（セキュリティパッチ適用、パターンファイル更新） ・利用者年次更新処理（ユーザアカウント作成・削除作業) ・キャッシュシステム調整作業 これらの業務は、定型的であるが、多くの PC や何台かのサーバーがある状況下では、管 -1- 理者の作業負担は大きい。また、アプリケーション、サーバー、ネットワーク機器の日頃 からの監視で、障害の発生への迅速な対応や、障害の発生になる前の兆候をつかむことに より、システムダウンの回避行動をあらかじめ取ることができる。このような、システム として、オープンソース・ソフトウェアであり、アプリケーション、ネットワーク、およ びサーバーを監視するソフトウェアである Zabbix の導入を行った。 5） Zabbix の特徴 は、 * オープンソース・ソフトウェア * 様々な OS のサポート * SQL データベースによるデータ管理 *分かりやすい Web インターフェース * 簡単に作成できるグラフ機能 * Unix/Windows の両プラットフォームに対応した高性能なエージェント * エージェントレスでも行える簡易監視機能 * SNMPv1、v2、v3 対応 * 情報サービスに対応した SLA 機能 であり、Linux 上で動く（LAMP 上で動く）ことから、コストがサーバー用ＰＣのみにな る。また、そのＰＣの要求スペックも 、ＣＰＵ Pentium(Pentium4 以上を推奨)ディスク 空き容量: 10MB (100MB 以上を推奨)搭載メモリ: 64MB (128MB 以上を推奨)であり、高 価なものを必要としないことも大きい。 多機能な監視ソフトであり、監視のレポートはわかりやすいグラフで表示することがで き、障害発生時の通知が自動で行うことができる。SNMP のサポートや多くの OS をサポ ートしているエージェントを各ＰＣやサーバーにインストールすることにより、ネットワ ークに繋がっている殆どの機器の状態を把握することができる。エージェントなしでも、 簡易な監視ができる。 しかし、Zabbix のシステムの構築を行うのには、Linux の知識が要求されるため、単に Download をして、すぐに使えるものではない。LAMP 上で動くため、サーバーとして Linux のインストールから行わなければならない。Linux は Windows のようにインストール環境 が整っていないが、その中でも、インストール環境が整備されていて、解説書も多く出て いる CentOS5.3 を用いた。Zabbix のインストールには、MySQL データベースの設定ファ イルの変更や Apache Web サーバの起動後、PHP の設定など行った後に、Zabbix 画面の 設定になる。 http://www.zabbix.jp/や http://thinkit.co.jp/free/article/0611/19/1/等のネット情報 をもとに構築を行った。 ３．今後の課題 ランニングコストや、情報の多さ、それらを見やすくするための工夫がされていること から、Zabbix を運営・管理を行う上での管理ツールとしての用いることは、大変有意義 である。また、他社から iphone や Android 端末上で Zabbix のクライアントして動く MoZBX があり、Zabbix 上の情報が端末で容易に確認できるのである。Zabbix の可能性は 大きいが、そのシステム構築の難しさがネックである。容易に構築できる方法の研究とさ らなる実践的な研究が必要である。 1）「e-Japan 重点計画 2004」（平成１６年６月１５日ＩＴ戦略本部決定）等に基づき、平成１７年度までに各学級の授 業においてコンピュータやインターネットが活用できる環境を整備することを目標として、整備が行われた。 http://www.mext.go.jp/a_menu/shotou/zyouhou/05060401.htm 2）「普通教室のＬＡＮ整備率」は、全普通教室数のうち、ＬＡＮに接続している普通教室数の割合としている。 3）http://www.mext.go.jp/b_menu/houdou/20/07/08072301/001/007/002/008.htm による 4） http://www.soumu.go.jp/joho_tsusin/kyouiku_joho-ka/pdf/index_01.pdf による 5） http://www.zabbix.jp/modules/main0/index.php?id=3 による -2- 平成２２年４月２７日 学術情報研究センター研究開発部門プロジェクト研究 「教育資料館特別展・企画展の恒例化と出張展示等の試行」 研究報告書 申請代表者 山岸 公基 ① プロジェクトの名称 「教育資料館特別展・企画展の恒例化と出張展示等の試行」 ② プロジェクトの概要 本学の公開施設として、教育資料館を利用する展示を４か年度にわたり実施してきたノ ウハウを活かし、教育資料館展示機能の充実とその活用を進め、 「教育資料館 夏の特別展」 としての恒常化を目指した。補助期間終了後も継続する大学院「地域と伝統文化」教育プ ログラムの実践とタイアップする形で、学外（本学近傍の新薬師寺）に展示作品を求め、 学校教育の教科を横断する内容により、中学生・高校生、さらに地域も巻き込んで教育資 料館、ひいては本学を活性化させることにつとめた。 ③ 実施状況と得られた成果 ・特別展「仏の中にこめられた想い」展 ７月２６日～７月３１日（６日間） 平成２２年度は、平成２１年７月２６日から７月３１日にかけて「仏の中にこめられた想い」展 （入場者のべ５６０名）を教育資料館で実施した。 「仏の中にこめられた想い」展では、院「伝統文化発信法Ⅱ」の成果発表という形をとり、新 薬師寺より四天王立像納入品（特に印仏）、地蔵菩薩立像納入品（宋銭）、薬師如来坐像など 美術工芸文化財の現物をお借りし、本学絵画記録保存研究室における研究成果や所蔵の古 写真とあわせ展示した。受講大学院生にとっては、教員の目配りのもと研究成果や展示案を 自ら企画立案・実行する苦労と達成感とを体感できる機会となった。昨年の展示より期間は短 縮し６日間となったが、入場者数は昨年に匹敵し、関係各層にとって意味・価値あるものとなっ たと自負している。本学絵画記録保存研究室における研究成果や図書館保管古写真の意 義・価値もこの展覧会を通じ再確認された。 ④ 課題、その他 教育資料館展示ケースの一部の不具合からセコムの導入を余儀なくされたため、特別展 以外の企画展の実施や、教育資料館の展示ケースを附属校園に持ち込んでの出張展示・ワ ークショップ等の試行は今回断念せざるを得なかった。今後特別展・企画展を恒例化して ゆくうえに設備面で大きな課題が残った。 学術情報研究センター研究報告 ■プロジェクトの名称 有機化学３次元デジタル教材の開発 研究組織：○山崎祥子 理科教育講座 山辺信一 教育実践総合センター ■プロジェクトの概要 高校化学、大学学部の有機化学の学習用デジタル教材を作成した。中学校・高校向けの化学教材は、 いくつか例があるが、その内容は各論的で高校化学の基礎的有機化学および大学学部初級用の系統的な 教材は比較的少ない。中には３次元で表示しているものの、反応経路の稚拙な表現のものもある。反応 の正確なポテンシャル面に基づく 3 次元分子モデルの構造および化学反応による構造変化について視覚 化されたデジタル教材を作成し、微視的レベルでの学習の理解を助けることは重要と考える。特に、化 学反応では遷移状態(TS)の構造が鍵であり、計算シミュレーションのデータを蓄積しており、それを利 用したデジタル教材を提供することを行った。 有機化学の教科書に記載されている古典的な反応のうち、本学で計算化学を使った詳細な反応経路の 追跡を行った。この研究成果を用いて、本格的な３次元表示の本学独自の教員養成大学用有機化学およ び高校教員のためのデジタル教材の素材集を作成し、学内共同パソコン X-ドライブ上に学内公開した。 また、有機化学実験の目で見る基本操作についてのデジタル教材を作成した。 ■得られた成果又は実施状況 有機化学の古典的な反応である Beckmann 転位（図１）, Friedel-Crafts 反応（図２）, ピナコール 転位, ベンゾイン縮合/Cannizaro 反応, ベンジジン転位について、計算化学の手法を用いてモデル反応 系での経路を求めた。この研究成果を有機化学の初学者でも理解できるモデル教材として編集・加工・ 学内公開した。 Me A two-step process with a -type complex + H+(AcOH)3 O H 7A [0 kcal/mol] C N Me 9A [-30.0 kcal/mol] C5 1.819 Å (1.749) C4 2.498 Å (2.513) C1 C4 N2 1.658 Å (1.660) 1.762 Å (1.737) O O3 C O C O O O 1.769 Å (1.778) Me: CH3, メチル基 AcOH: CH3CO2H, 酢酸 1.739 Å (1.738) O ‡ = 436.4 icm-1 C O 8A (TS1) [+19.2 kcal/mol] C 水素原子 C O ‡ = 175.4 icm-1 C 1.743 Å (1.693) C O C 1.835 Å (1.910) O 1.839 Å (1.845) 1.720 Å (1.719) O3 C 1.519 Å (1.503) 2.056 Å (2.076) C C 1.719 Å (1.771) O C C5 N2 1.877 Å (1.934) C1 O Me C N Me + (AcOH)3•H2O HO C N Me 10A (TS2) [-18.4 kcal/mol] Me + (AcOH)3H+ 11A [-23.5 kcal/mol] H O Me Me C N H + (AcOH)3 12A [-53.8 kcal/mol] 図１. Beckmann 転位の３次元構造。 小数点以下３桁の長さはオングストローム(Å)単位。1 Å = 10-8 cm。 化学反応では遷移状態の構造が鍵である。計算化学に基づいた反応経路による３次元モデルより、必 要な部分を引き出して、授業、講演に自在に編集して使用することができる。 Cl15 Cl15 Cl11 2.206Å Al10 Cl14 Cl14 Al10 Cl11 ‡ = 141.70 icm-1 2.288Å 2.408 Å 2.430Å ‡ = 153.96 icm-1 2.708Å Cl9 2.334Å H5 H4 H4 Al8 O3 C2 Cl13 H5 1.965Å C1 C2 H22 H6 Cl7 C16 H24 H23 Cl12 ‡= 84.16 C17 C18 O3 C1 1.743Å H6 2.705Å 2.670 Å H24 H22 H26 C18 H25 Cl13 3.745Å 3.818Å C19 C20 Cl9 Al8 Cl7 1.854Å 1.866 Å icm -1 2.233 Å 2.214Å 2.610 Å 2.602Å TS1[ac] H26 Cl12 C16 C20 C17 C21 C21 H23 TS2[ac] C19 H27 H25 H27 図２. Friedel-Crafts 反応の２つの遷移状態の３次元構造 また、有機合成実験の１連の基本操作、反応、精製、スペクトル測定などについての視覚教材を作成 した（図３） 。 実験の流れの一例（その１） 0℃の状態で、試薬を フラスコに加える。 オイルバスで加熱還流を 反応処理後減圧下濃縮 行い、試薬を反応させる。 する。 実験の流れの一例（その２） NMRスペクトルを 測定する。 粗生成物を、カラム クロマトグラフィーで 精製する。ＴＬＣ, Rf カラム後減圧下濃縮 する。色、形状。収量、 収率。 図３. 有機合成実験の操作例 これらの教材の、有機化学分野の授業での実践利用を通じて、有機化学の反応の姿や実験操作を視覚 的に理解でき、興味・関心を喚起し、授業効果を上げることができる。 ■課題 有機化学の授業でデジタル教材を利用する。この際、学生の視覚への訴え方と彼らの内容の理解度の 相関関係を吟味する。計算シミュレーションのデータを用いて作成したデジタル教材内容の評価により、 改良を加えていく。 さらに種々の結合交替を伴う化学反応の新規コンテンツ作成を行う。既に計算シミュレーションのデ ータのある有名な古典的反応、人名反応などの有機化学反応、例えば Grignard 反応、Aldol 反応、 Knoevenagel 反応、Kolbe-Schmitt 反応についてもデジタル教材のコンテンツユニットを作成し、公開 する予定である。 また、動画を交えた有機化学実験および安全対策についても視覚化によるデジタル教材を作成する予 定である。有機化学実験での予習として教材利用を試行し、改良を加える。 2010 年度学術情報研究センタープロジェクト 報告書 教育実践総合センター/学術情報研究センター 藤原公昭 課題 SSO(Single Sign On)の試行 目次 SSO(Single Sign On)の試行 .............................................................................................................. 1 課題 始めに ........................................................................................................................................................... 3 1. SSO を実現する技術[1]-OpenID .............................................................................................................. 3 1.1 OpenID による SSO ........................................................................................................................... 4 1.2 OpenID の取得.................................................................................................................................... 4 1.3 OpenID によるログイン ..................................................................................................................... 6 1.4 個人サイトの URL を OpenID の ID とする ...................................................................................... 7 1.5 OpenID の認証メカニズム .................................................................................................................. 8 1.6 OpenID 対応サイトの構築 ................................................................................................................ 10 2. SSO を実現する技術[2]-SAML と Shibboleth ....................................................................................... 12 2.1 OpenID と SAML の比較 .................................................................................................................. 12 2.2 SAML と Shibboleth ........................................................................................................................ 13 3. Shibboleth による認証システムの構築 .................................................................................................. 15 3.1 Shibboleth の基本動作 ...................................................................................................................... 15 3.2 フェデレーションとメタデータ ....................................................................................................... 17 4. Shibboleth に対応したサーバーの構築 .................................................................................................. 17 4.1 IdP の構築 ......................................................................................................................................... 17 4.1.1 ソフトウェアの構成と設定 ........................................................................................................ 18 4.1.2 スキーマ..................................................................................................................................... 19 4.1.3 Shibboleth-IdP XML ファイルの設定 ........................................................................................ 20 4.1.4 サーバー証明書のインストールと関連の設定 ........................................................................... 24 4.1.5 IdP のメタデータを作成し、フェデレーションに登録する ....................................................... 25 4.1.6 Shibboleth1.3 への対応 .............................................................................................................. 26 4.2 SP の構築 .......................................................................................................................................... 26 4.2.1 Shibboleth-SP のインストール .................................................................................................. 27 4.2.2 設定ファイルの編集 ................................................................................................................... 28 4.2.3 サーバー証明書の設定とメタデータの作成・送付 .................................................................... 28 5 奈良教育大学における Shibboleth-IdP、SP の設置 ............................................................................. 30 6. OpenAM と GoogleApps の連携............................................................................................................. 31 [email protected] October 27, 2011 1 6.1 OpenAM のインストール.................................................................................................................. 31 6.2 GoogleApps への登録........................................................................................................................ 32 [email protected] October 27, 2011 2 始めに 様々な WEB 上のサービスで ID とパスワードの入力を求められる。同じ組織で提供するサービスでは、 同一の ID/パスワードで認証されることが望ましい。さらに、サービス毎に ID/パスワードが要求される のではなく、関連するサービスに関しては、一回の ID/パスワード入力によって、一定期間、すべてのサ ービスが再度の ID/パスワードの入力なしに利用できることが望ましい。これを SSO(Single Sign On) という。 本学では、2011 年 1 月から学務情報システムの ID/パスワードが学内統合認証に統合され、財務・会計 関連の業務を除き、教職員・学生の ID/パスワードが統合された。概ね同じ ID/パスワードで学内の主な サービスにログオンできる環境が整ってきたが、SSO はまだ実現できていない。 ログイン SSO 使用前 e‐learning ログイン Web‐Mail ログイン 学務情報 ログイン どこかにログイン 図書館ポータル e‐learning Web‐Mail 学務情報 図書館ポータル 今後、SSO を実現することでさらに利用者の利便性を図っていきたい。今回、そのための調査作業を行 った。 1. SSO を実現する技術[1]-OpenID SSO とは、WEB 上のいずれかのサイトで、ID/パスワードにより認証を受けることにより、複数の WEB [email protected] October 27, 2011 3 サイトのサービスを連続的に利用できるようになることである。 SSO を実現するシステムにおいて、ID による認証を担当するシステムを IdP(Identity プロバイダー)、 WEB サービスを提供するシステムを SP(サービスプロバイダー)と呼ぶ。 現在、本学では個々の SP の候補として、WebMail、学務情報、図書館ポータル、グループウェア(Cyboze)、 e-learning(Moodle)などがある。これらのサービスと連携する IdP を構築することが課題である。 IdP と SP との連携の方式には、現在の業界では、SAML(Security Assertion Markup Language)準拠方 式と OpenID 方式が標準的である。本学で SSO を実現する手法として、国立情報学研究所(NII)の「学 認」に採用されている SAML が第一の候補であるが、一方で、民間の WEB サービスで採用され始めて いる OpenID による方式も、将来的には広まる可能性も大きく、双方について考察することとする。 1.1 OpenID による SSO 大学内の業務であれば、個人 ID は決まってしまう。著者の場合、fujiwara、学生であれば a105501 な どであり、メールアカウントとも連動している。他大学の場合は職員 ID がそのまま WEB サービスへの ID として用いられることが多いであろう。 他方、インターネット上のサービスへの登録 ID は個人名では重複があり得るので、最近ではメールアド レスを用いることが多くなっている。これは覚えやすくて便利であるが、一旦変更があれば、登録して あるすべてのサービスへの変更が発生する。また、同一のパスワードがすべてのサイトに記録されてい るので、漏洩の危険性も大きい。 OpenID では、個人の ID として、インターネット内でユニークな ID を提供する。その ID は URL (http://・・・・/)の形式であることが特色である。特に、その個人が管理しているインターネット上のサ イトの URL を使うことで「自然な個人 ID」を手に入れることができる。 たとえば、著者の場合、livedoor に blog を持っている。その URL は http://blog.livedoor.jp/dansesacre/1 であり、この URL を OpenID での ID として用いることができる。これは、恒常的にアクセスし、更新 しているサイトであるので記憶のための努力を必要としない、また、この URL 自体が著者の身辺記録(個 人を特定できない形ではあるが)であるため、著者自身の ID として他人の ID と紛れたりする心配のない ID である、という意味で「自然な」ID である。 なお、OpenID の用語では、ID の相当する URL を”Claimed Identifier”と呼び、特定のサイトとは結び ついていない URL も可能である。(以下では”Claimed Identifier”を単に”ID”と呼ぶ) 1.2 OpenID の取得 OpenID の取得は、 A: OpenID.ne.jp から取得する。http://www.openid.ne.jp/ 1 Claude Debussy "Danse sacrée et Danse profane"「神聖な舞曲と世俗的な舞曲」より [email protected] October 27, 2011 4 OpenID ファウンデーションのページから「アカウントの作成」を行い、ID を取得することができる (無料)。このときに作成される ID は、 http://<username>.openid.ne.jp/であり、ユニークな<username>を指定する必要がある。著者の場合、 取得できた ID は http://dansesacre.openid.ne.jp/であり、幸運にも個人 blog の ID と同じ、dansesacre を取得することができたが、これは OpenID が未だ普及していないことによるものかも知れない。 http://dansesacre.openid.ne.jp/ この<username>に希望通りのものが得られない場合、前述したように個人の管理するサイト(blog な ど)の URL を取得した ID と関連づけ(Delegate するという)、サイトの URL を OpenID の ID として 用いることができる。この仕組みについては、後述する。 B: OpenID に参加しているサービスサイトから ID を取得する。 著者は Livedoor に dansesacre というアカウントを持っている。この場合、特に申請しなくとも http://profile.livedoor.com/< ア カ ウ ン ト 名 > つ ま り 、 http://profile.livedoor.com/dansesacre が OpenID 用の ID として用意されている。 [email protected] October 27, 2011 5 http://profile.livedoor.com/dansesacre 1.3 OpenID によるログイン OpenID に対応する WEB サービスでは、そのサービス固有の ID によるログイン以外に、OpenID 用の ログイン機能が用意されていて、OpenID のマークが表示されている。 例えば、LIVEJOURNAL(http://www.livejournal.com/)では、以下のようなログイン画面となっていて、 http://www.livejournal.com/ OpenID マークのクリックによって、OpenID でのログイン画面に遷移する。 http://www.livejournal.com/identity/login.bml?type=openid [email protected] October 27, 2011 6 このように、ユーザー登録をしていないサイトに、ユーザー登録をすることなく、OpenID によってロ グインすることができる。但し、そのようなログインで受けられるサービスは当然正規のユーザーより は制限される。 また、Blog などでコメントの投稿に OpenID を要求するサイトもある。 http://www.y-mainichi.co.jp/news/17341/ 1.4 個人サイトの URL を OpenID の ID とする 1.3 の A(OpenID ファウンデーションから取得：著者の例では http://dansesacre.openid.ne.jp/)または B(OpenID 対応サービスから指定される：例 http://profile.livedoor.co/dansesacre)のいずれかの方法で 取得した OpenID をそのまま、3.2 で示した OpenID 対応サービスへのログオンに利用することは可能 である。ただし、このようにして得られた ID はアクセスすることのない URL なので記憶にとどめるこ とは難しい。前章で述べたように、個人が管理し、日常的にアクセスしているサイト(例えば個人の Blog) の URL を OpenID の ID として用いることができる。 具体的には、著者の管理する Blog ページ http://blog.livedoor.jp/dansesacre を OpenID の ID として用 いる 2 ためには、この URL を 3.1 で取得した OpenID (A: http://dansesacre.openid.ne.jp または B:http://profile.livedoor.com/dansesacre)と関連づける必要がある。 以下では、A：http://dansesacre.openid.ne.jp と関連づける例を示す。 そのために、Blog ページの HTML を編集し(これが可能であるために、個人が「管理している」ページ である必要がある)、以下の２行をヘッダー部分に挿入する。 http://blog.livedoor.jp/dansesacre/ のソースのヘッダー部は以下のようである。 <!DOCTYPE html PUBLIC "-//W3C//DTD これを「User-Claimed Identifier」という。一方 IdP から取得した ID(URL)を「OP Endpoint URL」 という。 2 [email protected] October 27, 2011 7 XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" id="ldblog-standard"> <head> ・・・ ・・・ここに以下の A または B の２行を挿入する ・・・ <title>日々の記録</title> </head> <body class="standard_blue standard_blue_2c index"><script type="text/javascript"><!— ・・・・ A：http://dansesacre.openid.ne.jp と関連づける場合、 <link rel="openid.server" href="http://www.openid.ne.jp/index.php/serve"> <link rel="openid.delegate" href="http://dansesacre.openid.ne.jp/"> B:http://profile.livedoor.com/dansesacre と関連づける場合は <link rel="openid.server" href="http://auth.livedoor.com/openid/server"> <link rel="openid.delegate" href="http://profile.livedoor.com/dansesacre”> いずれも、2 行目の”opened.delegate”に本来の OpenID の ID が記述され、1 行目の”opened.server”に、 その ID を発行したエージェントの用意する認証サーバーが記述される。つまり、認証は対応する ID を 発行した主体が行うことが示されていることになる。 1.5 OpenID の認証メカニズム OpenID と連携している WEB サービス(SP)にアクセスすると、OpenID の ID(URL)を入力するフォー ム(入力の箱)があり、そこに ID(URL)を入力する(1)。すると、その ID を発行したエージェント (OD=OpenID プロバイダー)の認証画面に遷移する(2)。そこで入力する ID/パスワードは OpenID を発 行したエージェント(OD)に登録した際に発行されたアカウントとパスワードである(3)。この ID/パスワ ードが OD において認証されれば、WEB サービスが開始される(4)。 [email protected] October 27, 2011 8 WEBサービス(SP) OpenIDプロバイダー 1:ID(URL)の提示 OpenID 連携 4:サービス開始 2:認証要求画面 3: ID/パスワード入力 他の WEB サービスで、すでに上の認証[(2)と(3)]が行われていれば、このプロセスは省略され、OpenID 連携しているサイト間では SSO が実現される。 上の例では、(1)で[AboutMe]へログインしようとして、OpenID の ID http://profile.livedoor.com/dansesacre を入力する。この ID は livedoor が発行したものであるので、利用者の PC には livedoor の認証画面が 表示される(2)。利用者は、この画面で、livedoor への ID/パスワードを入力する(3)。 認証が OK であれば、その結果は[AboutMe]のサイトに通知され、(4)サービスが開始される。 ここで重要なことは、OpenID の ID として http://profile.livedoor.com/dansesacre を使う場合、(2)の認証は必ず、その ID の発行エージェントである livedoor で行われることであり、WEB サービス側に livedoor での ID/パスワードが伝えられることはない、ということである。 また、このことにより、OpenID でのユーザー登録は OpenID プロバイダーのいずれか一カ所で行えば 良く、パスワードの管理が楽になる。 個人が管理するサイトの URL を OpenID の ID として用いる場合、そのサイトの HTML ファイルに記 述した link、例えば <link rel="openid.server" href="http://www.openid.ne.jp/index.php/serve"> <link rel="openid.delegate" href="http://dansesacre.openid.ne.jp/"> によって、OpenID ファウンデーション(Openid.ne.jp)によって(2)の認証が行われる仕組みになっている。 なお、利用者から見た場合の画面の遷移は、HTTP リダイレクトという手法によってブラウザーを制御 することによって行われているが、詳細は省略する。 [email protected] October 27, 2011 9 1.6 OpenID 対応サイトの構築 OpenID のアカウント(ID)でログイン可能なサイトを Relying Party(RP)という。RP を研究室の LINUX マシン上に構築してみた。このマシンは DNS 名 ga.nara-edu.ac.jp を持ち、FireWall 外からのアクセス ができる状態にしておく(HTTP 及び RAILS 用ポート 3000)。 OpenID の仕様(プロトコル)に準拠した各種言語のライブラリがオープンソースとして公開されている。 ここでは、Ruby 言語による OpenID を用いた。インストールの手順は「いますぐ使える OpenID3」に 従った。用いたソフトウェアとそのバージョンは以下の通りである。 Linux(CentOS-5.5) Ruby 1.8.6 RubyGems 1.3.1 Rails 2.0.2 Ruby-openid 2.0.4 指示通りのバージョンが存在しないものもあり、また、バージョンによりソフト間の連携がとれないこ ともあるので注意を要する。 Rails に含まれる WEB サーバーを指示通り起動し、 http://ga.nara-edu.ac.jp:3000/consumer にアクセスすると OpenID アカウントの入力画面が表示される。 http://ga.nara-edu.ac.jp:3000/consumer OpenID ファウンデーションが発行した ID(http://dansesacre.openid.ne.jp)を入力し「Verify」をクリッ クすると、OpenID ファウンデーションのページに導かれ、パスワードの入力を促される。 3 松岡浩平、技術評論社：http://gihyo.jp/dev/feature/01/openid [email protected] October 27, 2011 10 登録された ID(dansesacre)が示されるので、対応するパスワードを入力し、 「ログイン」をクリックする。 パスワードが正しければ、認証が成功する。このあと、利用者に以下の確認が求められる。 これは認証の結果(アカウント)を、筆者が用意した RP サイト(ga.nara-edu.ac.jp)へ通告して良いかの確 認であり、「認証状態を保持」すれば、以降この確認は現れない。「拒否」しなければ、認証されたアカ ウントが RP へ通告され、RP のサービス画面へと導かれる。 [email protected] October 27, 2011 11 2. SSO を実現する技術[2]-SAML と Shibboleth 2.1 OpenID と SAML の比較 はじめにも述べたように、OpenID のように WEB サービスを行うエージェント(SP)と ID の認証を行う エージェント(IdP)の間の連携(ID 連携という)の標準的な技術のもう一つが SAML(Securuty Assertion Markup Language)である。むしろ、歴史的には SAML が古く 2003 年、一方 OpenID は 2007 年に策 定された。SAML は政府機関・大企業での採用が多く、OpenID はインターネットでの消費者向けサー ビスのニーズから生まれた4。 http://www.nri.co.jp/opinion/it_solution/2009/pdf/IT20090804.pdf OpenID、SAML いずれも「Assertion：アサーション」と呼ばれる「確認書」の形式と交換手順を決め たものであり、利用者の認証のみならず、利用者の属性や資格などの情報を利用したサービスの提供を 行うことができる。このアサーションの形式が、OpenID では Tag-Value 形式、SAML では XML と異 なっている。この形式の相互変換を行えば、OpenID と SAML の相互連携も可能である。 OpenID と SAML の運用面での大きな違いは、WEB サイトにアクセスしてきた利用者の認証をどの IdP で行うか(Discovery という)が、SAML の場合はあらかじめ設定されていることに対して、OpenID では 利用者の ID によって自動的に IdP が決まるため、設定の必要がないことである。このことによって、 インターネットのサービスを OpenID 連携に簡単に追加できるようになっている。一方、SAML では ID 連携を行う範囲をあらかじめ設定しておく必要があり、一般にフェデレーション(連合)という枠組みが設 定される。「学認」はそのような大学間認証連携のフェデレーションである。 4 「アイデンティティ関連技術の潮流」崎村夏彦：野村総合研究所 http://www.nri.co.jp/opinion/it_solution/2009/pdf/IT20090804.pdf [email protected] October 27, 2011 12 2.2 SAML と Shibboleth SAML は文字通り言語(Markup Language)と抽象的な手順の仕様であり、Shibboleth はその実装ソフト ウエアと位置づけられる。Shibboleth 自体は、個々のアプリケーションソフトウェア、具体的には(IdP と SP)、と OS との間に介在する「ミドルウエア」と呼ばれる階層のソフトウェアである。Shibboleth を採用すると言うことは、具体的には各大学で Shibboleth を取り込んだ IdP と SP を構築するという作 業になる。このようなシステムが構築されることで、他大学のサービスを本務校の ID/パスワードで利用 することが可能となる。 WEBサービス(SP) 認証サーバー（IdP) 1:他大学サービスへ アクセス Shibboleth連携 4:サービス開始 2:IdPリスト提示 Discovery Service= 各大学IdP のリスト 3:奈良教IdPを選択し認証 OpenID と大きく異なることは、認証を行う IdP を選択する画面が現れることである。 「学認」では以下 のように、所属校を選択するようになっている。 [email protected] October 27, 2011 13 「学認」Discovery Service ここの選択肢に「奈良教育大学」を加えることが当面の目的である。 たとえば、京都大学を選択すると、以下のように京都大学の Shibboleth 対応 IdP の画面が現れ、京都大 学のアカウントでログインできる。 京都大学 Shibboleth IdP の認証 [email protected] October 27, 2011 14 3. Shibboleth による認証システムの構築 Shibboleth による認証の動作を、具体的に説明する。 3.1 Shibboleth の基本動作 1) 利用者(自分)は、SP にアクセスし、 「Shibboleth 認証(学認)」を選択する。 2) SP は、この利用者のブラウザーを DS(Discovery Service)にリダイレクトする。 SPにアクセス SP: http://ci.nii.ac.jp/ 国立情報学研究所 CiNiiサービス 1) Shibboleth認証を選択 2) 所属校 （のIdp)を 選択する DS: http://upki‐ds.nii.ac.jp/ds/・・ へリダイレクトされる この動作は、SP に組み込まれた Shibboleth の SessionInitiator によって行われる。 (SP の/etc/shiboleth/shibboleth2.xml において <SessionInitiator type="SAMLDS" URL="https://upki-ds.nii.ac.jp/ds/・・" />) 3) DS で自分の所属校を選択することで、(SP の Session Initiator を一旦経由して)所属校の IdP にリダ イレクトされる。このとき DS からブラウザーにクッキーが渡され、次回以降 DS では選択画面が表示 されることなく、直接所属校の IdP にリダイレクトされる。 所属校のIdで ログイン DS: https://upki‐ds.nii.ac.jp/ds/・・ 奈良教育大学が あるとする 所属校を選択して 所属校の認証画面 (IdP)へリダイレクトされる 所属校での ID/Passwordを 入力する 所属校の ID/Passwdでログイン IdP: https://shibboleth‐idp.nara‐edu.ac.jp/ [email protected] October 27, 2011 15 4) 所属校の IdP 画面で、所属校の ID/Password を入力し認証を受ける。認証が OK であれば、利用者 のブラウザーを経由して、元の SP にリダイレクトされる。 このとき、 「認証が所属校の IdP で OK と認められたという事実」および「利用者に関する属性情報」が SP に伝えられる。これらの情報をアサーション(Assertion：「認証情報」)という。 また、認証が OK であった場合は、IdP からブラウザーにクッキーが渡され、次回からは ID/Password の入力画面がパスされる。 5) IdP から(ブラウザー経由で)SP はアサーションを受け取り、SP のサービスポリシーとつきあわせた 上で(利用者資格の判定など)、SP サービスへのアクセス承認を行い、OK であれば、利用者のブラウザ ーにサービス画面を送出する。 このときにも、SP からクッキーが渡され、次回以降、直接サービス画面へのアクセスが可能となる。 所属校のID/Passwdでログイン IdP: https://shibboleth‐idp.nara‐edu.ac.jp/ が認証し、アサーションを発行 SP: http://ci.nii.ac.jp/ SPの サービス開始 アクセス承認 利用者のブラウザーを中心とした上述の動作の流れを、HTTP の観点から詳細に説明したものが、 http://www.switch.ch/aai/demo/2/expert.html にある(下図)。 [email protected] October 27, 2011 16 3.2 フェデレーションとメタデータ 各機関の IdP サーバー、SP サーバー、およびフェデレーションが用意する DS サーバー、相互間で認証 に関する情報のやりとりがあるため、SSL/TSL などのセキュアな通信手段が用いられる。このため、各 サーバーは自身のサーバー証明書(公開鍵)を、メタデータの形式でフェデレーションのリポジトリに登録 する必要がある。 IdPの情報とサーバー証明書 ・・ SPの情報とサーバー証明書 ・・ 認証局Aの証明書 ・・ フェデレーションの署名 Federation Metadata.xml 定期的に ダウンロード 登録 登録 リポジトリ 認証局A 定期的にダウンロード 認証局B SP サーバー証明書 (Entity‐Matadata.xml) IdPサーバー証明書 (Entity‐Metadata.xml) アサーション(認証・属性)の交換 XML署名 SSL/TLS SSL/TLS SSL/TLS フェデレーションでは、これらの IdP、SP のサーバーに関する情報と証明書を一個のメタデータとして 集約し、フェデレーションの署名を付け、フェデレーションメタデータ(metadata.xml)とする。これを、 各 Ipd、SP は定期的にダウンロードする。これによりお互いの Relying-Party の関係が信頼できるもの となる。 4. Shibboleth に対応したサーバーの構築 2011 年１月 11,12 日に行われた、学術認証フェデレーションによる「IdP, SP の構築に関する講習会」 に沿って、サーバー構築の概要を述べる。 4.1 IdP の構築 Ldp の機能は 1) 認証：ユーザーの認証(ID/Password、またはクライアント証明書)を行うこと 2) SSO 管理：クッキーによって、すでに認証済みである場合、認証は行わない(Single Sign On)こと 3) 変換処理：データベースに格納されている利用者の属性を SP の要求する形式に変換すること 4) リリース管理：属性が SP に送信してよいものか否かのポリシーを確認し、SAML2.0 に準拠し安全 [email protected] October 27, 2011 17 に(XML 署名)送信すること となる。(以下、特に断らない図表は、http://www.gakunin.jp/docs/fed/technical による) 4.1.1 ソフトウェアの構成と設定 準備作業 1) httpd の設定 /etc/httpd/conf./httpd.conf ・IdP のサーバーのホスト名を ServerName として設定 2) ssl の設定 /etc/httpd/conf.d/ssl.conf ・SeverName の設定 (同上) ・Document /idp/以下を TOMCAT へ送ることを指定 ProxyPass /idp/ ajp://localhost:8009/idp/ 3) tomcat の設定 /usr/java/tomcat/conf/server.xml ・8008 ポートの Connector をコメントアウト ・8009 ポートの Connector に localhost を指定 Shibboleth-Idp のインストール 1) http://shibboleth.internet2.edu/downloads/shibboleth/idp/latest/から最新版の IdP パッケージをダ ウンロードし、インストールする。その際、IdP サーバーのホスト名を設定する。 2) 上を展開した lib ディレクトリから、いくつかの JAR ファイルを所定の場所(java の jre/lib/ext およ び tomcat の CATALINA/endorses)にコピーする。 3) $JAVA_HOME/jre/lib/security/java.security に追加の security provider(暗号化のパッケージ)とし て以下を設定する security.provider.9=edu.internet2.middleware.shibboleth.DelegateToApplicationProvider [email protected] October 27, 2011 18 4) 適切な環境変数の(CATALINA_OPTS)追加、ログファイルの設定など Tomcat に関するエラーは、/usr/java/tomcat/logs/catalina.out に出力される。 4.1.2 スキーマ 学術認証フェデレーションで定めている属性は以下の 16 種類である。 IdP は、各機関でユーザー情報を持つ LDAP/AD や他の DB から取得した属性を元に、上の属性にマッ ピングを行い、各 SP が要求する属性アサーションとして送出する。その処理を図式として示すと以下 のようになる。 http://www.nii.ac.jp/hrd/ja/joho-karuizawa/h21/txt3-1.pdf テストで用いた LDAP データの一部は以下のようである。 [email protected] October 27, 2011 19 dn: o=Test Organization,dc=ac,c=JP objectClass: organization o: Test Organization dn: ou=Test Unit1,o=Test Organization,dc=ac,c=JP objectClass: organizationalUnit ou: Test Unit1 dn: uid=test001,ou=Test Unit1,o=Test Organization,dc=ac,c=JP objectClass: eduPerson objectClass: inetOrgPerson uid: test001 o;lang-ja: テスト 001_大学 ou: Test Unit1 ou;lang-ja: テスト 001_学部 1 sn: test001_sn sn;lang-ja: テスト 001_sn cn: test001_cn userPassword: test001 givenName: test001_givenname givenName;lang-ja: テスト 001_givenname displayName: test001_displayname displayName;lang-ja: テスト 001_displayname mail: [email protected] eduPersonAffiliation: member 属性管理テンプレートやメタデータテンプレートは（https://upki-repo.nii.ac.jp/Template）からダウ ンロードできる。 4.1.3 Shibboleth-IdP XML ファイルの設定 Shibboleth の実装をモジュールとして図示すると、以下のようになる。 [email protected] October 27, 2011 20 IdP SP Browser https https #.htaccess AuthType shibboleth http://www.switch.ch/aai/demo/2/expert.htmlから ShibRequireSession On require valid‐user これらのモジュールの機能は、いくつかの XML 設定ファイルで指定される。 属性情報のフィルタリング shibboleth‐IdP SAML attirbute‐ filter.xml LDAP handler.xml login.config shibboleth‐SP attirbute‐ resolver.xml relying‐ party.xml attirbute‐ filter.xml httpd.conf .htaccess attirbute‐ resolver.xml 信頼 BackingFile shibboleth2. xml httpd Access Control BackingFile Repository Federation Metadata 実際の運用時にこれらのファイルを適切に編集する必要がある。 1) relying-party.xml ファイルの編集(フェデレーションの信頼関係の設定) /opt/shibboleth-idp/conf/relying-party.xml において [email protected] October 27, 2011 21 ・AnonymousRelyingParty および DefaultRelyingParty の Provider として自ホスト名を指定する <AnonymousRelyingParty provider="https://upkishib-idp.nara-edu.ac.jp/idp/shibboleth" /> <DefaultRelyingParty provider="https://upkishib-idp.nara-edu.ac.jp/idp/shibboleth"・・ ・フェデレーションメタデータの取得先と、保存ファイル(BackingFile)の指定を行う <MetadataProvider id="URLMD" xsi:type="FileBackedHTTPMetadataProvider" xmlns="urn:mace:shibboleth:2.0:metadata" metadataURL="https://metadata.gakunin.nii.ac.jp/gakunin-metadata.xml"・・ backingFile="/opt/shibboleth-idp/metadata/some-metadata.xml"> ・取得したメタデータの検証のために、検証用証明書 https://metadata.gakunin.nii.ac.jp/gakunin-signer-2010.cer をダウンロードし そのパスを設定する <security:Certificate> /opt/shibboleth-idp/credentials/gakunin-signer-2010.cer </security:Certificate> 2) handler.xml ファイルの編集(LDAP のデータを用いた ID/Password 認証の設定) /opt/shibboleth-idp/conf/handler.xml において <LoginHandler xsi:type="UsernamePassword" jaasConfigurationLocation="file:///opt/shibboleth-idp/conf/login.config"> <AuthenticationMethod>urn:oasis:names:tc:SAML:2.0:ac:classes: PasswordProtectedTransport </AuthenticationMethod> </LoginHandler> 3) login.xml ファイルの編集(LDAP のデータを用いた ID/Password 認証の設定) ShibUserPassAuth { // Example LDAP authentication // See: https://spaces.internet2.edu/display/SHIB2/IdPAuthUserPass edu.vt.middleware.ldap.jaas.LdapLoginModule required host="localhost" 必要に応じて、外部の LDAP を指定する base="o=test_o,dc=ac,c=JP" ssl="false" userField="uid" subtreeSearch="true" ; [email protected] October 27, 2011 22 4) attribute-resolver.xml の編集(属性の定義や LDAP の属性を学認標準属性への変換・マッピングを行 う) 学認からテンプレートを入手し、必要に応じた編集を行う。 /opt/shibboleth-idp/conf/attribute-resolver.xml において 例えば、 eduPersonPrincipalName(ePPN)を LDAP の属性 uid にマッピングする場合は、以下のよう な設定を行う。scope には所属組織のドメインを指定する。 <resolver:AttributeDefinitionid="eduPersonPrincipalName" xsi:type="Scoped"xmlns="urn:mace:shibboleth:2.0:resolver:ad" scope="nara-edu.ac.jp"sourceAttributeID="uid"> scope に IdP のドメイン(nara-edu.ac.jp)を設定する また、sourceAttributeID に LDAP 内の属性名(uid)を設定する <resolver:Dependencyref="myLDAP"/> <resolver:AttributeEncoderxsi:type="SAML1ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:mace:dir:attribute-def:eduPersonPrincipalName"/> <resolver:AttributeEncoderxsi:type="SAML2ScopedString" xmlns="urn:mace:shibboleth:2.0:attribute:encoder" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"friendlyName="eduPersonPrincipalName"/> </resolver:AttributeDefinition> また、LDAP へのコネクターも設定する。 <resolver:DataConnectorid="myLDAP"xsi:type="LDAPDirectory" xmlns="urn:mace:shibboleth:2.0:resolver:dc" ldapURL="ldap://ldap.example.org" ←LDAP の URL を設定 baseDN="ou=people,dc=example,dc=ac,c=JP" ←LDAP の baseDN を設定 principal="uid=myservice,ou=system" ←LDAP の principal を設定 principalCredential="myServicePassword"> ←LDAP のパスワードを設定 <FilterTemplate> <![CDATA[ (uid=$requestContext.principalName) ]]> </FilterTemplate> </resolver:DataConnector> 5) attribute-filter.xml (SP への属性送信のポリシー・フィルタリングを設定する) 学認からテンプレートを入手し、必要に応じた編集を行う。 [email protected] October 27, 2011 23 /opt/shibboleth-idp/conf/attribute-filter.xml において、例えば Elsevier に対して eduPersonEntitlement 属性送信を行う場合は、以下のような設定を行う。 <AttributeFilterPolicy id="PolicyforElsevier"> <PolicyRequirementRule xsi:type="basic:OR"> <basic:Rule xsi:type="basic:AttributeRequesterString" value="https://sdauth.sciencedirect.com/" /> <basic:Rule xsi:type="basic:AttributeRequesterString" value="https://scauth.scopus.com/" /> </PolicyRequirementRule> <AttributeRule attributeID="eduPersonEntitlement"> <PermitValueRule xsi:type="basic:ANY" /> </AttributeRule> </AttributeFilterPolicy> 4.1.4 サーバー証明書のインストールと関連の設定 サーバ証明書：server.crt 秘密鍵：server.key 中間 CA 証明書：server-chain.crt の所在を、ssl.conf および relying-party.xml に設定する 1) /etc/httpd/conf.d/ssl.conf において SSLCertificateFile /etc/pki/tls/certs/server.crt ←サーバ証明書のパス SSLCertificateKeyFile /etc/pki/tls/private/server.key ←秘密鍵のパス SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt ←中間 CA 証明書のパス 2) /opt/shibboleth-idp/conf/relying-party.xml 上と同じ サーバ証明書：server.crt 秘密鍵：server.key を relying-partyxml の参照先ディレクトリ/opt/shibboleth-idp/credentials にもコピーし、 relying-party.xml を以下のように編集する <security:Credentialid="IdPCredential"xsi:type="security:X509Filesystem"> <security:PrivateKey>/opt/shibboleth-idp/credentials/server.key ←ssl.conf と同一のものを左記のパスにも格納 </security:PrivateKey> <security:Certificate>/opt/shibboleth-idp/credentials/server.crt ←ssl.conf と同一のものを左記のパスにも格納 </security:Certificate> [email protected] October 27, 2011 24 </security:Credential> 4.1.5 IdP のメタデータを作成し、フェデレーションに登録する 学認から IdP 用メタデータテンプレートをダウンロードし、自機関用に編集する。 以下は idp-metadata-template-20100303.xml に関する変更点である。 <EntityDescriptorentityID="https://YourIdPSite.ac.jp/idp/shibboleth"> サーバー証明書を以下に貼り付ける(２カ所) <ds:X509Certificate> MIIFIjCCBAqgAwIBAgIERcdlfzANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGE wJK ******************* サーバー証明書 srflHJUIcX/aCPSTd+LJw1IEP6ivjw== </ds:X509Certificate> SSO への対応 <SingleSignOnServiceBinding="urn:mace:shibboleth:1.0:profiles:AuthnRequest" Location="https://YourIdPSite.ac.jp/idp/profile/Shibboleth/SSO"/> <SingleSignOnServiceBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://YourIdPSite.ac.jp/idp/profile/SAML2/POST/SSO"/> <SingleSignOnServiceBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://YourIdPSite.ac.jp/idp/profile/SAML2/Redirect/SSO"/> <AttributeServiceBinding="urn:oasis:names:tc:SAML:1.0:bindings:SOAP-binding" Location="https://YourIdPSite.ac.jp:8443/idp/profile/SAML1/SOAP/AttributeQuery"/> <AttributeServiceBinding="urn:oasis:names:tc:SAML:2.0:bindings:SOAP" Location="https://YourIdPSite.ac.jp:8443/idp/profile/SAML2/SOAP/AttributeQuery"/> 組織情報と連絡先 <Organization> <OrganizationNamexml:lang="en">YourIdP</OrganizationName> <OrganizationDisplayNamexml:lang="en">YourIdP</OrganizationDisplayName> <OrganizationURLxml:lang="en">http://YourHomePage/</OrganizationURL> </Organization> <ContactPersoncontactType="YourContactType"> <GivenName>YourGivenName</GivenName> <SurName>YourSurName</SurName> <EmailAddress>YourEmailAddress</EmailAddress> </ContactPerson> [email protected] October 27, 2011 25 この自機関 IdP 用メタデータ xml ファイルを、学認のヘルプデスク [email protected] に送付する。 送付されたメタデータは、DS に登録され、またフェデレーションのメタデータとマージされ、リポジト リに登録され、各機関にダウンロードされる。これによって、DS のメニューに自機関 IdP での認証が 選択できるようになる。 4.1.6 Shibboleth1.3 への対応 以上は Shibboleth2.X での設定であるが、1.3 の SP に対応する場合は、Back-Channel の設定という作 業はある。ここでは、説明を省略する。 4.2 SP の構築 SP の機能は、以下の通りである。 ・ユーザーの認証を IdP に要求する ユーザーが SP にアクセスすると、SP は IdP にリダイレクトを行い、IdP にユーザーの認証を要求 する。IdP はこれを受けてユーザーの認証を行う。ユーザーの認証が行われると、SP は IdP から認 証アサーションを受信してユーザーを認証したことを確認する。ただし、ここで受信するのはユー ザーを認証したという事実のみで、そのユーザーが誰かという情報は渡されない。 ・ユーザーの属性を安全に IdP から受信して、アプリケーションに渡す 属性アサーションから属性を取得して、属性の名称を IdP 間で利用する名称から、アプリケーショ ンに渡すための名称に変換する。(属性マッピング機能) 属性値が許容されるものかどうか、フォーマットなどをポリシーに従ってチェックし、問題がない 場合は、属性をアプリケーションに渡す。(ポリシー管理機能) http://www.gakunin.jp/docs/fed/technical/sp/about [email protected] October 27, 2011 26 4.2.1 Shibboleth-SP のインストール 1) 動作用件 CentOs 5 Apache HTTP Server 2.2 以上と mod_ssl SELinux の無効化 時刻同期(NTP)：Shibboleth ではサーバー間の時刻のずれが約５分を超えるとエラーとなる 2) Shibboleth-SP のインストール Shibboleth 用の repository ファイルをダウンロードし、 # wget http://download.opensuse.org/repositories/security://shibboleth/CentOS_5/security:shibboleth. repo yum に repository ファイルを追加する。(ファイル名も変更する） # cp security¥:shibboleth.repo /etc/yum.repos.d/shibboleth.repo そして、yum コマンドを使用する。 # yum install shibboleth 依存性のある unixODBC など、以下のパッケージも同時にインストールされる。 libsaml7 libxerces-c-3_1 libxml-security-c16 libxmltooling5 log4shib opensaml-schemas unixODBC xmltooling-schemas shibboleth 2.4-2.3 3) httpd の設定 /etc/httpd/conf.d/ssl.conf においてサーバーのホスト名を設定する ServerName My-SP.nara-edu.ac.jp 4) shibd の自動起動を設定する # chkconfig --level 345 shibd on # service shibd start [email protected] October 27, 2011 27 4.2.2 設定ファイルの編集 Shibboleth-SP の動作設定は、主に Shibboleth2.xml の編集で行う。 /etc/shibboleth/shibboleth2.xml において、以下のような設定をおこなう。 ・SSO entityID と SessionInitiator に機関の IdP と DS を指定する <SSOentityID="https://test-idp.nara-edu.ac.jp/idp/shibboleth" ↑IdP サーバを設定（metadata に設定されている entityID） discoveryProtocol="SAMLDS"discoveryURL="https://ds.example.org/DS/WAYF"> SAML2SAML1 </SSO> ・・ <Handlertype="DiscoveryFeed"Location="/DiscoFeed"/> <SessionInitiator type="Chaining"Location="/DS"isDefault="false"id="DS"> <SessionInitiator type="SAML2"template="bindingTemplate.html"/> <SessionInitiator type="Shib1"/> <SessionInitiator type="SAMLDS"URL="https://test-ds.gakunin.nii.ac.jp/WAYF"/> ↑DS サーバの設定 </SessionInitiator> </Sessions> 4.2.3 サーバー証明書の設定とメタデータの作成・送付 1) LdP の場合と同様に、サーバー証明書と秘密鍵を(と中間 CA 証明書)を次の２カ所に置く。 /etc/pki/tls/certs/server.crt サーバー証明書 /etc/pki/tls/certs/server-chain.crt 中間 CA 証明書 /etc/pki/tls/private/server.key 秘密鍵 /etc/shibboleth/cert/server.crt /etc/shibboleth/cert/server.key 2) このパスを /etc/shibboleth/shibboleth2.xml に設定する。 <CredentialResolver type="File" key="cert/server.key" certificate="cert/server.crt"/> 4) LdP の場合と同様に、学認からメタデータのテンプレート SP-metadata-template.xml をダウンロー ドし、自機関にあわせた変更を行い、学認のヘルプデスクに送付する。 <EntityDescriptorentityID="https://YourSPSite.ac.jp/shibboleth-sp"> <idpdisc:DiscoveryResponsexmlns:idpdisc="urn:oasis:names:tc:SAML:profiles:SSO: idp-discovery-protocol" [email protected] October 27, 2011 28 index="1"Binding="urn:oasis:names:tc:SAML:profiles:SSO:idp-discovery-protocol" Location="https://YourSPSite.ac.jp/Shibboleth.sso/DS"/> <ds:X509Certificate> MIIFFDCCA/ygAwIBAgIERcdSRzANBgkqhkiG9w0BAQUFADB3MQswCQYDQGEwJK ***************** サーバー証明書 Hyis3FhGejI= </ds:X509Certificate> <AssertionConsumerServiceindex="1"isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://YourSPSite.ac.jp/Shibboleth.sso/SAML2/POST"/> <AssertionConsumerServiceindex="2" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST-SimpleSign" Location="https://YourSPSite.ac.jp/Shibboleth.sso/SAML2/POST-SimpleSign"/> <AssertionConsumerServiceindex="3" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact" Location="https://YourSPSite.ac.jp/Shibboleth.sso/SAML2/Artifact"/> <AssertionConsumerServiceindex="4" Binding="urn:oasis:names:tc:SAML:1.0:profiles:browser-post" Location="https://YourSPSite.ac.jp/Shibboleth.sso/SAML/POST"/> <AssertionConsumerServiceindex="5" Binding="urn:oasis:names:tc:SAML:1.0:profiles:artifact-01" Location="https://YourSPSite.ac.jp/Shibboleth.sso/SAML/Artifact"/> <Organization> <OrganizationNamexml:lang="en">YourSP</OrganizationName> <OrganizationDisplayNamexml:lang="en">YourSP</OrganizationDisplayName> <OrganizationURLxml:lang="en">http://YourHomePage/</OrganizationURL> </Organization> <ContactPersoncontactType="YourContactType"> <GivenName>YourGivenName</GivenName> <SurName>YourSurName</SurName> <EmailAddress>YourEmailAddress</EmailAddress> </ContactPerson> [email protected] October 27, 2011 29 5 奈良教育大学における Shibboleth-IdP、SP の設置 [email protected] October 27, 2011 30 6. OpenAM と GoogleApps の連携 6.1 OpenAM のインストール オ ー プ ン ソ ー ス の シ ン グ ル サ イ ン オ ン ソ フ ト 、 OpenAM を 研 究 室 の Linux サ ー バ ー (openam.nara-edu.ac.jpCNAMEga.nara-edu.ac.jp)にインストールした。OpenAM は、ユーザー情報の リポジトリとして LDAP と RDB、認証/認可に関しては SAML/OpenID に対応している。インストール の方法は、SoftwareDesgn2010/Sept に従った5。 http://openam.nara-edu.ac.jp:8080/openam/OpenAM 管理ログイン画面 管理者 ID(amadmin)でサインインし、OpenAM の設定を行うことができる(次画面)。 この中に「GoogleApps の設定」という項目があり、 「OpenAM と GoogleAppsWeb アプリケーションを 統合して、シングルサインイン環境を作成する」ことができる6。今回、この機能について、Try してみ た。 GoogleApps は Google が提供するクラウドサービスで、大学教育機関での利用も広まりつつある。メー ルやファイルサーバー、スケジュール管理などの機能を GoogleApps にアウトソースすることで、大学 での管理コストを大幅に提言できることが期待される。 GoogleApps は SAML をサポートしていて、OpenAM では GoogleApps との SAML 連携を行うメニュ ーが用意されている。 5 6 「OpenAM の導入と初期設定」Software Design 2010 Sept. P42 「SAML によるシングルサインオンの設定」ibid P46 [email protected] October 27, 2011 31 OpenAM 管理者画面 6.2 GoogleApps への登録 GoogleApps への登録には、所有権を持つドメインを申告し、そこに HTML ファイルをアップロードで きることが必要である。今回、それを ga.nara-edu.ac.jp として登録を行った。 これに対する、Google からの通知は以下の通りであり、登録は完了している。 しかし、今回は StandardEdition の登録であったため、SSO の設定は現在できていない。 SAML のサポートは、PremierEdition、EducationEdition、PartnerEdition でのみサポートされる、 とのことであるので、EducationEdition への切替を行う予定で、他大学での事例を調べている。 [email protected] October 27, 2011 32 GoogleApps への登録確認メール http://www.google.com/a/ga.nara-edu.ac.jp/GoogleApps 管理者ログイン画面 [email protected] October 27, 2011 33 GooglApps 管理コントロールパネル 「高度なツール」画面、StandardEdition では「SSO の設定」が存在しない。 [email protected] October 27, 2011 34 [email protected] October 27, 2011 35