前回のSAML2実装準備の完了の報告に続けて、汎用認証サイトにSAML2を実装し始めて、大方完了し、この機能は、2019年10月リリース予定の、汎用認証サイト ver 01-90に（SAMLライブラリはOpen棟梁 ver 02-50に）含まれる予定です。


　色々とSAML2の仕様・実装を見て思うのは、「SAML2の仕様自体ってそこまでセキュアじゃないよな？」って事です。

　...例えば、SAML2仕様を見ていて一番最初に気が付くのは、「トラストサークル（Circle Of Trust）って任意っぽい。」と言う事でしょうか？（そもそもOASISの仕様中に、この用語が出てこない）。調べてみると、SAML2リクエストに署名しないIdPもフツーにあるっぽいですね。

　多分、インターネット向けは殆どSAML2レスポンスのみの単方向の署名・検証で、イントラネットからフェデレーションするようなケースでは、トラストサークル（Circle Of Trust）構築して、SAML2リクエスト＆レスポンスに双方向の署名・検証をするのがデファクト・スタンダードなんじゃないでしょうか？

　従って、「FAPI Part 1 (Read Only API Security Profile)」の双方向の署名・検証（Client認証に「jwt-bearer」を使用する）位までやれば、単純にSAML2を超えてる気がします。更に、JARやJARMを導入すればよりセキュアになると思います。

---

余談：

　...あと、XML関連の処理は、今迄、結構書いてきた気がしますが、この度、改めて、XMLライブラリには問題が少々多い気がしました（これは、（１）XMLの仕様が重過ぎる事と（２）昨今、JSONとの対比が入った事に起因するモノと思いますが）。

　また、外部実体参照によるXMLライブラリの遅延だけでなく、脆弱性の問題報告もありましたが、

1. 以前ご報告した、SignedXmlでネストした署名・検証の問題
   （あと、署名を署名対象の中に入れるのも釈然としない）。
2. XML名前空間 [XMLNS] 属性が無いと、XMLの読込に失敗する。
3. DTDが無いとDOM操作（GetElementById）できない。
4. XPathで代替すると、ルートとルート以下で検索式が違って、
   XPathのルートの検索が上手く動かない（「/」「//」）。
5. XmlDocumentのマージにImportNodeと言う「お呪い」が必要。
6. XmlDocumentから空のxmlns属性が出力される問題
   

　...等々、なんか、色々と大変でした
　（多分、やればやっただけ、もっと出る）。

　ココまで書いていると、（XMLがJSONと比べ複雑なので）XMLライブラリには、恐らく相互運用性にも問題があり、SAML2の相互運用なんかも、これまで、各言語間で、苦労されてきている人が多数いらっしゃるんじゃないだろうか？なんて思ったりしています。

　一方で、JSONはPOCO（POJO）への「parse」が容易なので、プログラム的には、このように悩むことが無く快適、そして、現時点で出来ているように、相互運用性の問題が少ないのがイイですね。そう言う事もあり、以前、書いたようにSOAPが廃れてREST（やJSON-RPC）が隆盛したんだと思います。