Shibbolethで複数のIDを同一人物としてログインさせる

(こちらの内容は、学認メーリングリストで国立情報学研究所の西村様、京都大学の針木様から頂いたアドバイスの内容を含んでいます)

Shibbolethにおいては、認証システムにおける「ユーザ名」に相当する概念が、uid(ログイン名)、ePPN(フェデレーション内で一意なユーザ名)、ePTID(IdP:SPのペアで一意なユーザ名)の3つがあります。

この仕組を利用して、他のID体系からShibbolethにユーザアカウントのプロビジョニングを行うにあたって、学内に複数のID体系が存在して、同一ユーザが複数のIDを持っている場合に、次のようなID管理を実現可能です。

  • ユーザはどのID体系でもIdPにログインできる
  • ログイン後は、どのID体系でログインしてもSPからは同一人物として見える

複数uidで同一ePPNのLDAPを用意する

まず、パスワードはuidに紐付いています。LDAP上にuidの異なる複数のエントリを設けることで、その双方でログインすることは可能となります。Shibbolethのuidはフリーフォーマットですので、「@ドメイン名」などのスコープを付けた形でuidを定義するなどの方法で、複数ID体系の衝突を防ぐことは可能でしょう。

そして、ePPNは一番広いアカウント体系のuidを採用するか、Trusted DBにあるユーザ識別可能な何らかの属性から生成して、LDAP上で同一人物は同一のePPNを持つようにすることで、ePPNを要求するSPからはどのuidでログインしても同一人物に見えるようにすることができます。

ePTIDは基本的にePPNとSPのentityIDから生成されるようにすれば、これもSPから見ればどのuidでログインしても同一人物に見えるようにすることができます。

これだけ読むと、LDAP上のデータを適切に用意することだけで実現できそうに思えるのですが、それほど簡単な話ではありません。

ePPNとePTIDをLDAPのePPN値ソースに変更する

まず、学認の標準テンプレートのattribute-resolver.xmlでは、ePPNをLDAPのePPNのエントリではなく、uidを流用するようになっています(2行目のsourceAttributeID=”uid”の部分)。

続きを読む

Shibboleth SPで学認独自属性にアクセスする

(2014年9月1日 追記) NIIの西村様から情報をいただき、これらの属性にアクセスするためのattribute-map.xmlは、https://meatwiki.nii.ac.jp/confluence/pages/viewpage.action?pageId=12158127#id-%E6%8A%80%E8%A1%93%E3%82%AC%E3%82%A4%E3%83%89-%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88 から取得できるということを教えていただきました。どうもありがとうございます。なお、以下の記事の内容は、そのまま掲載しておきます。

OSにShibboleth-SPをインストールした状態で、主なShibbolethの属性はアプリケーションから環境変数経由で読み出せるのですが、学認独自の属性に関しては、標準状態では読みだすことができません。

独自属性には、日本語の組織名(jaOrganizationName, jaOrganizationalUnitName)、氏名(jaSurName, jaGivenName, jaDisplayName)等の日本語データや、身分や学籍番号などを表すgakuninScopedPersonalUniqueCode等があります。

これらの属性にアクセスするには、Shibboleth SPの設定ファイルattribute-map.xmlの <Attribute>…</Attribute>内に、次のように追記することで実現可能です(環境変数経由でアクセスするときのパラメータ名は適当に短縮しています)。

なお、このファイル中にはたとえば

のように、OIDではなくパラメータの名前で定義されている行もありますが、これはShibboleth 1.3対応のものなので、Shibboleth2系でアプリケーションを構築するのであれば必要ありません。

OIDに関しては、学認サイトの属性リストページで調べられますので、上記に挙げられていないパラメータにアクセスしたい場合は、ここからOIDを調べてください。

学認用Shibbolethリバースプロキシの構築

学認で利用されている認証ソフトウェアであるShibbolethは、SP部分はC++で記述されているため、SPの動作にJava VMの必要などもなく、既存のシステムへの組み込みも比較的容易です(IdPはJava VMやtomcatが必須です)。一方で様々な理由で、認証リバースプロキシがあると、内製ではないWebアプリの対応が楽になる場合があります。

そのため、Shibbolethの認証リバースプロキシを構築してみました。作業環境にはFreeBSDを用いましたが、CentOS等の場合でもそれほど違いはないと思います。

まずは、shibboleth-spをインストールします。FreeBSDの場合、標準だとapache22がprefork MPMでインストールされてしまい、メモリを無駄遣いするので、このあたりの手順でworker MPM版をインストールするのがお勧めです。

そして、ApacheのSSLを適切に設定し、SPとしての設定も行います。リバースプロキシを使って実現するようなサービスはたいてい学内サービスでしょうから、学認のSPとしてグローバルに登録しない、ローカル的なSPとしての構築をしたい場合はこの辺りの手順を参考にしてください。

そして、ApacheのSSL設定部分(FreeBSDならば/usr/local/etc/apache22/extra/httpd-ssl.conf、CentOSならば/etc/httpd/conf.d/ssl.confあたり)の<VirtualHost _default_:443>…</VirtualHost>の中で、次のような設定を行います。ここで、プロキシ先は平文で、http://192.168.1.2/を仮定します。

この例では、ePPNとeduPersonAffiliationを属性として受け取り、Affiliationが教員か学生の場合のみにプロキシにアクセスを許可ています。そして背後のサーバに、HTTPのパラメータとしてX-Shib-EppnにePPNを、X-Shib-AffiliationにeduPersonAffiliationを渡しています。

続きを読む

学認のIdPを用いた学内サービス用SPを構築する

学認のIdPを構築することで、学認で利用可能な外部のSPを利用可能となりますし、学認の多くのユーザに使ってもらうSPを構築することも可能です。一方で、作成したいSPの中には、外部のユーザに公開することが適切ではないサービスもあります。

そのようなサービスでは単に外部のユーザには使用できないだけではなく、学認の公式メタデータにもリストアップされず、認証に用いるIdPの選択画面なども表示されないようにする必要があります。

学認公式サイトの技術ガイドではこの辺りの手順がよくわからないので、以下にまとめてみます。

IdP側の設定

まずは、SPのメタデータを生成します。学認申請システム(運用フェデレーション用テストフェデレーション用は別です)にログインし、「新規SP申請」から「SPメタデータ情報」のところに必要なデータを入力し、そこにある「以下の内容でエンティティメタデータをテスト生成」をクリックすることでメタデータを生成できます。

この際、XMLファイル冒頭の<EntityDescriptor>のID属性は、適当に修正しましょう(他と同じでも特に問題はなさそうですが)。

これを適当なファイル名で、IdPの/opt/shibboleth-idp/metadata/に置きます(ここでは仮にtestsp.xmlというファイル名を仮定します)。そして、IdPのrelying-party.xmlの、/rp:RelyingPartyGroup/metadata:MetadataProviderの中にある

の前か後に、次のようにしてローカルメタデータへの参照を追加します。ここでも、id属性は適当に設定してください。複数のSPを登録したければこれを並べていけば問題ありません。

続きを読む

FreeBSDで作る学認用Shibboleth SP

学認などで利用されているShibboleth SPをFreeBSD上に構築してみました。環境としてはFreeBSD 10.0-RELEASEです。作業は非常に簡単です。

OSをインストールし終わったら、次のようにしてShibboleth SPをインストールします。

ただし、shibboleth-spのportはapache22に依存しているのですが、標準のapache22はprefork MPMのためにメモリを大量に消費します。できればこういうアプリのパッケージはapacheに依存性を付けないでもらえると嬉しいのですが、mod_shib22.soを入れる必要があるので必要なんでしょうね。

とりあえず、apache22を強制再インストールで問題はなさそうです。

ただし、/usr/local/etc/apache2/httpd.confのCGIモジュールの部分だけは、

から、

に修正しないと、worker MPMのApacheは起動しません。ちなみに、shibbolethのモジュールが

で正常に組み込まれていることも確認して下さい。もし入っていなければLoadModuleの行の最後にでも追加しましょう。

続きを読む

学認FPSP(Filter Per SP)の改良

(この内容は、学認メーリングリストで、オープンソース・ソリューション・テクノロジの相本様、辻口様からいただいたアドバイスやパッチを含んだ内容となっています)

学認FPSPとは

学認は認証インフラとしてShibbolethを利用しているのですが、Shibbolethは認証と認可をIdPとSPとに完全に分離しているため、属性によってユーザが利用できないSPを利用しようとすると、次のような行動パターンになってしまいます。

  1. SPのサイトで自IdPを選択
  2. IdPでユーザ名とパスワードを入力してログイン
  3. SPのサイトに戻ってそこで利用を断られる

認証と認可の分離という観点から言えばこれは正しいといえるのですが、通常の1サイトで完結したアプリケーションの利用者にとっては今ひとつわかりにくいのも事実です。

また、本来であればSP側でユーザ属性に基づいて認可を行ってほしいのに、ユーザ属性が何であっても受け入れてしまうSPもあります(なおかつ、そのまま利用するとソフトウェアライセンス違反になってしまうものもあります)。

このような問題を解決するには、IdP側である程度の認可情報を管理し、SPに移動する前に制御を行いたいと思うのですが、そのような目的に利用できるものとしてFPSP(Filter Per SP)というツールが提供されています。

FPSPの問題点

ところが実際のところ、このFPSPを利用してみると色々と問題があります。バグといえる問題点としては、

  • 一旦FPSPでログインを拒絶されると、その後シングルサインオン自体が無効となり、他のSPにもログインできなくなる(ブラウザを終了させるか、タイムアウトを待たないと他のSPが利用できない)
  • 実は、FPSPに設定されたサイトにアクセスしてIdPを選択すると、そこでログインしなくても他のSPにログインできなくなる

仕様上の問題といえる点としては、

  • SPが要求しない属性でフィルタできないため、先程述べたような、SPが必要な属性を要求せずに認めてしまっているサイトへの移動をフィルタできない

が挙げられます。

続きを読む

FreeBSD 10.0にWordPressをインストール

このサイトを立ち上げるにあたって、FreeBSD 10.0にWordPressをインストールしたメモです。FreeBSD 10からはpkgngがデフォルトのパッケージ管理システムになっているので、これを用いてインストールすることになりますが、色々問題があり、試行錯誤が必要でした。

普通に考えれば、

でインストールできるんじゃないか、と思うのですが、この状態だと次のような問題があります。

  • ja-wordpressの依存性でphp5がインストールされるが、このphp5にはmod_phpは入っていない
  • apache22のMPMがpreforkなので、mod_phpとか組み込んで色々やった日にはメモリをバカ食いする
  • apache22のMPMをworkerにするには、php5をスレッドセーフにしなければならないが、標準ではそうなっていない

そのようなわけで、結局次のような方法を取ることにしました。まずは上記の理想例同様に、ja-wordpressとmysql56-server、apache22-worker-mpmをインストールします。

そして、ja-wordpressとphp5関係をすべて削除します。

続きを読む