学認の現代化：MDQによるメタデータ取得の効率化と属性流通の見直し

はい、国立情報学研究所の西村です。本日は学認の現代化ということで発表させていただきます。その1と書いておるのがメタデータ取得を効率化するという話。今までの話からするとだいぶ具体的な話ではございますが。その2につきましては、属性の話をしたいという風に思っております。

先ほどメタデータトラストフレームワークの話を変えていかなきゃという話はあったんですけれども、もうちょっと短期的な話として、現在ある問題、学認にある問題を解決していくというところで、話としては今年度のお話なので、何が2030だというご指摘もあるかもしれませんけれども、まずはこういうことをやっているというところで聞いていただければと思います。

皆さんもご存知かもしれないですけれども、学認にはメタデータというものがありますよというところの説明から入っております。このフェデレーションと書いているのが、どうすればいいんだか、学認なら学認でございまして、その中にIdP、SP多数のものが参加していると。あるIdPは、その学認に参加しているSPというものを把握するために、メタデータというものを参照するわけでございます。フェデレーションメタデータというのが、その学認のトラストの根幹になっているという形になっております。同様にSPは、対向となるIdP、学認にどのようなIdPが参加しているのか、どういう証明書を使っているのかというような情報をこのフェデレーションメタデータに依拠して、それを参照することによって情報を得ているというものでございます。

これはフェデレーションメタデータの中身を説明しているんですけれども、ご存知の方はご存知ですかね、XML形式という、テキストとしては複雑な部類に入るかなと思いますが、その中身としては、それぞれのIdP、SPに対して、そのIDなり、証明書なり、利用可能なプロトコルなり、その他の情報をぎゅっとメタデータという形にしたものを、IdP、SPの数だけ並べたものというものがメタデータということでございます。

ここで出てくるのがeduGAINですね。先ほどもありましたけれども、学認はともかく、eduGAINという世界各国のフェデレーションが集まったフェデレーション、インターフェデレーションという風に呼んでおりますけれども、その枠組がeduGAINというものでございます。

ちょっと字が小さくてすいませんけれども、学認のようなフェデレーションが世界各国に存在しており、現在80以上の国と地域が参加した大きなインターフェデレーションとなっております。IdP、SPと合わせると、もう1万以上のエンティティが参加しているという風になっております。学認に参加したIdPですね。学認からeduGAINに参加することによって、そのたくさんの、SPで言うと4000以上ですかね、のSPが利用可能になるという風な仕組みでございます。学認からどうやって参加するかという話はちょっと置いといてですね。

メタデータという視点で言いますと、とっても大きなメタデータ。先ほど学認のメタデータの話をしましたけれども、eduGAINにも同じようにメタデータというものがあって、1万以上のエンティティを含んでいる。サイズ、バイト数で言うと90MBというようなところではあるんですけれども、このXML形式のものを解析して使えるような形にするには、莫大なメモリが必要、解析の時間も必要となって、これがeduGAINに参加しているIdP、SP側で問題になっているというところでございます。

今までは、そのメタデータというもの、フェデレーションメタデータ、学認のメタデータ、eduGAINのメタデータ、それをIdPならIdP、SPならSPがダウンロードしてくる、丸ごと取得して、それを解析してというようなことをそれぞれのIdP、SPの中で行っていたわけですが、ここで新メタデータ取得方式プロトコルMDQ、メタデータクエリー、略してMDQなんですけれども、その新しいメタデータ取得方式を導入いたします。

このMDQ、もしかすると名前を聞いたことがある方もいらっしゃるかもしれませんけれども、いよいよ学認でも導入できる段階にありましたので、改めてご紹介させていただくというものでございます。詳細はともかく、従来方式で言うとメタデータを丸ごと取得するのではなくて、1万以上あるエンティティの中の、その認証連携に必要なものだけを取得して、それで認証連携を行うというようなモデルでございます。

これは従来方式との比較ということで、左が従来の方式ですね。大きなメタデータ、学認メタデータ、eduGAINメタデータをそのまま丸ごとSPがダウンロードしてきてというようなものが左でございまして、先ほど言いましたように、その処理に時間がかかる、莫大なメモリを必要とするようなところで、重かったり非効率だったりするところがありますと。実際、eduGAINのメタデータ、1万以上あると言いましたけれども、それら全てが必要になるなんてことは全然なくてですね、実際そのSPが相対する、認証連携するようなIdPというのはごく限られたものになるというようなところがございますので、必要なIdP、SPのメタデータ、エンティティメタデータって言ってますけれども、それだけを取得してくるような形にすれば、右の図ですね、軽く、効率的になりますよというようなものでございます。

これは実際、我々が独自にやっているということは全然なくてですね、先ほどのURLもありましたけれども、国際標準仕様が提案され、規定されているものでございまして、すでにInCommonやSWAMID、えっと、どこだっけ、スウェーデンのフェデレーションですかね、でも実用されていると。InCommonとかで言うと、もうすでに従来の方式、そのフェデレーションメタデータをダウンロードしてというようなところはもう切り捨てて、過去のものとして、このMDQのみでいいというような移行を、2025年、去年ですかね、行ったというようなものでございます。

では、これを利用するためにはどうすればいいのかというところでございます。皆さんのSAML実装でも、MDQという機能を利用するためにはどうすればいいんだろうというところを是非確認いただきたいんですけれども、例えばShibboleth、Shibboleth IdP、Shibboleth SPでは、このようになっているというようなところでございます。これも小さくて読んでいただくには及ばないですけれども、すでにShibbolethにはMDQの機能が組み込みでございますので、その機能を使うという宣言、設定を、IdPならこんな感じ、SPならこんな感じということで、どのURLに対してMDQを行いますと、どのサーバーに対してですね。現時点で、学認はこのサーバーですというのが提示できてなくて申し訳ないですけれども、今年度中には提供しますと、詳細に関しては後日お知らせしますというところで、お知らせした際には、皆さんのところのIdP、SPでこのMDQの機能を使っていただければという風に思います。メタデータの処理の部分はとても軽く済ませることができるようになりますので、是非ともご期待いただきたいと存じます。

最後のスライドは、実際の学認でMDQをサービスするために、このようなことが行われますというところをお示ししたものでございますが、右下にありますeduGAINのメタデータ、学認のメタデータを、それぞれプログラムによって分割して、キャッシュのような形で配置しておいて、それに対してSP、IdPからリクエストが来たら、エンティティIDというIDをキーに、そのメタデータを取得して、それに対して署名して返すというようなプログラムが走ると。単純なものですけれども、そのような開発、実装に関してはすでに終わっていると。あとは本番環境、学認のシステムに組み込んで提供するだけというようなところでございまして、先ほどから何度も言ってますが、今年度中、近々アナウンスできるであろうというところでございます。

はい。今のが1つ目ですね。学認の現代化その2として、属性セットの流通最新化というところでお話をさせていただければと思います。

こちらですね、先ほどこういうことをやりますというところなんですけれども、本来センター長がこの場で話すというところでございましたが、先ほど山先生からもありましたような事情により、私が代わりに発表させていただきますと。学認の属性セットに関して、このようなことを考えているという。これもeduGAINで行われているところの、追いつけ追い越せというような感じで、色々な国際的な取り組みが行われておりますので、それを学認でも行うというようなところでございます。

属性に関しても、皆さんもご存知のところかと思います。IdPから、その人、利用者に関する情報ということで、氏名であったり、メールアドレスであったり、その人の所属とか職員などを学認で規定しておりますと。どういう名前で呼ばれて、その内容として、フォーマットと言うんですかね、このようなフォーマットで格納してください、SPに渡してくださいというような形で、学認技術運用基準で定義して規定しているんですけれども、現在21属性を規定しておりますと。実際のサービス、SPでは、その中のこれとこれが必要ですという風な形で、それぞれのサービスA、B、Cとありますけれども、それぞれが異なったセットの属性を要求し、IdP側はそれに合わせて設定して、送信できるようにする。実際の認証連携で、その属性が送られて、ログインして、利用が開始されるという風なところが行われているかと思います。

よくある不満というかですね、としては、それぞれのサービスに対して設定しなければ送らないようになっていると。それが、ごめんなさいね、めんどくさいというのもありますし、その作業は大変である、1つ1つのサービスに対して必要な属性をIdPに設定していくというのは大変であるというような話をよく聞くところでございます。

まずは新たな属性ということで、最後に書いてあるように、eduGAINではそのような取り組みが行われていますというところなんですけれども、学認で今、ID属性、そのユーザーのIDとして使われているですね、eduPersonPrincipalName(ePPN)及びeduPersonTargetedID(ePTID)という、名前は聞いたことあるという方も多いかもしれないですけれども、それらに関して後継となる属性が国際的な標準として決められておりまして、そちらの属性に関して学認として規定し、それらも学認の中で流通させようという風に現在検討しているところでございます。

こちらは、このePPN、ePTIDの問題、歴史的なところも多いんですけれども、それの問題を解決して、シンプルな目的で改めて定義したものでございまして、Shibbolethに依存するような理解の難しさとかを排除して、大文字小文字同一視の問題も、一部の非Shibboleth、Shibbolethでない実装の間で問題であったところも解決したものが規格として規定されておりますので、そちらに乗り換えて、サポートするようにして。eduGAIN等では、そちらを要求するようなSPも存在しております。今後増えていくと考えられますので、そのようなものに対しても問題なく認証連携できるように、学認としてもこちらへのサポートを進めていきたいと考えているところでございます。

もう1つの話は、R&Sという名前で、もしかしたらこちら聞いたことがあるという方もいらっしゃるかもしれないですけれども、まさに先ほど言ったIdPに属性を送るための設定、1つ1つ、どのSPに何を送る、別のSPに何を送るというようなところを1個1個設定していかなければならない、大変だというところの解決策として提供されているものを、学認でもやりますよというようなところでございます。研究学習環境の連携のためということで、2つ目に書いてあるSirtfiというものは、最後にちょっと触れさせていただきます。

R&Sですね、Research and Scholarshipというものが規定されておりまして、この枠組では、あるSP群に対してR&Sという、なんて言うんですかね、ラベルをつけましょうと。ちゃんとフェデレーションとして審査した上で、このSPはR&Sですという風なラベルをつけていきますと。ですので、IdP側は個々のSPを見ることなく、R&Sというラベルがついたら、これの属性を送ってくださいねという、SPをまとめて扱うようにするような枠組でございます。

どういう属性かというのは真ん中に書いてあるものでございまして、パーソナルアイデンティファイアーズとか、シュードニマスアイデンティファイアー、アフィリエーション等をまとめて扱う、属性バンドルという風に言っておりますけれども、このようなR&Sという仕組みに乗っていただければ、IdP側で、R&Sという印がついているSPに対してはこれの属性を送ります、ここに書いてあるような属性を送りますという風な設定ができますので、そのような設定をしていただけると、個々のSPに対して属性設定するという手間を省くことができまして、ということでございます。

実は、よろしいですかね。こちらもeduGAINの中で、そのようなSPが多くありまして、それらに対して効率的に属性送信ができるようにしようという風な仕組みでございます。実は最後に書いておりますけれども、IdPに対して、R&Sをサポートしてます、R&SのSPに対しては送りますというような、学認申請システム上の機能なんですけれども、そのようにアサート、IdPがサポートしてますよという風な宣言をすることはすでに可能なんですけれども、それをSPにも広げて、これはR&SのSPですという風な印付けも学認でできるようにしようと。まず始めに、学認RDMからR&Sを付与するというような作業を始めていて、さらには学認の他のSPに対しても、そのようなR&Sを普及させていきたいという風に考えているところでございます。

ここからあと、そっか。実はこのR&S、先ほど言った仕組みはバージョン1.3という形で、先ほどのURL上に公開されているんですけれども、実はその進化版というものが、アノニマスアクセス、シュードニマスアクセス、パーソナライズドアクセスと3種類のカテゴリーに分かれて存在しております。先ほどのR&Sというのは、パーソナライズドアクセス、いわゆる共通の識別子、ePPN改めサブジェクトIDという識別子を必要とするカテゴリーのSPなんですけれども、それに別の2つのカテゴリーを用意して、ePPNは必要ないんだけれどもシュードニマスなアイデンティファイアを必要とするようなカテゴリーのSPとか、そういうID属性は不要だよというようなカテゴリーのSPと、自分のSPはこういうSPですという風な3種類の申告ができるようにして、それらに対してR&Sと同じように、アノニマスと印がついているSPに対してはこういう属性を送りますよと。3つそれぞれ、この属性を送ってくださいねという属性バンドルが定義されておりますので、それらを送るように、これもIdP側で、この3種類に対してこういう風な設定ができると。その設定さえしておけば、その印が付いているSPに対しては、個々のSPの属性送信設定をする必要なく、使用が開始できるという風な仕組みになっております。

このようなところで、これまで学認に参加していただいた皆さんも、IdP側で、SPを審査して、このSPならオッケーです、この要求されている属性を設定しましょうという形で、1つ1つ、最小というと、あれですね、なるべく送らないようにするという方ですかね、審査した上で、チェックした上で送るというものを設定されているかと思いますけれども、今言ったようなカテゴリーのSPに対しては、共通識別子とかシュードニマスなアイデンティファイアを必要としているSPでございますので、それに対してまとめて属性送信設定するというような形で、より積極的に認証連携をして、使えるSPの数を増やしていきましょうというのが、この取り組みの目的、やりたいところというところでございます。

はい。ちょっと時間がなくなったので飛ばしますけれども、Sirtfiという、そのIdPなりSPなりの運用体制を示す、ちゃんと運用していますよというのを表す仕組みでございまして、これもREFEDSの方で定義され、使われているというところでございます。実際、今説明したようないくつかのものがどれぐらい使われているんだろうと、eduGAINメタデータ上でカウントしたものがこちらでございます。やっぱり新しいものの方が、使われている量としては少なくなっており、ただR&SとかSirtfiに関しては、もう1000以上使われているというところで、皆さんも是非こちらの枠組に乗っていただけるとよいのではないかなというところでございます。はい。私からの発表は以上でございます。