スライド

そのうち公式から録画が公開されるはずなので、そちらも公開され次第貼ります。

発表概要

現在開発を進めている弊社の認証基盤サービスでは、「SessionStore を RedisStore にして各アプリケーションで共有する」ことでシングルサインオン・サインアウトや認証情報の連携を実現しています。

この手法について、どうやって実現しているか・どうしてその構成にしたか・細かいTipsなどをまとめた発表をさせていただきました。

認証基盤であまり推奨されないであろう独自実装寄り、かつ Rails アプリ間でしか利用できない方法ということで用途は相当に狭いんですが、ありがたいことに採択いただくことができました。

CfP応募内容

以下が投稿したCfPの「レビュー委員会向け」部分の全文です。

詳細

(あなたのプロポーザルについての概要、成果、対象者など、関連する詳細があれば含めてください。) 本セッションでは、複数の自社サービスを展開する際に課題となる「シングルサインオンを実現する認証基盤サービス」について、OpenID Connectなどの仕組みを使わずドメイン指定Cookie と Rails の Redis Session Store のみを用いて実現した事例を提案します。これは多少制約があるもののシンプルで扱いやすい仕組みで、その割にはインターネット上で事例紹介をあまり見ないものです。

おおまかな発表の構成は以下のとおりです。

はじめに、複数の自社サービスを展開する際になぜ認証基盤サービスが求められるのかを、シングルサインオンやサービス横断でのデータ名寄せなどの観点から説明します。次に、サービス横断の認証基盤サービスを実現する選択肢として OpenID Connect などの規格に合わせた自社開発, Auth0 などの IDaaS を利用する方法を紹介し、それぞれのメリット・デメリットを挙げます。この上で、ドメイン指定CookieにセッションIDを保持し、各アプリケーションから共通して参照できるRedisにセッション情報を格納する手法を紹介します。これは親ドメインが共通するRailsアプリケーション間でのみ利用可能な手法であり、ドメイン指定Cookieを利用するためいくつかのデメリットがあるものの、セッション管理周りの実装が単独のRailsアプリケーションとほぼ変わらないためシンプルに扱えるというメリットがあります。またセキュリティ上の懸念も単独のRailsアプリケーションと大きく変わらないことをセキュリティレビューで確認しており、この内容についても紹介します。

本手法の具体的な事例として、自社で開発した認証基盤サービスの構成を紹介します。これは認証にRodauth Railsを利用し共有Redisにセッション情報を格納したうえで、各アプリケーション共通のドメインを指定してCookieを設定することでセッション共有を行う仕組みになっています。また各アプリケーションで必要になる「セッション変数からのユーザー取得」「セッション変数競合を避けるためのprefix付与」などを独自gemとして切り出しているため、このあたりの工夫についても紹介します。また実際に運用するなかで感じたメリット・デメリットを率直に共有し、「この方法が絶対におすすめ」とは言い切れない理由も解説します。

本セッションは認証の必要な自社サービスをRailsで運用している開発者を対象にしています。特に、今後複数サービス展開を行うようなスタートアップ規模の開発者を想定していますが、認証に関する知識やgemによる共通化の工夫などは広いRailsエンジニアにとって興味を持ってもらえる内容だと思います。

ピッチ

(このプロポーザルを採択すべき理由と、あなたがそのテーマで講演するにふさわしい理由を説明してください。) 認証基盤は複数プロダクトを抱える企業にとってほぼ必須の存在ですが、自社セキュリティの根幹に関わるため詳細な事例紹介が少なく、また大企業ではマイクロサービスを前提とした仕組みになりがちです。一方で、多くのRailsエンジニアが関わるRailsアプリケーションでは、もっと単純かつ扱いやすい認証基盤が求められているのではないでしょうか。ドメイン指定Cookieを利用した認証状態の共有自体は新しいアイディアではありませんが、具体的な仕組みの解説や事例紹介は少なく、Railsに特化した構成も含めて知見を共有することは多くのRailsエンジニアの参考になるはずです。(実際自分がこの構成を事前に学べていたなら、自社の認証基盤構築を大きくショートカットできたと思います)

私は自社の認証基盤をどうするか他社事例調査や各種認証規格・認証サービスの調査を行ったうえで、現状必要になる機能の範囲であれば上記手法で十分だと判断し、外部のセキュリティ診断企業にセキュリティレビューを依頼・実施したうえで認証基盤の実装までを通して実施しました。これは認証基盤の発表を行うのにふさわしい経験になっていると自負しています。

採択いただいた一事例ではありますが、来年 CfP へ応募する方の参考になれば幸いです！

発表した感想

認証・認可・セッション管理あたりの前提知識を揃えたかったので、発表の前半に例え話を多めに入れて概念を説明しました。その甲斐あってか普段プログラミングをしないデザイナーさんにも「内容がわかりやすかった」と言っていただけてよかったです。

一方で他の方から「なんでRedisStoreである必要があるかわからない」などのご意見もいただき、もう少し技術選定の根拠の話を深堀って入れるべきだったかなーという反省があります。Cookie Storeだと暗号化キーを共通化する必要があって厳しいんですがそれ以外のStoreならだいたい問題ないので、ここはタイトルの付け方をミスった部分でもありますね。

とはいえスケジュール最後の方であまり時間なかったにもかかわらずいろいろな方から発表のフィードバックや質問をいただけたので、登壇させていただけてよかったです。

来年も認証周りでCfPを出したいと思います！