こんにちは。サイオステクノロジー OSS サポート担当 山本 です。
今回は keycloak (というか SSO) ってどんなもの？というお題でざっくり話してみようと思います。
今日、インターネットを使用しているのであれば SSO の恩恵を受けていないということは稀かと思いますし、どんなものかもある程度以上知っている方も多いかと思います。
が、個人的に keycloak を調べてみる機会があって合わせて周辺の情報を確認しなおしたので、折角なのでざっくりとまとめてみようと思った次第です。
ぼんやりふんわりとした理解の助けになれば幸いです。
■SSO ってなんだ？
SSO (シングルサインオン) は、その名のとおりサインオン (=ログイン、サインインなど) に関する技術で、主に Web サービスや Web アプリケーションで活躍するものです。
改めてお話しするまでもないかとは思いますが、サインオンはそのユーザを識別する何らかのキー (例えば、「ユーザ名 + パスワード」など) によってユーザを識別し、そのユーザ向けのサービスを提供したり、そのユーザ自身が登録した情報にアクセスできるようにしたりするための処理です。
例えば、電子メールサービスを扱うならばそのユーザ宛てのメールやそのユーザ自身が作成したメールだけを見れるようにしなければいけませんし、電子書籍サービスを扱うならばユーザが購入した書籍を識別できなければいけません。
この他にも様々な観点において、Web サービスなどはユーザを識別できなければ立ち行きません。
このため、サインオンという考え方は Web サービスなどにおいて非常に重要なものとなります。
…と改めて前置きをしたところで、まずは SSO と普通のサインオンの違いを確認しておきましょう。
(以下では全てのサインオンは「ユーザ名 + パスワード」で行うものと仮定してお話しします。)
■通常のサインオンの場合
あるユーザが「HogeHoge メール」というサービスを利用しようとしたとします。
この場合、そのユーザは「HogeHoge メール」に登録した、「HogeHoge メール」用のユーザ名 + パスワードでサインオンを行なってサービスを利用することになります。
その後、そのユーザが「FugaFuga 動画」というサービスを利用しようとしたとしましょう。
そうしたら、そのユーザは別途「FugaFuga 動画」に登録した、「FugaFuga 動画」用のユーザ名 + パスワードでサインオンを行なってサービスを利用することになります。
……それはそうだろ、という感じですね。
このように、従来型の通常のサインオンでは使用するサービスごとに識別情報・認証情報の登録やサインオン操作が必要になります。
■SSO の場合
SSO では、”SSO 認証サーバ” などと呼ばれるいわゆる親玉的なモノが出てきます。
この「親玉」は様々な他のサービスと連携し、連携先のサービスのサインオン操作などを肩代わりします。
これにより、ユーザは「親玉」用の 1種類の認証情報 (「ユーザ名 + パスワード」など) だけでその「親玉」と連携しているあらゆるサービスを効率よく使うことができます。
大雑把なイメージでのお話にはなりますが、少し細かく見てみましょう。
■SSO の例1：サインオン操作の肩代わりと入力回数低減
あるユーザAが SSO 認証サーバ「PiyoPiyo 認証」と連携している「HogePiyo メール」というサービスを利用しようとしたとします。
そのユーザAが「HogePiyo メール」サービスを利用しようとすると、”「HogePiyo メール」から来た” という情報を付けた状態で「PiyoPiyo 認証」へ飛ばされます。
ユーザAは飛ばされた「PiyoPiyo 認証」で、「PiyoPiyo 認証」に登録した「PiyoPiyo 認証」用のユーザ名 + パスワードでサインオンを行ないます。
「PiyoPiyo 認証」でのユーザ認証に成功すると、「PiyoPiyo 認証」は
・「HogePiyo メール」に対して “(「PiyoPiyo 認証」の) ユーザ ID” などのようなユーザを識別する情報 (+ その他必要になる情報)
・ユーザAに対して「HogePiyo メール」のページに飛ばす処理
と、このユーザAが「HogePiyo メール」を使用する際に、このユーザAからのアクセスであると「HogePiyo メール」が識別できる何らかの手段・情報をそれぞれに送ります。
これで、このユーザAは無事「HogePiyo メール」サービスを利用することができるようになります。
ここで、このユーザAは「PiyoPiyo 認証」にしかサインオン処理を行なっていないのがポイントです。
さて、その後さらにこのユーザAが先と同じ SSO 認証サーバ「PiyoPiyo 認証」と連携している「FugaPiyo 動画」というサービスを利用しようとしたとします。
基本的な流れは先の「HogePiyo メール」の例と同じで、そのユーザAが「FugaPiyo 動画」サービスを利用しようとすると、”「FugaPiyo 動画」から来た” という情報を付けた状態で「PiyoPiyo 認証」へ飛ばされます。
さて、先ほどはここで「PiyoPiyo 認証」でサインオンを行ないましたが、このユーザAは先ほど「HogePiyo メール」を利用しようとした時に、既に「PiyoPiyo 認証」へのサインオンを済ませています。
このため、改めて「PiyoPiyo 認証」用のユーザ名 + パスワードを入力することなく「FugaPiyo 動画」を利用できる状態になるというわけです。
概ねこのような流れで、SSO を利用するとユーザは一度のサインオン操作で複数のサービスを利用できるようになります。
なお、サービス側はあくまでサインオンを肩代わりしてもらっているだけであり、サービス自体の情報 (「HogePiyo メール」の管理しているメール情報や、「FugaPiyo 動画」の購入履歴・利用プラン情報など) は別途そのサービス自体が管理することになります。
このような役割を担う SSO の仕組みとしては、Kerberos 認証、SAML、OpenID-Connect (OIDC) などが挙げられます。
■SSO の例2：ユーザ情報の共有
先の例を流用して、例えば「FugaPiyo 動画」で “「PiyoPiyo 認証」のメールアドレスでメールマガジン登録” という操作ができる場合のことを考えてみましょう。
この場合、「FugaPiyo 動画」は「PiyoPiyo 認証」に登録されているメールアドレスを取得する必要があります。
(SSO 認証サーバ「PiyoPiyo 認証」には、ユーザ情報としてメールアドレスも登録されているものとします。)
あるユーザAがこの操作を行うと、「FugaPiyo 動画」は「PiyoPiyo 認証」にこのユーザAのメールアドレスが必要な旨を伝えます。
もちろん、いくら連携しているとは言え「PiyoPiyo 認証」は（セキュリティ的に考えて）無条件でメールアドレスを渡すわけにはいきません。
そこで、「PiyoPiyo 認証」は “「FugaPiyo 動画」がユーザAのメールアドレスを取得しようとしているよ” という情報を含めた合わせ鍵を用意して、「FugaPiyo 動画」に渡します。
「FugaPiyo 動画」は「PiyoPiyo 認証」から受け取った合わせ鍵 (ユーザA用の部分) や、後で「FugaPiyo 動画」に戻る際のアドレスなどの情報をまとめて、ユーザAに送ります。
ユーザAに送られる情報には「PiyoPiyo 認証」に飛ばす処理も含まれているので、ユーザAは「PiyoPiyo 認証」に飛ばされます。（ユーザAが「PiyoPiyo 認証」にサインオンできていない場合、ここでサインオン操作をする必要があります。）
ユーザAが合わせ鍵を「PiyoPiyo 認証」に渡すと、「PiyoPiyo 認証」は合わせ鍵の内容を確認して、ユーザAに [「FugaPiyo 動画」にメールアドレスを渡すけど、いいのか？] と確認を行ないます。
ユーザAがこれを承認すると、「PiyoPiyo 認証」はこの合わせ鍵に「承認済み」フラグを記録し、ユーザAは「FugaPiyo 動画」に戻されます。
「FugaPiyo 動画」はユーザAが戻ってきたことを確認すると、改めて合わせ鍵を使って「PiyoPiyo 認証」にユーザAのメールアドレスを要求します。
「PiyoPiyo 認証」は合わせ鍵の正当性や「承認済み」になっているか、要求元が間違っていないかなどを確認した上で、問題がなければメールアドレスの情報を持っているリソースサーバに “「FugaPiyo 動画」にユーザAのメールアドレスを渡すように” という通達と合わせ鍵を、「FugaPiyo 動画」にはリソースサーバの場所と合わせ鍵を渡します。
そうして、「FugaPiyo 動画」はリソースサーバに合わせ鍵を持ってアクセスすることで、目的のユーザAのメールアドレスを得ることができます。
……行ったり来たりでややこしいですが、このほとんどは使い捨てのデータによる承認や確認処理で、
・ユーザAは SSO 認証サーバ「PiyoPiyo 認証」でサインオンと承認をしただけ
・やりとりされるのはユーザが許可したメールアドレスのみ
・実際にメールアドレスのやり取りをしているのは「FugaPiyo 動画」とリソースサーバのみ
なので、ユーザは少ない手間で、かつデータのやり取りはかなり安全に行なうことができます。
と、基本的には概ねこのような流れで、SSO によって SSO 認証サーバが連携する範囲で登録したデータをやりとりさせることができます。
ここではメールアドレスを例にしたためあまり便利そうには見えないかもしれませんが、例えば SNS の投稿を連携したり、荷物の宛先情報などを連携したり……などであればだいぶ便利そうに感じれる…ハズです。
このような役割を担う SSO の仕組みとしては、OAuth が挙げられます。
■SSO のメリットは？
さて、ゴチャゴチャ話してみましたが、結局 SSO というのは何が嬉しいのかを考えてみましょう。
まず、ユーザは認証情報の管理がラクになります。
SSO 認証サーバの連携する範囲内のサービス・アプリケーションで1回だけ認証処理をすればよく、当然覚えておく認証情報も1つだけで済みます。また、場合によってはユーザの入力した情報 (各種個人情報や SNS 等の投稿など) を別サービスから必要に応じて参照させることで、同じ情報を複数回入力する手間も削減することができることもあります。
旧来はサービス・アプリケーションごとに別々の認証情報を用意し、必要に応じて各サービスに別々で手動での情報入力を行う必要があったことを考えると、ユーザにとってはかなりラクになることでしょう。
SSO 認証サーバの管理者・連携先としては……
まず、組織内で複数サービスのサインオン処理の統合のために使っている場合、SSO 認証サーバのアカウントだけ管理すればよくなるので、個別のサービスごとにアカウント管理するよりもアカウント管理の手間が減る可能性が高いです。
外部の SSO 認証サーバと連携する場合だと、自システムに認証情報を保存しなくて済みます。このため、(その他の個人情報などを取得していなければ) 漏洩して困る情報を手元に置かなくて済むようになり、万が一自システムでの情報漏洩が出てしまった場合でも対ユーザへの被害が深刻になりにくい可能性が考えられます。また、ユーザ側の新規登録の手間が省かれるので、ユーザにサービス自体を触ってもらいやすくなる可能性も考えられます。
このように、認証の一元化による管理の容易さとユーザビリティの向上が見込めることが SSO のメリットと言えるでしょう。
ただし逆に、万が一 SSO 認証の認証情報が漏洩した場合、連携先のサービスなども含めて丸ごと不正利用される恐れがあります。
そのため、SSO 認証サーバ自体、および SSO 認証サーバの通信や SSO の認証情報には十全なセキュリティ対策が求められます。
（もっとも、SSO により管理を一元化することでより複雑な認証情報・認証方法を採用しやすくなったり、逆に SSO を使用していない場合にユーザが認証情報をメモして残したり使い回しをしたり…といったことを考えると、SSO のセキュリティリスクは高いというわけではありません。）
■keycloak ってなんだ？
keycloak は、正にここまでお話ししてきた “SSO 認証サーバ” の1種です。
SAML、OpenID-Connect (OIDC)、OAuth に対応しており、管理コンソールやユーザ連携、ユーザ制御などの機能を備えています。
今回は前置きが長かったので、管理コンソールとそれぞれ今回のお話の何をどれで設定するのかだけ確認します。
まず、デモ環境を立ち上げます。今回は手早く podman で作ってしまいましょう。
podman を導入して、以下のようなコマンドを実行すれば OK です。
$ podman run --name test -p 8080:8080 -e KC_BOOTSTRAP_ADMIN_USERNAME=admin -e KC_BOOTSTRAP_ADMIN_PASSWORD=admin quay.io/keycloak/keycloak:26.2.4 start-dev
(このコマンドはセキュリティ設定などを省いて動かせるデモ用・開発用の環境を作成するためのコマンドであり、実際に運用する環境を作る場合は絶対に使用してはいけません。)
そうしたら、任意のブラウザで以下のアドレスにアクセスしてみましょう。
http://(IP アドレス):8080/admin
サインオンの画面が表示されるので、サインオンしてみましょう。
初期ユーザのユーザ名/パスワードは、podman コマンドの “KC_BOOTSTRAP_ADMIN_USERNAME” と “KC_BOOTSTRAP_ADMIN_PASSWORD” で指定したものです。
(上記のとおりのコマンドだった場合、”admin” / “admin” です。)
サインオンに成功すると表示されるのが keycloal の管理コンソールです。
今回は、マークをつけてある今回お話ししたものに対応している3つの要素が何に対応しているかだけ、最後に確認したいと思います。
・Clients
この keycloak (=SSO 認証サーバ) と連携するサービス・アプリケーションやその連携方法などを設定します。
連携先のサービス・アプリケーション側でも別途この keycloak と指定した方法で連携するように設定する必要があります。
今回のお話では「HogePiyo メール」「FugaPiyo 動画」が該当します。
・Users
この keycloak による SSO 認証のユーザ情報 (認証情報など) を設定します。
今回のお話では「ユーザA」の認証情報が該当します。
・Realm (※ “master” となっているプルダウン部分)
設定する SSO 連携の「枠」です。keycloak では複数の Realm を持つことができます。
先述の “Client” と “User” などは Realm ごとに管理されます。
確認できたら、先ほど立ち上げた検証用の keycloak コンテナは念のため削除しておきましょう。
$ podman stop test $ podman rm test
■最後に
今回は SSO と keycloak の概要についてお話ししてみました。
SSO について長々とお話ししましたが、今日日インターネットを使用しているのであれば、恐らくは恩恵にあずかっているはずです。
そう、「google でログイン」「Apple でログイン」「Facebook でログイン」などのような「～でログイン」というアレです。アレこそが、SSO という技術の典型と言えるでしょう。
keycloak はそんな SSO の “親玉” の部分を担うサービスです。
例に挙げたような外部にまで連携する超大規模 SSO サービス……なんてものはまず新しく立ち上げることはないでしょうから、
基本的にはお話の途中でちらりと出した「組織内のサインオン処理の統合」のために使用するものと考えてもらえばよいでしょう。
