シングルサインオン(SSO)とは
一般的なシステムでは、各サーバ毎にユーザ ID とパスワードを各サーバが持っています。
AD 連携、LDAP 連携や、さらにそれを束ねる統合 ID 管理ソリューションによって、ID / パスワードを共通化することもできますが、この場合でも各サーバそれぞれに対してログインプロセスが必要になります。
シングルサインオン環境を構築すると、通常は各々で認証が必要な複数システム (サーバ) に、1 つ認証したら他の全てのシステムでは認証プロセス無しにログインできるようになります。
Windows の SSO (ActiveDirectory)
企業内システムで一番身近な SSO は ActiveDirectory です。
ドメイン参加した Windows 端末にて、ActiveDirectory に登録されたドメインユーザでログインすると、Kerberos というプロトコルで電子チケットが払い出され、以降は電子チケットを提示するだけで、『ファイルサーバ』や『統合 Windows 認証の設定がされた Exchange サーバ』、『ADFS (ActiveDirectory Federation Service) サーバ』といった様々な Windows サーバへ認証無しでログインできます。
電子チケットにはユーザ情報が書かれていますので、そのユーザの権限でそのシステムを利用することができます。ただし、SSO となる条件として、『クライアント PC がドメイン参加していること』などの条件があります。
ActiveDirectory の中核サーバである"ドメインコントローラ"は 主に "Kerberos" や "LDAP" といったプロトコルを利用することで SSO を実現します。(実は Linux でも OpenLDAP と GSS-API を使って同様に "Kerberos" と "LDAP" をサポートし、Linux端末向けの SSO を実装させることができます。)
Kerberos や統合 Windows 認証については併せて以下も参照下さい。
この ActiveDirectory による SSO ではファイル共有 (CIFS) サーバ等 Windows サーバ全般で様々なサービス、プロトコルと連携できます。
ですが近年では Web アプリケーションの発達により、それ以外のアプリケーションで SSO を実装することが少ないです。
逆に言うと、シングルサインオンは (ActiveDirectoryを除いて) もはや Web アプリケーションのためのものになりつつあります。
エージェント型・リバースプロキシ型のWebアプリケーションSSO
昔からある Web アプリケーションのための SSO としては、以下の 2つがあります。
- エージェント型
- リバースプロキシ型
エージェント型
エージェント型は Web サーバにエージェントプログラムをインストールし、Web アプリケーションの認証をエージェントに託すようにカスタマイズします。このカスタマイズは必ずできるとは限らないので事前に確認が必要です。
認証処理を託されたエージェントは、クライアントから認証済 Cookie が提示されなければ"未認証状態"と見做し、認証を要求します。
認証成功したらその情報 (端末を識別する情報とユーザ ID) を "SSO サーバ" へ格納し、SSO サーバはエージェントに認証済 Cookie を発行します。そしてエージェントからクライアントに認証済 Cookie が返され、そのクライアントは以降はその認証済 Cookie を提示すればエージェントが認証済と見做してくれます。
なお SSO サーバは、認証情報をローカルに持つパターンもありますし、LDAP サーバ等に聞きに行くパターンもあります。
リバースプロキシ型
リバースプロキシ型は、全ての連携先サーバへのアクセスが、リバースプロキシサーバ経由になります。
一度ポータルサーバ (リバースプロキシサーバと同居可) へログインすると、認証済 Cookie が発行され、その認証済 Cookie を提示すれば後はリバースプロキシサーバが連携先サーバへ認証情報を送ってくれるため、クライアントは ID / パスワードを入力すること無く、ログイン状態になります。
なお、連携先 Web サーバ側はカスタマイズは不要ですが、例えば以下のいずれかのような設定にする必要があります。
- http GET や POST で ID 情報を送ればそのユーザ権限で操作できる
- 認証画面を (html 内の特定文字列等で) 識別し、認証画面の場合は認証情報をリバースプロキシサーバが http GET や POST で送りつけることでログイン認証が為される
1 のパターンのサーバについては、リバースプロキシサーバからのみアクセスを受け付けるようにする必要があります。もしクライアントから直接そのサーバにアクセスできると、認証無しでそのユーザ権限の操作ができてしまうため、セキュリティ上の問題となるためです。
2 のパターンであれば、直接アクセスすれば ID / パスワードが要求されますので、問題にはなりません。(シングルサインオンにはなりませんが。)
このリバースプロキシ型の大きなデメリットとしては、構築作業の負荷が高く、構築中に連携できないことが分かるケースがあることです。
クライアントから見たら宛先 URL がリバースプロキシサーバになるのですが リバースプロキシから連携先 Web サーバへのアクセスは宛先 URL が連携先 Web サーバになります。そのため、動的に生成されるリンクを使うような場合にうまくいかないケースがあります。
例えば動画配信サーバのセキュリティ機能として、動画が誰からでも見られてしまうような状態を防ぐために、動画の URL を動的に生成する、といった動作をするものもあります。具体的には、動画のリンクをクリックしたときにセッション ID を動的に生成すると同時に動的にディレクトリを生成し、http でセッション ID を提示した場合にその URL へリダイレクトする、といった複雑な動作をする場合、設定ではうまく吸収できず、SSO によるログインはできるけど肝心の動画が見れない、といった状態が発生します。
またその他のデメリットとして、負荷がリバースプロキシサーバに集中するため、パフォーマンスに注意が必要であることも挙げられます。
これらエージェント型とリバースプロキシ型の両方式を実装する製品として、HP の IceWall が挙げられます。
SAML の登場
前述のシングルサインオンでは大きく2つの課題がありました。
1つは連携先サーバが自ドメイン(1企業内)に限られることです。
例えば Microsoft Office365 や GoogleApps / Gmail といったインターネット上のクラウドメールサービスを、自社内で構築した認証サーバ (AD や LDAP 等) で認証させることはセキュリティ上の理由から通常は行いません(Cookie は外部ドメインの Web サーバに送られないように制限を掛けるのが常識)。
ですが近年ではクラウドサービスの発展が目覚ましく、このようなサービスへのシームレスな連携が求められてきました。つまり、異なるドメイン間での SSO が期待されるようになったのです。
もう 1 つは規格化されていないことによる適合性の不確かさです。
前述の通り、エージェント型ではアプリケーションの認証モジュールのカスタマイズができるかどうかが不明確、リバースプロキシ型では動的なリンク・ディレクトリ構成に対応できるかどうかが不明確、といった問題です。
これらの課題の解決策として、SAML (Security Assertion Markup Languageの略。読み方：さむる) という規格が登場しました。
SAML 規格の主要コンポーネントとしては IdP (ID Provider) と SP (Service Provider) の2つがあります。
IdP とは『ユーザ認証成功後にAssertion (認証したユーザ、そのユーザの属性＆属性値、期限情報、発行IdPとその署名などから構成されるセキュリティトークン) を発行する』サーバのことです (エージェント型やリバースプロキシ型でいう SSO サーバに該当します)。
SP とは、ログイン後に見せる Web コンテンツを持つ Web サーバのことで、認証方式が SAML に対応したものを指します。有効な Assertion を提示された場合、そのユーザに応じて(属性＆属性値によって)適したコンテンツを閲覧させます。
SAML のシーケンスや Kerberos との比較などの詳細は以下をご参照ください。
ADFS の仕組みと構成例
IdP と SP の実装として有名なクラウドメールサービス Office365 と ADFS の例を見ていきましょう。
SP ( Office365 ) で認証を行おうとした場合、http リダイレクトにより自組織の IdP (ADFSサーバ) へ飛ばされ、そこでログインを行います。(インターネット経由の場合、ドメイン参加が必須である ADFS の外部公開を避けるため、ドメイン非参加の WAP によるリバースプロキシ経由になることが多いです。)
ログイン認証のためのユーザ情報は AD DS (いわゆるドメインコントローラ)のデータベースを使います。ADFS が AD DS にログイン成否を聞きに行くのです。
ログインが成功した場合、IdP はクライアントに Assertion (アサーション) を発行し、クライアントは再度 http リダイレクトにより SP へ戻され、その際に Assertion を提示することでそのサーバへログインできます。以降はそのAssertionを提示すれば他のサーバへログイン可能となります。
このアサーション等の認証情報は秘密裏に行われなければなりませんが、SAML 規格としては暗号化して防ぐ仕組みを決めていません。ですが TLS による暗号化、つまり https で暗号化することが推奨されています。ADFS では加えてデジタル証明書による暗号化/復号化も行っています(トークン暗号化解除証明書)。
この SAML 規格の登場により、『SAML 認証に対応している』Web アプリケーションでは、連携が可能であることが事前に明確に分かるようになりました。
この SAML に対応したものとして、他にはオープンソースの OpenAM があります。
フェデレーション (Shibboleth認証)
先程の例で記載した通り、Office365 は 1 企業専用ではなく、複数の企業が共有することができます。つまり認証リソースだけは SAML により各企業で用意し、他のリソース (CPU/メモリ/HDD (メール領域) /サービス)についてはクラウド側のものを他の企業と共用で使うことができるのです。
クラウドメールにおいてはコンテンツ (メール) は共有してはならないですが、この SAML の仕組みを利用して、コンテンツまで共有させるものもあります。このような構成をフェデレーションと言います。
例えば大学等のアカデミック機関のフェデレーションとして『学認 (GakuNin)』があります。大学間で情報を共有するためのものです。
この学認では SAML を使ってより具体的な実装を示した Shibboleth 認証が使われています。SAML に無く、Shibboleth で定義されている特徴として、所属組織を尋ねるプロセスWAYF (Where Are You From?) があります。
SAMLではどのように所属組織を識別するか (あるユーザの認証を、どのIdPに聞きに行けばよいか)、その方法については規格では指定しておらず、実装に委ねられています。
実装として多いのは、識別子を SP 側の URL に埋め込むか、ログインユーザの後ろに@と識別子を付け加えるか、あるいはその両方です。
Shibboleth の場合はログイン画面にずばりその所属機関をプルダウン等で選択させます。例えば以下の SP のようなログイン画面になります。
所属機関を指定してログインボタンを押した後は SAML のプロセスと同様で、その組織の IdP へ飛び、そこで認証に成功すると再度 SP に戻り、Assertion を提示することでログインが為されます。
OpenID と OAuth
今まで話してきた SSO は主に企業や研究機関等のいわゆる法人向けのものですが、個人向けの SSO も登場しました。
例えば「Yahoo ID でログイン」だとか「facebook でログイン」といった表示をするアプリケーションが増えていますが、これらは OpenID や OAuth の技術を使っています。
OpenID
OpenID は (認証・認可・属性情報を扱うSAMLとは異なり) 認証情報だけを提供します。Yahoo や facebook が用意したサーバが IdP 兼 SP となり、他の SP へ ID 認証機能を提供するのです。
その他の SAML と異なる点としては、IdP と SP 間の事前の信頼関係構築が無いこと、アサーションのようなセキュリティトークンを利用しないことが挙げられます。
低負荷で手軽に実装できるといったメリットがある反面、セキュリティ強度が低くなるというデメリットがあります。
OAuth
OAuth は認証技術ではなく、認可技術です。SAML や OpenID と異なり、ID 認証機能だけでなくコンテンツそのものを提供します。具体的に言うと、『facebookでログイン』ボタンで SP へログインした場合、その SP はその人の facebook アカウントへ自由にアクセスできるようになります。『facebook の情報を使っていいよ』と認可するのです。これは facebook への鍵を SP へ渡す行為に等しいです。
つまり、勝手に facebook にその SP の宣伝を投稿する、といった権限を与えることもできてしまいます。
OpenID Connect
近年では Open ID と OAuth2 を統合した OpenID Connect という規格が SAML と並んで主流になってきています。
OpenID 2.0 の運用性やセキュリティに関する課題を改善するなど、OpenID の流れは入っているものの、一応 OAuth2 (OAuth version2) の拡張仕様という位置付けです。
SAML と比べて実装や運用が楽である、という利点があり、企業向けサービスにも受け入れられてきており、ADFS では SAML と OpenID Connect (OAuth2) の両方を使うことができます。
コメント
分かり易い図解ありがとうございます！
エージェント型の解説ですが、WebアプリB側のエージェントの動作も図解してもらえるとうれしかったかもです。アプリAの初回アクセス時にアプリBにも認証Cookieが発行されるわけじゃないですよね？（それはできないと思うで）とすれば、アプリBがどうやって認証済みを確認するのか？の説明がないと、SSOの説明としては不足するような気がするのです。これだとただ単にアプリAがログインしただけのような…
ひろさん
コメントありがとうございます。そしてご指摘ありがとうございます。
たしかに表現が分かりにくかったので図を修正してみました。同じアプリでも別のWebアプリでも同じ動作になります。つまり、アプリAで払い出された認証CookieはアプリBにも流用され、その背後のSSOサーバで「どのCookieがどのユーザのものか」を識別し、認証します。
まだ気になる点や不明点などありましたら、ご指摘頂けるとありがたいです。
今後も当サイトを宜しくお願い致します。
“アプリAで払い出された認証CookieはアプリBにも流用され” というところですが、たいがいのSSO解説で同じように説明されているのですが、それが可能になるのは、アプリAとBが同じdomain指定のcookieを共有できるときのみですよね？アプリAとBが同じdomainにあるのなら、そもそもSSOサーバーやエージェントが登場しなくてもSSOが可能になると思うのです。domainが異なれば、アプリAが認証済みでもアプリBにcookieが届くことはないので、そこにエージェントが登場してくると思うので、その部分の説明があると他とは違う説明になるような気がしました。
ひろさん
またまたコメントありがとうございます。私の勉強不足かもしれませんが、私の理解とは異なりますね。
> それが可能になるのは、アプリAとBが同じdomain指定のcookieを共有できるときのみですよね？
はい、この部分は認識合います。この課題を解決するために、SAMLが登場したという認識です。SAMLではCookieに頼らず、ドメイン間で信頼関係を結んだ後に、ドメイン間で認証情報を(httpsで)やり取りすることでセキュリティを保ちます。
> アプリAとBが同じdomainにあるのなら、そもそもSSOサーバーやエージェントが登場しなくてもSSOが可能になると思うのです。
この部分は私の理解と異なります。ActiveDirectoryのドメインのことを仰っているのであれば統合Windows認証等によりSSOが可能になりますが、Cookieで言うドメインは別の概念なので、SSOサーバ無しでSSOが可能になることは無いと思っているのですが、いかがでしょうか。
あ～なるほど、エージェント方式ではdomainを跨げないということですね！（ちゃんと明確に説明されていましたね；）すみません、そこを誤解していました。自分が作成していたasp.netなwebアプリでは、特にエージェントとかSSOサーバーを意識せずにSSOが実現できていたので、エージェントの定義を誤解していたみたいです。お手数おかけしました。
asp.netのSSOは知らなかったです。
asp.netのライブラリがSSOサーバ兼エージェントとなり、認証DB自体はActiveDirectory等で共有化する感じなんですかね。。
いずれにせよ、勉強になりました。ありがとうございます。