Shibboleth IdP 3.0.0 をインストールしてみた

メモ的に。

こちらも参考に: https://www.gakunin.jp/ml-archives/upki-fed/msg00868.html

# 環境について

* Java 7/8 以降サポート
    * Oracle JDK 推奨。先を考えると8でいいと思う
* Jetty 9, Tomcat 8が公式にサポートされている(らしい)
    * 公式、の意味は個人的にイマイチ定かではない
    * 公式にはJetty 9を強く推奨。ただし公式Wikiの文面はまだ少ない。
    * 個人的にはTomcat 8の方が罠が少なかった
        * 多分経験値不足だろうとは思うが
        * Tomcatの方が相対的に起動が遅い
            * 公式の説明では未チューニングで4分……4分？？
            * jarを舐めまわすのが遅いらしい。公式Wikiに緩和策の記載あり。
    * Servlet 3.0 に対応してればなんでもいい
* IdP設定ファイルの構造がだいぶ変わった。
    * 推測可能な範囲ではある
    * 特にbean beanしてるのが露骨に見えるようになった気がする
* 2系が入っているところで上書きすると空気を読んで設定を作ってくれる
    * らしいのだが、何をどうしてくれちゃったのかの説明はない
    * 素でインストールしてみて設定したほうが分かりやすいのは事実
* 間違ってある環境で上書きして「わー！」ってなった
    * /opt/shibboleth-idp/conf.v2/ というところに設定は残っている
    * ので、それをconf/に移して古いIdPを起動すれば元に戻る
        * war.v2/ も忘れないように。

# 雑記

インストールしている環境から http://localhost:8080/idp/status を見られるかどうかがIdPインストール成功失敗の判断基準として適している。これが見られるかどうかで安心感だいぶ違うので、その後で各種IdP設定に臨むのが吉な気がする。

以前のバージョンでは確か「OK」とかいう親切な文字2文字が返ってくるか来ないかだったのが、今回は使用している環境情報がもっさり出てくる。この情報はJDKのバージョン間違いがないか、といった微妙な情報を動的に見るには適している。

ステータスページはインストール直後の設定ではlocalhostからしか見ることが出来ない。ただしエラーページ自体はShibboleth IdPのパステルオレンジのデフォルトロゴ (下のスクショ参照) が出てくるので、外からでも設定云々はともかくサーブレットコンテナにインストールされているかまでは判断が出来る。

過去の設定でも概ね動作はする互換性があるらしい。……のだけど、以前のようにattribute-resolver.xmlになんでも書くのはあまりよろしくない……という公式Wikiから発されるオーラみたいなのがある。たしかに、あのファイルのごった煮感と比べるとv3の設定は概ね意味に沿って分解しようとしている気がする。ただ、慣れるまでちょっとめんどい。

Jetty 9でHTTPプロキシを使った方法を推奨されるのだが良い方法分からず。httpsからlocalhostの8080に転送したりするとReceivedEndpointSecurityHandlerさんが大層お怒りになる。このハンドラ自体無理やり停止させることは出来るのだけどそれは推奨とは言いがたいので、Jetty 9についてはそこで一旦作業やめた。8443への転送ってなんかダブルでSSLやってそうで遅そうなんだけどいいのかしら。ajp使うと学認の今(2系)の方法とは相性が良い気がする。

Tomcat 8を使うと試すという意味では割と障害が少なかった。以前と同じだから、というのは大きい。相対的にはかなり遅いので、公式の「強く推奨」というところもあってJetty 9に慣れときたい。

デフォでConsent画面が出てきてビビった。お、おぅ

![idp3-consent.png](https://qiita-image-store.s3.amazonaws.com/0/14365/338cf046-78b1-941d-1ae0-c906b7ca61ba.png)

v2では見たことがなかった気がするが/opt/shibboleth-idp/flows /opt/shibboleth-idp/system/flows といったところに、特定の処理を記述できるSpring frameworkのwebflowがもりもり存在し、認証フローをXMLでプログラミングするかのような雰囲気が出ていてヤバい。どのモジュールを次に読み出すかといったことを(起動時に？)コントロール出来るようにするための仕組みとして使っているっぽい。例えば上記のReceived舌噛みそうなHandlerについては以下で読み込まれていたりする。

```/opt/shibboleth-idp/system/flow/saml/saml2/sso-security-flow.xml
<flow xmlns="http://www.springframework.org/schema/webflow"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/webflow http://www.springframework.org/schema/webflow/spring-webflow.xsd"
    parent="security-policy.abstract">

    <!-- Default inbound security processing for SAML 2 SSO profile. -->

    <action-state id="SAML2SSOSecurityPolicy">
        <evaluate expression="ReceivedEndpointSecurityHandler" />
        <evaluate expression="MessageReplaySecurityHandler" />
        <evaluate expression="MessageLifetimeSecurityHandler" />
        <evaluate expression="SAML2AuthnRequestsSignedSecurityHandler" />
        <evaluate expression="SAMLProtocolMessageXMLSignatureSecurityHandler" />
        <evaluate expression="SAML2HTTPRedirectDeflateSignatureSecurityHandler" />
        <evaluate expression="SAML2HTTPPostSimpleSignSecurityHandler" />
        <evaluate expression="CheckMandatoryIssuer" />
        <evaluate expression="'proceed'" />

        <transition on="proceed" to="proceed" />
    </action-state>

    <bean-import resource="../security-beans.xml" />

</flow>
```

特にsystem/内のフローは書き換えを基本的には嫌っている模様で、インストール時点では所有者にも書き込み権限がない。もちろんrootにそんなものはむいみだー、ということで上の部分でコメントアウトすると、エンドポイントが希望したものでない時にIdPがブチ切れる挙動を強制的に止められるのだ。

技術メモは随時以下に突っ込んでるので暇ならどーぞ
https://mowa-net.jp/wiki/Shibboleth3

# IdP 2.4系はいつオワコン？

以下のリリースによると、決定は2015年3月までには行われるとのこと 
http://shibboleth.net/pipermail/announce/2014-December/000092.html

読み違えて3月までと思った俺がいました。流石に3ヶ月はねーだろと思って2度見したら3ヶ月以内にいつオワコンにするか決めるわーでした。

安心した……

といっても長続きは、しそうにない、らしい。