はじめに

NTTデータ先端技術株式会社にてアジャイル開発、並びに技術調査業務に従事している志田です。業務の中では技術担当としてプロジェクト開始後、並びにプロジェクト実施中に顧客や開発チームからの技術相談に乗ることが頻繁にあり、その中でもSSOに関して相談されることが多いです。このSSOの技術というものが所謂インフラに属する技術なのか、アプリケーションに属する技術なのかが曖昧で、本連載で取り上げているエンジニアの理想像やフルスタックエンジニアを考えるうえで良い題材だと思っています。今回は、このSSOの技術を例にとってインフラエンジニア、アプリケーションエンジニアの観点で技術を活用するためのコツを説明したいと思います。

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

SSO(シングルサインオン)は認証・認可に関わる技術、または環境そのものを指します。少々乱暴に説明すると、一度あるシステム、サービスにログインしたユーザが別のシステムにログインする際に、ログイン作業をスキップするための技術となります。この技術自体は古くからありますが、現時点ですとOAuth2.0をベースにしたOpenIDConnect1.0仕様を利用して、SSOを実現するのが最も一般的です。

  • シングルサインオンの概要

    シングルサインオンの概要

SSOを実現するためのやり方はさまざまな方式があります。以下によく利用されるSSOの実現方式をまとめます。

    ●Kerberos認証
    MITで仕様策定された最も古いSSOの実現方式。WindowsログインユーザがMicrosoft製品を利用する際に同じユーザで自動的に認可されているWindow統合認証もこのKerberosを使っている。
    ●LDAP認証、ActiveDirectory認証
    最も普及したSSOの仕組み。ログインするユーザの情報をLDAPデータベース(またはActiveDirectory)に登録し、個々のサービスがログインを行う際にLDAPデータベースに問い合わせを行うことでSSOを実現している。
    ●SAML
    XMLを利用して認証してほしいサービス(SP、Service Provider)と認証機能を提供するサーバ(IdP、Identity Provider)を定義し、SSOを行う際に両サーバがどのようなやり取りを、どのようなXMLで実施するかを定義したもの。
    ●Shibboleth
    SSOを実現するオープンソースソフトウェアと、そのソフトウェアで実装しているプロトコルでもある。世界各地に点在していたさまざまな認証サーバ、データベースを統合して利用できるようにするプロジェクト。
    ●OAuth/OpenIDConnect
    WebブラウザやHTTPのプロトコル上で簡単にSSOを実現するための規約。現在はOpenIDConnectがよく利用されているが、ほとんどの仕様はOAuth2.0で定義されており、認証してほしいサービス(RP、Relaying Party)と認証機能を提供するサービス(OP、OpenId Provider)の間でどのようなやり取りをするかを規定している。Webサービスでよく目にするGoogleでログインやFacebookでログインなどはこのOpenIDConnectが利用されている。

例えば、はじめてSSOをやる、または学習する必要がありSSOをインターネットで検索すると、上のようなプロトコルや実現方法に関しての記事や情報が大量に集まると思います。SSOではプロトコルごとに用語も少々異なっており、初めて見たときは混乱するかもしれません。ただ、SSOの本質は上に挙げたような実現方式ではなく、一度ログインしたらその後のログインをスキップしたいという一点になります。新しい技術を学ぶ時に最も重要な点は技術をどう実現するかではなく、その技術で何をしたいかです。

アプリケーションの視点でのSSO

アプリケーションエンジニアの視点でSSOの実現方法を見る時に重要なのは、SSO では一度入力した認証情報を複数のサービスで共有するために認証情報を保持するサーバ・サービスと、認証が必要なサーバ・サービスが分離している点です。

  • SSOのシステム構成概要

    SSOのシステム構成概要

SSOの実現方式にはさまざまな種類がありますが、どの方式を見てもこの認証を行うサーバと認証が必要なサーバが分離されており、SSOのプロトコルは分離したサーバ間のやりとりに関して規定しているということに気がつくと思います。SSOのプロトコルや実現方式に応じて役割の名前や通信の順番は異なります。しかし、アプリケーションとして重要なのは認証したという結果を複数のサーバ・サービスで共有するためにどうやって伝搬させているかという点になります。これを押さえておけば、実際にSSOを導入する際にもどのタイミングで認証サーバに処理を移譲し、認証した結果をどう受け取ればよいかがわかり、理解が容易になります。また、このやりとりは業務に大きく依存しないため、多くの言語で標準ライブラリに組み込まれており一般的なWebアプリケーションフレームワークなどで意識せずに利用できます。 また、SSOというと認証方法について目が行きがちです。以下はID、パスワードでの認証以外での認証方式や認証に関連する技術や考え方です。これらはSSOを実現するソフトウェア・サービスが備えていることが多い機能ではありますが、SSOの本質ではなく認証方式という別のジャンルの技術になります。

    ●多要素認証(MFA)
    認証時にID、パスワードだけでなく、ほかの認証方法を混ぜることによってログインの堅牢性を高める方式。ワンタイムパスワードと組み合わせることが多い。
    ●ワンタイムパスワード(OTP/HOTP/TOTP)
    期間やアクセス回数などの一定の条件で有効期間が定められたパスワードを発行する仕組み。Google Authenticatorなどもこの仕組みを利用している。
    ●証明書認証
    端末やユーザに対して証明書を配布し、その証明書の検証を行うことでID、パスワード以外での認証を行う方式。VPN製品などで利用することが多い。
    ●生体認証
    人間の体の特徴を認証キーとして利用する認証方式。スマホでの顔認証や指紋、静脈や虹彩など長期的に変化の少ない部位を利用する。

SSOの本質ではありませんが、こういった認証に関する機能をプロジェクトに導入したいが認証機能を自前で実装するのが大変なため、こういった機能を具備しているSSO製品を導入するというケースもよくあります。これもサーバ・サービスの分離がなされているからこそ導入がしやすくなっています。

インフラ視点でのSSO

インフラ視点でSSOを見ると、認証サーバに対して大量のリクエストが発行される可能性が高いということがわかります。提供するシステムによりますが、一般的な業務システムは全てのユーザがログイン処理を通過して業務を実施するケースがほとんどです。また、SSOの場合は複数のシステムを一つの認証サーバで認証させる仕組みになっており、複数のシステムの、全ユーザ分のログイン要求が認証サーバに集中します。どんなSSOの実現方式を利用しても最低限以下の要求は必要となります。

    ●ログイン処理自体とログイン後の認可情報の払い出し)
    OpenIDConnectの場合ですと、アクセストークンの払い出しとなります。
    ●アクセスするごとにログインしているかどうかのチェック)
    OpenIDConnectの場合ですと、アクセストークンの検証処理となります。
  • SSOで発生する通信

    SSOで発生する通信

仕組み上、大量のリクエストが認証サーバに集中するモデルになっているため、SSOではアクセスを減らすための工夫がプロトコルに規定されており、SSO製品の実装では高速化のための仕組みを持っています。例えばオープンソースソフトウェアのSSO製品であるKeycloakは発行したアクセストークンをデータベースに保存せず、メモリ上に保持し高速な処理を実現しています。サーバ停止によるトークン消失を防ぐために、単純なメモリでなく複数のサーバで共有できる分散メモリを利用しています。また、ほかの製品ではトークンの保持にKeyValue型のデータストアを利用し、高速化が実現しています。

技術を活用するためには

SSOという技術をみるとアプリケーションの視点だけではなく、インフラとしての視点も併せて持つことでより理解が深まります。SSOの技術をどのように利用するかという機能に関する観点のほかに、SSOの仕組み上ボトルネックになる部分や、その解消方法まで目が届くようになります。 ログイン自体はシステム・サービスが持っている機能の一つになりますが、さまざまなシステム・サービスでも必要とされる汎用的な機能であり、ある意味非機能であるとも言えます。ログイン機能だけを持った業務システムというのは存在しないと思いますし、ログインはある業務を実施するうえで必要となる従属的な機能です。実際にIPAで提示されている非機能要求グレードにおいても、セキュリティ要求の一部としてログイン処理やユーザ管理について言及されています。 こういった機能要求に属するのか、非機能要求に属するのかが曖昧な技術こそが、アプリケーション・インフラの両方の視点で把握する必要がある技術です。このような技術を学んでいく際は、どうやって実現しているのかという視点でなく、その技術が何を実現したいかの観点で見ることにより技術を単純化でき、技術を効果的に活用できるようになります。 次回からはSSOと同じようにアプリケーション、インフラの境が曖昧な技術要素に対して説明をしていきたいと思います。

※本記事はエヌ・ティ・ティ・データ先端技術株式会社から提供を受けております。著作権は同社に帰属します。

[PR]提供：エヌ・ティ・ティ・データ先端技術