こんにちは。
システムインテグレータの佐藤です。
ECサイトを運営する上で気を付けないといけないことはたくさんありますが、個人情報の流出は特に気を付けないといけないことです。
運営者として、サイバー攻撃に対応するべくサイトおよびシステムのセキュリティを高めておくことはもちろん重要なのですが、運営しているサイトとは全く関係のないところでお客様のパスワードが漏れてしまっている状態だと、こちらではどうしようもありません。
それを防ぐために個人としては、パスワードの使い回しをせずサイトやサービス毎にバラバラの複雑なパスワードを設定することが望ましいのですが、厳密に細かくやれている方がどれくらいいるのかというと、大多数ではない気がしています。
たくさんのサービスを利用していると、パスワードがバラバラで複雑だと自分の頭では覚えていられないからです。
パスワードを管理するアプリやサービスを使えば自分で覚えておく必要はないのですが、そういったサービスを活用してきっちり管理している人はまだ少数派だと思われます。
今回は、お客様のそんな面倒なパスワード管理を少しでも楽にするシングルサインオンについて考えていきたいと思います。
シングルサインオン（SSO）とは
シングルサインオンとは、一言でいうと同じIDでいろいろなサービスにログイン出来るようにすることです。
Yahoo!やFacebookやtwitterのIDでログイン出来るサイトやサービスを見たことがあると思いますが、それのイメージです。
SNSのアカウントでログイン、というのが一番想像しやすいということで例に挙げてみましたが、他にも自社が運営する別サービスがある場合、そちらのサービスと同じIDでECサイトもログイン出来るようにもしたいですよね。
1つの自社IDで複数の自社サービスにログインできるようにするのもシングルサインオンとなります。
同じ会社のサービスなのに、それぞれ別で会員登録が必要となると、なんだか面倒くさいですよね。
シングルサインオン（SSO）の方式
シングルサインオンには大きく4つの方式があります。それぞれご紹介します。
エージェント方式
対象のアプリケーションサーバーにエージェントモジュールを組み込む方式です。
自身のブラウザと対象のアプリケーションの間にエージェントモジュールが挟まる形になります。
エージェントモジュールがシングルサインオン用の外部認証サーバーと連携することで、ログイン情報がサーバーから送られてログインが可能になります。
この場合は対象となるWebサーバーやアプリケーションサーバーすべてにエージェントをインストールしなければいけません。
リバースプロキシ方式
アプリケーションと認証サーバーの間にリバースプロキシサーバーを設置する方法です。
リバースプロキシサーバーにエージェントモジュールが組み込まれており、ここでユーザーのログイン情報を取得できます。リバースプロキシサーバーを中継サーバーとしてログインしたいサービスにアクセスします。
エージェント方式と異なり、すべてのWebサーバーにエージェントを入れる必要はありませんが、直接サービスにアクセスできないため、中継サーバーを経由する用ネットワーク構築を見直す必要があります。
代理認証方式
クライアントPCにエージェントを導入し、システムが代理でログイン情報を入力する方式です。エージェントが対象systemのログイン画面を監視しており、ログイン画面が起動した段階で入力を行います。
比較的導入が容易ですが、代理認証に対応していないサービスも存在します。また、クライアント側にエージェントを導入する必要があります。
SAML認証方式
SAMLはSecurity Assertion Markup Languageの略称で、「サムル」と読みます。この認証はユーザー、SP（Service Provider）、IdP（Identity Provider）の三者間で行われます。
ユーザーが対象のサービス（SP）にアクセスすると、SPからIdPに認証要求が飛ばされ、IdPがユーザーの画面にログイン画面を表示させます。ユーザーは一度ログインしておけばその後は自動ログインが可能になります。
シングルサインオン（SSO）のメリット
管理するIDが少なければ少ないほど、お 客様は楽ちんですよね。
ログインがSNS等の既に持っているアカウントで簡単に出来るという使い勝手の良さが、シングルサインオンにおけるお客様側のメリットと言えます。
一方EC事業者の立場で考えると、
「パスワードがわからないからやっぱり買うの辞めた！」
なんてお客様を減らすことも期待出来ます。
いざ買おうと思ったのに、パスワードがわからなくて進めないというのはたまらないストレスですよね。
スムーズに買い物をしてもらいやすくなるというのがシングルサインオンにおけるEC事業者側のメリットとなります。
主にこちらのメリットはSNS等のアカウントで実現するシングルサインオンで期待出来るメリットと言えるでしょう。
一方1つの自社IDで複数の自社サービスをご利用頂くケースで期待出来るメリットと言えば、一元管理された顧客情報を活用した横断的なコミュニケーションが実現出来ることです。
なぜならば、1IDで管理しているということは、お客様がそのIDでログインしている限り、別のサービスであっても同じお客様と判断出来るからです。
例えば自社ECサイトでAという商品を買ったことがある人に対して、自社の異なるBという別のサービスのクーポンを提供しようなどといった販促を行うことも出来ます。
自社のファンになって頂くためのいろいろな仕掛けが打ちやすくなるというのが、自社の1IDで複数サービスにシングルサインオン出来るようにするメリットと言えるでしょう。
シングルサインオン（SSO）のデメリット
一般的に言われるシングルサインオンのデメリットは、シングルサインオンに使用するIDとパスワードが漏洩した際に、一気に複数のサービスに不正アクセスされてしまうという点が挙げられます。
IDaaSと呼ばれるようなクラウド上のID管理・シングサインオンのサービスや、SNSのアカウントを使ったシングルサインオンは複数のパスワードの管理から開放される反面、そのIDとパスワードの管理はより強固にしておかないといけません。
例えばfacebookなどのSNSでは二段階認証などのオプションを用意しています。
シングルサインオンを行うお客様側はこういったセキュリティ強化を意識しないといけません。
シングルサインオン（SSO）を自社のサイトに実装するには
SNS等のアカウントでログイン出来るようにする
もっとも簡単な方法は、対応したサービスを導入することです。
例えば、ソーシャルPLUSというサービスがあります。
ソーシャルPLUSは、複数のプラットフォームに対応したソーシャルログイン機能を、既存のWebサイトに導入できるID連携サービスです。
こういったサービスを使わないで実装する場合は、各プラットフォームが公開している仕様に基づいてログイン機能を開発しなくてはならないのですが、当然それぞれ仕様が異なるのでいろいろなアカウントを利用出来るようにする場合はなかなか大変です。
また、プラットフォーム側が仕様を変更することもあるので、仕様変更にキャッチアップし続けるのも一苦労です。
サービスの使用料は発生しますが、初期の導入も簡単で運用にかかる内部コストも少なくて済むので、こういったサービスの利用をまずは検討されるケースが多いです。
独自のIDでシングルサインオンを実装する
SNSではなく自社内で別で管理しているIDを活用してログイン出来るようにするには、そのIDを管理している基盤と連携する必要があります。
ECサイト構築パッケージでは通常、システムの内部に顧客情報を持ち、ログイン出来るようになっていることが一般的ですが、1IDで運用する場合はパッケージの顧客管理機能は使わずに、外部の顧客基盤に情報を集約した上で、そちらで用意されているログインの仕組みを利用してログインできるようにする必要があります。築パッケージでは通常、システムの内部に顧客情報を持ち、ログイン出来るようになっていることが一般的ですが、1IDで運用する場合はパッケージの顧客管理機能は使わずに、外部の顧客基盤に情報を集約した上で、そちらで用意されているログインの仕組みを利用してログインできるようにする必要があります。
ECサイト以外のお客様向けのサービスをWeb上で展開されている場合、通常このような対応を行い、1IDで自社の複数サービスにシングルサインオン出来るようにします。 [RELATED_POSTS]
まとめ
いかがでしたでしょうか。
シングルサインオンはサイトの使い勝手を高めてくれる一方で、ユーザー側はそのIDとパスワードが漏洩しないように注意することも必要です。
今後ユーザーが利用するWebサービスの数が減っていくことはあまり想像出来ないことを考えると、いかにこのID・パスワードの管理を簡単かつ安全にしていくかが、サービスの利用者を増やしていくポイントになるかもしれませんね。
