[AD FS]JavaアプリSPとSAML Artifact Bindingで連携する際の証明書ストア

こんにちは、富士榮です。

小ネタです。
JavaでSAML SPとなるアプリケーションを開発した場合のSP⇒IdP間のバックエンド通信に使う証明書の登録に関するTIPSです。

◆SAML Arifact Bindingとは？

まず、SAML Artifact Bindingの通信フローのおさらいです。
簡単に言うと、POST Bindingではユーザのブラウザを経由してSAML AssertionをIdPからSPに渡すのに対して、Artifact Bindingでは認証後Artifactと言われるコードをユーザのブラウザを経由してSPへ渡し、SPはブラウザより受け取ったArtifactをIdPへ渡してSAML Assertionと交換する、という仕組みです。
ややこしいので、SPとIdPの間で直接の通信が行われるタイプのBindingと覚えておいてください。
OAuthやOpenID Connectがわかる人は、Code Flowと同じ考え方と理解すると早いかもしれません。

こんなイメージです。

昔はガラケーなどブラウザで扱えるデータサイズの問題があったので、SAML Assertionそのものをブラウザ経由でPOSTするのではなく、比較的サイズの小さいArtifactを使ってID連携をする必要があったのですが、最近は通信速度や端末性能の向上により、Artifact Bindingが使われることは減ってきています。SPとIdPの間で直接通信をさせなければならないので、クラウドサービスと社内IdPを連携させる場合などの通信の取り回しなども非常に面倒、というのも使われなくなってきた一因です。

ただ、今でもたまにArtifact Bindingしか使えないSAML SPが存在するので、仕方なく実装することがあります。（AD FSではArtifact Bindingをサポートしています。尚、Azure ADはPOST BindingのみなのでArtifact Bindingは使えません）


◆SPとIdP間のSSL通信に使う証明書の信頼設定

先述の通り、POST Bindingではすべての通信がブラウザを介して行われるため、SSL通信に使う証明書のチェックについてはブラウザが信頼している証明書であればなんの問題もありませんし、最悪オレオレ証明書でもユーザが警告を無視してくれさえすれば、ID連携することが可能でした。

しかし、Artifact BindingではSPとIdPの間でSSL通信をエラーなく成立させる必要があるので、SPがSSL通信に使う証明書を信頼している必要があります。

信頼をするための方法はミドルウェアによりさまざまで、例えばsimplesamlphpでは設定ファイルに通信で使う証明書が入っているストアを直接指定する、などの方法をとります。

今回は前回のポストで使ったWebLogic上にデプロイしたJavaアプリケーションの場合のTIPSです。
WebLogicが信頼する証明書ストアはサーバの構成よりキーストアの設定で設定・確認することが出来ます。

初期状態では、デモ用のキーストアおよびJava標準のキーストアが設定されていますので、このキーストアのどちらかにIdPがSSL通信で使う証明書がインストールされている必要がある、ということになります。

今回はAD FSをIdPとして使ったので、AD FSがSSL通信で使っている証明書をExportしてWebLogicが使うキーストアにインストールします。

まずは、AD FS管理コンソールより証明書を開き、Service Communicationに設定されている証明書を開き、DER encoded binary X.509（cer）形式でエクスポートします。

エクスポートしたcerファイルをSPにコピーし、以下のコマンドを実行して証明書ストアへインストールします。

keytool -keystore <ストアのファイル名> -importcert -file <証明書ファイル名>

こんな感じです。

これで、無事にSP⇒IdP間でSSL通信が成立するので、SAML Assertionの受け渡しが行えるようになります。