SSO（シングルサインオン）に興味があって、SSOサービスを色々試してみた感想です。SSOは全く初めてで、SSOとは？から使い勝手までを簡単にまとめました。
動機
色々なウェブサービスを使っているのですが、それぞれにIDとパスワードがあって、とてもじゃないけど全て覚えることはできないので、IDとパスワードをメモしています。
さらに、同じサービスでも複数のアカウントがある場合は、アカウントを切り替えるのがとても面倒です。
また、１つアカウントを複数の人で共有することもあり、共有していた人が抜けた時に、パスワードを設定し直すのが面倒です。
それらを解決するのに、SSO（シングルサインオン）を使うといいらしいという話を聞いたので、色々試してみました。
SSO（シングルサインオン）とは？
SSO（シングルサインオン）とは、１つのIDとパスワードだけで、複数のサービスにログインできるようにする仕組みです。
方式は色々あるのですが、今回の目的は、ウェブのサイト・サービスを、１つのIDとパスワードでログインできるようにすることだったので、 IDaaS（Identity as a Service・アイダース）と呼ばれるものを試しました。
IDaaSの仕組み（SAML）
よくGoogleアカウントやFacebookアカウントでユーザー登録できるウェブサービスがありますが、それと同じようなものでした。
準備
まず、核となる、ユーザーIDとパスワードを作成して管理している、ユーザーデータベースサービス（IDaaS）があり、そこにアカウントを作ってログインできるようにしておきます。 （ここで言うユーザーIDとは、IDaaSのユーザーIDで、使いたいウェブサービスのユーザーIDではないので注意です）
そして、SSOしたいサービスに、アカウントだけ作成しておいてパスワードは設定せず、認証の問い合わせはIDaaSに聞くよう設定しておきます。
ログイン
SSOしたいサービスにログインしようとすると、そのサービスのログイン画面ではなく、IDaaSのログイン画面が開きます。
そこで、IDaaSのID・パスワードを入力すると、同意画面がでます。
そして、同意すると、SSOしたいサービスにログインできます。
GoogleやFacebook認証でログインする時によく見るあのフローですね。
厳密には、GoogleアカウントやFacebookはOAuth2.0認証で、IDaaSはSAML認証という、SSOを目的とした専用の認証を用いていますが、使う側から見た流れは同じようなものになります。
使い方（ユーザーサイド）
ユーザーから見た、サービスへのログイン方法は
- URLからサービスに直接ログインする方法
- IDaaSのポータルサイトからログインする方法
の２通りがあります。
URLから直接ログイン
前述の、サービスにURLを直接指定してログインしようとすると、IDaaSのログイン画面が出て、そこからログインする方法です。
ポータルから間接ログイン
サービスに直接アクセスするのではなく、IDaaSのポータルサイトからアクセスする方法もあります。
まず、IDassSのサイトにログインすると、ポータル画面にSSOしたいサイトのアイコンが並んでいて、そこからログインします。
サービスのアイコンをクリックすると、そのサービスのサイトがログインした状態で開かれます。
IDaaSの仕組み（フォーム）
SAMLを使った方法は、SSOしたいサービスがSAMLに対応していないと使えません。
SAMLが使えない時の代替方法として、「フォーム」を使った方法もあります。
準備
まず、IDaaSが提供しているブラウザーのプラグイン・機能拡張を、ブラウザーにインストールしておきます。
そして、SSOしたいサービスのIDとパスワードを、IDaaSに登録しておきます。
ログイン
IDaaSのポータルサイトにログインします。
サービスのアイコンをクリックすると、サービスのログイン画面が表示されます。
すると、ユーザー名とパスワードが自動で入力されて、自動でログインされます。
IDaaSのサーバーに、ユーザーIDとパスワードが保存されていて、ブラウザのプラグインが、そのID・パスワード情報を持ってきて、自動入力しているようです。
仕組みがよく分からず、セキュリティー的に大丈夫か何とも言えないのですが、全てのIDaaSがこの機能を提供していて、恐らく大丈夫なんじゃないかなぁと…。
SSOは個人・野良サービス向けではない
IDaaS側の話
IDaaSはエンタープライズ商品で、個人向けではないですね。
IDaaSを登録すると、まず組織が作られ、その管理者として登録されます。そして、組織で管理するユーザーを作成・追加していく形になります。
１個人の１アカウントだけを登録して、そのアカウントをキーにSSOしたいサービスを登録するといった、個人利用を想定したサービスではありませんでした。
SSOに登録するサービス側の話
また、SAML認証をする場合、SSOに登録するサービスも、エンタープライズアカウントの必要があります。
それは、ある利用したいサービスのアカウントの認証をSAMLにするには、そのサービスの組織管理者しかできないからです。
どういうことかと言うと、Googleの個人アカウントをSAML認証にすることはできません。一方、Googleアカウントの企業版「G Suite」なら、その組織の管理者が、その組織のG Suiteアカウントを個別にSAML認証にすることができます。（仮に、機能的にはGoogleの個人アカウントをSAML認証にできたとしても、それが行えるのはGoogleアカウントを管理しているGoogleだけなのです）
他例で言うと、ECサイトのAmazonのアカウントは個人アカウントなのでSAML認証にすることはできませんが、法人向けAmazonビジネスアカウントは、組織がアカウントを管理しているので、SAML認証にすることができます。
他にも、TwitterやFacebookは野良アカウントしかないので、SAML認証がありません。個人向けのサービスは、管理者がそのサービス提供者なので、SAML認証ができないと考えた方がいいです。
つまり、IDaaSの主な用途は下記になります。
「組織が、自分たちが管理しているユーザーに対し、同じく組織で契約している外部サービスにSSOできるようにする」
個人利用として使ったり、野良アカウントにSSOする用途にはあまり向いていません。
ただし、SAML認証にしないのであれば、前述のフォームによるログインを使って、野良アカウントにSSOすることは可能です。
アカウントを複数ユーザーで共有する
SSOしたいサービスは、そのサービスに登録されたユーザーの認証をIDaaSに問い合わせているだけで、IDaaSのユーザーが誰かは知りません。
なので、１つのSSOしたいサービスのアカウントを、複数のIDaaSのユーザーで共有することができます。
その逆に、同じSSOしたいサービスの複数のアカウントを、１つのIDaaSのユーザーに割り当てて、切り替えてログインすることも可能です。
こういうシチュエーションはあるので、SSOサービスを使うメリットの一つかと思います。
メインのユーザーID・パスワードとの連携
組織では、Active Directoryなどを使って、ユーザーIDとパスワードを一元管理しているかと思います。
IDaaSにログインする際も、それらのID・パスワードでログインしたいです。
そのために、IDaaSからは、中継アプリが提供されています。
Active Directoryなどのユーザー管理DBとIDaaSの間に、中継アプリを立ち上げておきます。
すると、IDaaSにログインする時に、IDaaSは中継アプリ経由で、ユーザー管理DBにユーザーID・パスワードを問い合わせるようになり、ユーザー管理DBのユーザーIDとパスワードでIDaaSにログインできるようになります。
つまり、IDaaS自体にもSSOできるようにするってことですね。
主なSSOサービス
調べたところ、下記の４つがメジャーかなといった感じでした。とりあえずG Suite以外は試してみました。
- OneLogin
- Okta
- Azure Active Directory
- G Suite
独立系
独立したIDaaSサービスなら、「OneLogin」「Okta」の２択です。
「OneLogin」と「Okta」の両方使ってみましたが、「Oktaの方が若干機能がイケてるけど料金は高め」といった印象でした。
どのIDaaSも一通りの機能は備わっているので、機能による比較は難しいです。
ユーザー管理DB系
前述のとおり、最終的にはIDaaSからも、ユーザーIDとパスワードを、Active DirectoryなどのユーザーDBに問い合わせてくるのですが、 実はそのユーザーDBである「Azure Active Directory」や「G Suite」自体が、SSO機能を提供しています。
「G Suite」は使ったことがないので分かりませんが、「Azure Active Directory」は上記のIDaaSと同様なSAML認証・フォーム認証の機能があります。
使った感じは、複数SSOアカウントと複数IDaaSの紐付け関連が弱く、管理機能や管理者の使い勝手も、独立系IDaaSの方が流石洗練されていて使いやすいなといった印象でした。
「Azure Active Directory」と「従来のActive Directory」
「Azure Active Directory」と「従来のActive Directory」は、名前こそ「Active Directory」と同じですが、全く別物です。
「従来のActive Directory」は、Windowsにログインするユーザーを管理する、ユーザーデータベースサーバーで、主にオンプレにインストールして運用されます。
一方、「Azure Active Directory」は、IDaaSと同じく、インターネット上でユーザーを管理する、ユーザーデータベースサービスで、Office365のユーザーはこちらで管理されます。
なので、「Azure Active Directory」のユーザーIDとパスワードを、WindowsにログインするユーザーIDとパスワードと同じにするには、独立系IDaaSと同様、「従来のActive Directory」と同期する必要があり、そのためのツールがMicrosoftから提供されています。
料金
料金は大体１ユーザー１ヶ月、500円～1000円くらいです。
セキュリティー・プロビジョニングのオプションの付け方で値段が変わってきます。
プロビジョニング
IDaaSとは、IDaaSに登録されているメインのユーザーに対して、複数の他のサービスアカウントの認証を紐付けるサービスとも言えます。
そこから発展して、メインのユーザーに他のサービスを紐付けると、そのサービスのアカウント作成・設定も自動で行ってくれる、「プロビジョニング」機能があります。
プロビジョニング機能はニーズが多いのか、どのIDaaSサービスでも提供しています。
SSOサービスは、手間の割には得られる機能は単純で、かつ、お安くはないので、なかなか価格に似合う導入メリットを感じにくいです。導入するなら、プロビジョニングも合わせて検討した方がメリットが大きいかなぁと思いました。
感想など
結局のところ、キーとなるのは、PCにログインする時や、Office365にログインする時に使うユーザーIDとパスワードなので、大元のActive DirectoryでSSOできるようにするのが一番合理的だし楽だと思います。
外部IDaaSと内部Active Direcotryとの接続は、中継アプリを動かすサーバーを立ち上げておく必要があるし、Active DirectoryのID・パスワードにアクセスできるようにするのは、あまり気持ちのいいものではなく、正直面倒くさいしできればやりたくないです。
Active DirectoryにSSOサービスやられたら、独立系IDaaSは商売あがったりなのですが、使う側からの心理からすると致し方ないのかなぁと思いました。
独立系IDaaS側も対抗手段として、IDaaSのユーザーをキーに、Active DirectoryやOffice365アカウントを作成してSSOする、逆プロビジョニング的な提案をしていますが、 まぁ、普通に考えて、まず先にActive Directoryのユーザーがあるよね…となってしまいます…。
プロビジョニング機能は使えるなら使っていきたい機能ですが、プロビジョニング先は外部のサービスなので、どこまで連携がうまくいくか実際に使ってみないと分かりません。
プロビジョニングされるサービス側も対応が必要なので、じゃあどのIDaaSを意識するかというと、まずは利用者が多いところからとなるわけで…。
以上、もろもろ考えると、IDaaSは、Azure Active Directory（ADFS）に集約されていくのかなぁという印象でした。
ただ、前述のとおり、Azure Active Directoryは、独立系IDaaSと比べると、機能的にまだまだな部分もあり、本当にやりたいことができるか実際に試した方がいいですね。
