「manaba」におけるSingle Sign-On (SSO)サービスについて【後編】

朝日ネットシステム基盤部のGernot Hassenpflugです。主に仮想インフラ、サーバ運用と認証システム連携を担当しています。

朝日ネットのSSOインフラとサポート業務
- SSOの実装と運用の問題点
  - SLO (Single Logout)について
- 運用の問題
まとめ・将来に向けて
最後に
参考
採用情報

朝日ネットのSSOインフラとサポート業務

前回の記事で書いたように、朝日ネットはお客様のIdPで連携する前に、サービスを検証するため社内用のIdPサーバを運用しています。

このインフラは大枠としては社内IdPサーバ、ステージング用IdPサーバ、テストユーザの認証情報を持つLDAPサーバからなります。

「manaba」でSSO認証連携が必要になったときは、ShibbolethのSPを該当のmanabaサーバに（新規構築中・本番運用中にかかわらず）デプロイし初期設定では社内IdPと連携します。ここで基本的な運用をテストユーザで確認します。そしてその後は検証のためにお客様のIdPへ連携用に設定変更します。初期設定や検証中に使うアクセスURLは最終的に本番で使われるURLとは別なので既存の運用には影響ありません。

お客様の組織のIdPの要件によっては、検証が簡単に終わることもありますし、SP側でカスタムの属性やポリシーの定義、デフォルトと異なるパラメタ設定が必要となる場合もあります。実際に必要となった定義や設定は朝日ネットとお客様の組織とで合意した仕様書に反映し、それを基準に今後の運用管理や設定変更を行います。

SSOの実装と運用の問題点

SSOの経験や技術的な知識を必要とする問題はSSOの実装の段階でよく発生します。特に、お客様がSSOの運用や設定への知識が不足している時は、（例えばSAML2のスキルが足りないお客様にシステムのSAML2の機能を理解していただく等）朝日ネットがサポートをします。 SSOのシステムとセキュリティーを保護するためであり、将来のスムーズな運用にもとても重要な業務です。

SLO (Single Logout)について

SSOからのログアウト、いわゆるSLO (Single Logout)は技術的な面でもユーザへの案内の面でも難しいです。 SP側でセッションを削除しても、IdPでまだ有効なセッションがあれば、ユーザは自動的にSPへのアクセスが許可され、SP側でセッションが再生成されます。つまり、アプリケーションでのローカルログアウトはSSOからのログアウトにはなりません。 その代わり、SPはSAML2のログアウト依頼メッセージをIdPへ送信します。このメッセージにはログアウト後に飛びたいログアウトページのURLもつけることができます。通常はSSOからログアウトしたという説明とユーザにこれからの操作の案内をするページになります。

f:id:watanabe06:20210428154801p:plain — SLOのSAML2フロー

SPからログアウト依頼が来たIdPは他の全てのSPにログアウトリクエストを送信します。各SP側で該当ユーザのセッションがあれば削除する仕様ではありますが、SP側が正しく処理を行うかどうか、またその依頼が確実に各SPに届くかどうかも保証できません。

次に、IdPは自分の持っている該当ユーザのセッションを削除し、元のSPへログアウト完了のメッセージを返します。そのメッセージには元のSPのメッセージで希望していたログアウト後に飛ぶURLがまた付加されます。元のSPはこのメッセージで自分のユーザセッションを削除して、ユーザをそのログアウトページにリダイレクトします。

上記の流れでわかるように、これは技術的に複雑で、また全てのメッセージが正しく処理される保証もありません。ログアウトプロセスの途中でIdP側またはSP側でエラーが発生したら、ユーザはそのサーバのエラーページにリダイレクトされる可能性もあります。そのため、IdPとSPの管理者両方で状況を説明するための適切なログアウトページとエラーページを用意する必要があります。

SLOは実装が難しく保証も難しいため、PLO（partial logout、部分的なログアウト）とも言われています。 PLOでは最低限の要件としてSP側のセッションが削除されればよく、他のSPやIdPでのセッションの削除は「ベストエフォート」とされています。

運用の問題

SSOの運用で発生する問題のいくつかの例を解説します。

セキュリティー設定

SSOの設定は例えば以下のような項目があります。

各種バリデーション
Cookieの取り扱いポリシー
各種タイムアウトの設定
ユーザを特定するために使う属性の定義とそれを利用した設定
メッセージの暗号化

全体的にSSOのセキュリティーと有用性に関わるものが多数あります。OSのシステムライブラリー、Shibbolethの依存ライブラリー、IdPのソフトウェアさらにはたまにSPのソフトウェア自体でも発見される脆弱性への対応により、必須の設定が変わったり、上記項目のパラメータを変更する必要があることもあります。ですので全てのパラメータを理解する必要があり、設定と仕様の変更の影響をIdPとSPの管理組織の間で情報共有し合意する必要があります。

証明書更新

SPとIdPは互いに送るSAML2メッセージを、互いにバックチャネルで検証して伝えた公開鍵証明書を使って電子署名し、場合によっては暗号化もします。鍵が有効期限に近づいたらロールオーバーというサービスに影響を与えない方法で交換するプロセスがあるので、このプロセスを正しく実施する必要があります。

ロールオーバーを行えないIdPもあり、もしくはIdPを運用する組織が何かの理由でロールオーバーの利用を望まないこともあります。その場合は、IdPと全てのSPが同じタイミングで鍵を切り替えるサービス停止メンテナンスを計画し実施する必要があります。

バージョンアップ

SPやIdPのソフトウェアのマイナーなバージョンアップはほとんどサービスに影響なく行えます。依存ライブラリー、OSのシステムライブラリーやプログラムのセキュリティー脆弱性対応もほとんどサービスに影響なく対応可能です。

ただし、バージョンアップで挙動変更やその他の影響がありそうかどうかはケースバイケースで判定する必要があり、必要に応じてサービスへの影響を最小限にするためにメンテナンスをIdP管理組織との協力で計画します。

メジャーバージョンアップ

メジャーバージョンアップは、デフォルト設定の変更や、既存の設定への大きな変更を含む場合があります。そのような場合社内で検証しますがIdP管理組織の協力も必要になることがあります。そしてユーザに事前に機能の変更点、挙動変更を充分案内した上でメンテナンス期間を設けて実施します。

まとめ・将来に向けて

Shibbolethを使ったSSOは2013年から運用中です。その時の最新バージョン2.3.1から様々なセキュリティー面、ウェブ標準の発展などに伴う機能面の変更が続いております。 ShibbolethのSPは開発者の方針で最新版のサポートしか行われていないので、朝日ネットはセキュリティー脆弱性対応、マイナー・メジャーバージョンアップを全ての環境でお客様の適切な時間に合わせて素早く実施します。

メタデータ管理改善

お客様のIdPと共有するサービス定義、いわゆる「メタデータ」は現在ほぼ自動で生成していますが、生成したXMLファイルはただウェブサーバに置いて通常のURLとしてアクセスしてもらう仕組みです。将来的にはメタデータファイルの検証や、対話的な変更管理などをウェブ上で行えるメタデータ管理システムを導入する方針で、これにより管理を用意かつ確実に行えるようになります。

「manaba」のフェデレーション利用に向けて

「manaba」でSSOを使うと、ほとんどは設定済みの決まったIdPのログイン画面へ飛びますが、一般にはIdPをプルダウンメニューから選択して該当のIdPのログイン画面へ飛ぶという機能があり、「manaba」でも実装可能です。この「フェデレーションSSO」機能によって、他組織のユーザが同じ「manaba」を利用することもできます。しかし、現在その要望は少ないですし「manaba」はドメイン毎にユーザを区別していないのでお客様側の調整と管理の負担が発生します。ですので将来的には「manaba」をフェデレーション可能にまで拡張するアプリケーション開発を行うことで、SSOで可能なさまざまなフェデレーション機能を充分活用できるようになるでしょう。

さらに実装する予定の連携とカスタム設定

ShibbolethのSPをデプロイすると、通常は最もサポートされている標準SSOの一つであるSAML2プロトコルが使われます。しかし、他にも有名もしくは実績が豊富なプロトコルが増えましたので将来的にはサポート対応範囲を広げる予定です。

一部のプロトコルはすでにShibbolethのSPでサポートされており、他にも拡張モジュールまたはカスタムのプログラミングをすれば使えるものがありますが、一部まだサポートされておらずShibbolethとは別のアプリケーションが必要なものもあります。将来のShibbolethでサポート範囲がさらに広がる可能性もあります。特にモバイルアプリケーションにはOpenID Connectのサポートが最重要です。

プロトコルの例：

SAML1.1: サポートあり
SAML2.0: サポートあり
WS-Federation (ADFS): サポートあり
WS-Trust 1.3: サポートなし
OpenID 1: サポートなし
OpenID 2: サポートなし
OAuth: サポートなし
OpenID Connect: サポートなし（連携は可能）
CAS: サポートなし（連携は可能）

上記のトピックの他にも沢山あります。 SSOの実装、維持、改善、運用の進化は必要に応じて普及していくことから随時課題が発生します。

最後に

前後編と記事をお読み頂きありがとうございます。 SAML2を使用したSSOの技術と運用について少しでも理解を深めて頂けたのであれば幸いです。 SSOについて興味を持った方は是非「参考資料」からSSOの標準・方針からより深い技術的側面まで調べてみてください。大学と連携している朝日ネットのLMS製品「manaba」ではSSOの技術活用がますます拡大する傾向にあるので、今後また他のポイントについて記事を公開させていただければと思います。