【図解】シングルサインオンの仕組みと実装例、製品例、メリット、セキュリティ

スポンサーリンク
スポンサーリンク

シングルサインオン(SSO)とは

一般的なシステムでは、各サーバ毎にユーザIDとパスワードを各サーバが持っています。AD連携、LDAP連携や、さらにそれを束ねる『統合ID管理』ソリューションによって、IDパスワードを共通化することもできますが、この場合でも各サーバ利用時にログインプロセスが必要になります

シングルサインオン環境を構築すると、通常は各々で認証が必要な複数システム(サーバ)に、1つ認証したら他の全てのシステムでは認証プロセス無しにログインできるようになります

Windows の SSO (ActiveDirectory)

企業内システムで一番身近な SSO は ActiveDirectory です。ドメイン参加したWindows端末にて、ActiveDirectoryに登録されたドメインユーザでログインすると、Kerberos というプロトコルで電子チケットが払い出され、以降は電子チケットを提示するだけで、『ファイルサーバ』や『統合Windows認証の設定がされたExchangeサーバ』、『ADFS(ActiveDirectory Federation Service)連携サーバ』といった様々なWindowsサーバへ認証無しでログインできます。

電子チケットにはユーザ情報が書かれていますので、そのユーザの権限でそのシステムを利用することができます。ただし、SSOとなる条件として、『クライアントPCがドメイン参加していること』や『Webアクセスには InternetExplorer を使うこと』といった条件があります。

スポンサーリンク

ActiveDirectory の中核サーバである”ドメインコントローラ“は 主に “Kerberos” や “LDAP” といったプロトコルをサポートすることで SSO を実現します。実は Linux でも OpenLDAP と GSSAPI を使って同様に “Kerberos” と “LDAP” をサポートし、Linux端末向けの SSO を実装させることができます

ですが近年ではWebアプリケーションの発達により、それ以外のアプリケーションでSSOを実装することが少ないです。

逆に言うと、シングルサインオンは(ActiveDirectoryを除いて)もはやWebアプリケーションのためのものになりつつあります

エージェント型・リバースプロキシ型のWebアプリケーションSSO

昔からあるWebアプリケーションのためのSSOとしては、以下の2つがあります。

  1. エージェント型
  2. リバースプロキシ型

エージェント型

エージェント型はWebサーバにエージェントプログラムをインストールし、Webアプリケーションの認証をエージェントに託すようにカスタマイズします。このカスタマイズは必ずできるとは限らないので事前に確認が必要です。

認証処理を託されたエージェントは、クライアントから認証済Cookieが提示されなければ”未認証状態”と見做し、認証を要求します。認証成功したらその情報(端末を識別する情報とユーザID)を”SSOサーバ”へ格納し、SSOサーバはエージェントに認証済Cookieを発行します。そしてエージェントからクライアントに認証済Cookieが返され、そのクライアントは以降はその認証済Cookieを提示すればエージェントが認証済と見做してくれます。

スポンサーリンク

なおSSOサーバは、認証情報をローカルに持つパターンもありますし、LDAPサーバ等に聞きに行くパターンもあります。

リバースプロキシ型

リバースプロキシ型は、全ての連携先サーバへのアクセスが、リバースプロキシサーバ経由になります。一度ポータルサーバ(リバースプロキシサーバと同居可)へログインすると、認証済Cookieが発行され、その認証済Cookieを提示すれば後はリバースプロキシサーバが連携先サーバへ認証情報を送ってくれるため、クライアントはIDパスワードを入力すること無く、ログイン状態になります。

なお、連携先Webサーバ側はカスタマイズは不要ですが、例えば以下のいずれかのような設定にする必要があります。

  1. http GETやPOSTでID情報を送ればそのユーザ権限で操作できる
  2. 認証画面を(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等)で認証させることはセキュリティ上の理由から通常は行いません。

ですが近年ではクラウドサービスの発展が目覚ましく、このようなサービスへのシームレスな連携が求められてきました。

もう1つは規格化されていないことによる適合性の不確かさです。前述の通り、エージェント型ではアプリケーションの認証モジュールのカスタマイズができるかどうかが不明確、リバースプロキシ型では動的なリンク・ディレクトリ構成に対応できるかどうかが不明確、といった問題です。

これらの課題の解決策として、SAML(Security Assertion Markup Languageの略。読み方:さむる)という規格が登場しました。

SAML 規格の主要コンポーネントとしては IdP (ID Provider)SP (Service Provider) の2つがあります。SPとはログイン後に見せるWebコンテンツを持つサーバのことで、認証モジュールがSAMLに対応したものを指します。IdP とは「認証Cookieを発行したり、そのユーザの属性:属性値をSPへ送ったり、認証状態を保持したりする」サーバのことです(エージェント型やリバースプロキシ型でいう SSOサーバに該当します)。

SP(例えばクラウドメールサービスの Office365 )で認証を行おうとした場合、httpリダイレクトにより自組織の IdP へ飛ばされ、そこでログインを行います。ログインが成功した場合はクライアントにAssertion(アサーション)と呼ばれるある種のセキュリティトークンを発行し、クライアントは再度httpリダイレクトによりSPへ戻され、その際にAssertionを提示することでそのサーバへログインできます。以降はそのAssertionを提示すれば他のサーバへログイン可能となります。

スポンサーリンク

このアサーション等の認証情報は秘密裏に行われなければなりませんが、SAML規格としては暗号化して防ぐ仕組みを決めていません。ですが TLS による暗号化、つまりhttpsで暗号化することが推奨されています。

このSAML規格の登場により、『SAML認証に対応している』Webアプリケーションでは、連携が可能であることが事前に明確に分かるようになりました。

このSAMLに対応したものとして、オープンソースの OpenAM があります。

フェデレーション (Shibboleth認証)

先程の例で記載した通り、Office365 は1企業専用ではなく、複数の企業が共有することができます。つまり認証リソースだけはSAMLにより各企業で用意し、他のリソース(CPU/メモリ/HDD(メール領域)/サービス)についてはクラウド側のものを他の企業と共用で使うことができるのです。

クラウドメールにおいてはコンテンツ(メール)は共有してはならないですが、この SAML の仕組みを利用して、コンテンツまで共有させるものもあります。このような構成をフェデレーションと言います。

例えば大学等のアカデミック機関のフェデレーションとして『学認(GakuNin)』があります。大学間で情報を共有するためのものです。

https://www.gakunin.jp/

この学認では SAML を使ってより具体的な実装を示した Shibboleth認証が使われています。SAMLに無く、Shibbolethで定義されている特徴として、所属組織を尋ねるプロセスWAYF(Where Are You From?)があります。

SAMLではどのように所属組織を識別するかは決まっていませんが、実装として識別子をSP側のURLに埋め込むか、ログインユーザの後ろに@と識別子を付け加えるか、あるいはその両方が為されることが多いです。

Shibbolethではログイン画面にずばりその所属組織をプルダウン等で選択させます。例えば以下のSPのようなログイン画面になります。

https://eduroamshib.nii.ac.jp/

所属組織を指定してログインボタンを押した後はSAMLのプロセスと同様で、その組織のIdPへ飛び、そこで認証に成功すると再度SPに戻り、Assertionを提示することでログインが為されます。

その他の SSO (OpenID , OAuth)

今まで話してきたSSOは主に企業や研究機関等のいわゆる法人向けのものですが、近年では個人向けのSSOも発展しています

例えば「Yahoo ID でログイン」だとか「facebook でログイン」といった表示をするアプリケーションが増えていますが、これはこれらの技術を使っています。

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の宣伝を投稿する、といったこともできてしまいます。

スポンサーリンク
スポンサーリンク
スポンサーリンク

シェアする

  • このエントリーをはてなブックマークに追加

フォローする

スポンサーリンク
スポンサーリンク

Comment

  1. ひろ より:

    分かり易い図解ありがとうございます!
    エージェント型の解説ですが、WebアプリB側のエージェントの動作も図解してもらえるとうれしかったかもです。アプリAの初回アクセス時にアプリBにも認証Cookieが発行されるわけじゃないですよね?(それはできないと思うで)とすれば、アプリBがどうやって認証済みを確認するのか?の説明がないと、SSOの説明としては不足するような気がするのです。これだとただ単にアプリAがログインしただけのような…

    • nesuke より:

      ひろさん
      コメントありがとうございます。そしてご指摘ありがとうございます。
      たしかに表現が分かりにくかったので図を修正してみました。同じアプリでも別のWebアプリでも同じ動作になります。つまり、アプリAで払い出された認証CookieはアプリBにも流用され、その背後のSSOサーバで「どのCookieがどのユーザのものか」を識別し、認証します。

      まだ気になる点や不明点などありましたら、ご指摘頂けるとありがたいです。

      今後も当サイトを宜しくお願い致します。

      • ひろ より:

        “アプリAで払い出された認証CookieはアプリBにも流用され” というところですが、たいがいのSSO解説で同じように説明されているのですが、それが可能になるのは、アプリAとBが同じdomain指定のcookieを共有できるときのみですよね?アプリAとBが同じdomainにあるのなら、そもそもSSOサーバーやエージェントが登場しなくてもSSOが可能になると思うのです。domainが異なれば、アプリAが認証済みでもアプリBにcookieが届くことはないので、そこにエージェントが登場してくると思うので、その部分の説明があると他とは違う説明になるような気がしました。

        • nesuke より:

          ひろさん
          またまたコメントありがとうございます。私の勉強不足かもしれませんが、私の理解とは異なりますね。

          > それが可能になるのは、アプリ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が実現できていたので、エージェントの定義を誤解していたみたいです。お手数おかけしました。