SSO機能を導入することで実現できることと、メタップスクラウドにてSSO関連で現在取り組んでいること
はじめまして、株式会社メタップスでエンジニアをしています米谷です。
現在は「メタップスクラウド」というSaaS一元管理ツールの開発を行っていまして、特にSSO(シングルサインオン)機能周りに関して関わることが多いです。
このSSOの機能に関して、SSOを導入することで実現できることと、SSO機能に関して現在取り組んでいることに関して紹介したいと思います。
現在メタップスクラウドにて対応しているSSO連携方法
現在メタップスクラウドではSSO機能として下記の2つに取り組んでいます。
● SAML連携
●フォームベース認証
そもそもSAMLとはなに？という方やフォームベース認証とはなに？という方もいると思うので軽く説明したいとおもいます。
SAML連携
SAMLとは「Security Assertion Markup Language」の略で、連携しているクラウドサービス間でユーザー認証を行うための標準規格です。
このSAMLではxml形式のデータをやりとりしてSSOを実現するのですが、パスワードを使用したログイン方法ではないため、ユーザーごとのパスワードの管理が不要になるといったメリットがあります。
またこのSAMLはシングルサインオンのみに使用されるのではなく、プロビジョニングといったユーザーの作成を行う際にも使用されます。
そのため、社内のユーザーを管理する際にそれぞれのユーザーのID Passwordの管理をしたり、新規ユーザーの作成に関してSAMLを導入することで管理が不要になります。(ユーザーの作成に関しては対応してないところも多いです)
フォームベース認証
フォームベース認証はログインに使用するID Passwordなどのログイン情報を使い対象のSaaSのログインページからID Passwordを送信することでログインする認証方法になります。
メタップスクラウドでのフォーム認証の場合、対象のサービスにおけるユーザーのID Passwordをメタップスクラウドに登録して、Chrome拡張機能を入れることで自分でID Passwordを入力しなくても登録されているID Passwordを元に自動的にID Passwordの入力を行いログインの実行を行うことができます。
この方法であればSAMLに対応していないSaaSでもSSOを実現することができますが、ユーザーごとのID Passwordの管理を行う必要があり、ユーザーが増えると対応しなければいけない量が増えますし、パスワードが変わった場合は再度システムにパスワードの登録をしなければいけないなどの手間がかかります。
SSO連携を導入することで実現できること
SSO機能を導入することでユーザーがそれぞれのサービスのID Passwordを管理する必要がなくなります。
特にSAMLの場合はパスワードを使用しないので、管理者もパスワードに関して考慮する必要がありません。
そのため使用しているSaaS全てがSAMLに対応している場合、ユーザーもシステムの管理者もID Passwordを管理する必要がなく、新しくユーザーが増えた際にそれぞれのSaaSのID Passwordを連絡するなどの必要がなくなります。
ただ、SAMLに対応していない、もしくは対応しているが料金の高いプランに変えなければいけないといった状況があるので、そういったサービスに対してもSSOできる様にフォームベース認証を用意しています。
一応フォームベース認証を導入してID Passwordを管理者が管理することでSSOを実現でき、ユーザーがパスワードを管理しなくて良い状況にはできますが、その代わりフォームベース認証の場合はID Passwordをシステム上で管理する必要があるため、ユーザーが増えたり、パスワードが変わったりしたら、その都度ID Passwordを設定するなどの作業が必要になります。
そのためフォームベース認証の場合は管理のコストがかかるので可能であればSAMLを使ったSSO連携ができることが理想だと思います。
SSOはセキュリティリスクを下げることができる
SSOのメリットとしてセキュリティリスクを下げることができるといった面もあります。
例えば、ユーザーがそれぞれのSaaSのID Passwordを管理しないことでパスワード漏洩のリスクも減らすことができます。
また、いろんなSaaSにて同一のパスワードを使用しているといった方も多いと思うのですが、その場合どこかのSaaSにてパスワードの情報が流出した場合に、他のSaaSに関してもログインされてしまう危険性が出てきます。
SAMLの場合はSaaSにログインする際にパスワードを使用しないので、SaaS側でデータベースの中身が流出するなどでパスワードの情報が漏洩した際にも影響を受けることがないといったメリットもあります。
メタップスクラウドにてSSO関連で現在取り組んでいること
現在はSAML、フォームベース認証ともに連携するSaaSを増やしている最中です。
フォームベース認証に関してはまだリリースできていないですが、SAMLに関しては現在約35個のSaaSと連携できる様になっています。
SAMLの場合は一度実装してしまえばSaaSの連携数を増やす上では新しく実装が必要になることはほぼ無いので動作確認を行うのみになりますが、たまにSP側でSAML連携の際の手順が複雑で確認に時間がかかる場合があったります。
フォームベース認証ではそれぞれのSaaSのログイン画面によって実装をかえる必要があるため、それぞれのSaaSごとに機能の実装が必要になりますが、そこまで実装に時間がかからないため、アカウントの準備さえできれば連携数に関してはすぐに増やしていくことが可能そうです。
SSO連携を増やす上で困った点
現在はSSO連携数を増やす中でいくつか困る場合がありまして、主に下記の3つになります。
● 動作検証の際に使用するアカウントの用意
● SP側でSAML連携の際の手順が複雑で確認に時間がかかる
● SP側でSAMLの設定を間違えたままSAMLを有効化してしまい誰もログイン出来なくなる
動作検証の際に使用するアカウントの用意
「動作検証の際に使用するアカウントの用意」に関してですが、無料でアカウントの作成が行えるSaaSの場合は問題ないのですが、有料の場合は対象のSaaSにテスト用のアカウントの作成を依頼したりする作業が必要になります。
そのため、SAML連携の動作確認自体はすぐに終わるものの、動作検証を行うためのアカウント用意に対象のSaaSへの連絡、テストアカウントの作成などの手順が必要になるため一気に連携数を増やしていくのが難しいといった点があるのかなと思っています。
SP側でSAML連携の際の手順が複雑で確認に時間がかかる
次に「SP側でSAML連携の際の手順が複雑で確認に時間がかかる」に関してですが、例えば `SamlAttribute`に特定の値を設定しないと動作しない場合や、署名をする場所がアサーションのみだと失敗する場合、SaaSのSAMLの設定をブラウザから行えずコマンドを実行して設定する必要がある場合などいろんなパターンがあります。
そのためまず対象のSaaSのSAMLの仕様を調べて、それに対応する形で動作確認をしなければいけません。
全てのSaaSがどれも同じ形で実装していれば確認作業もすごく楽になるのですが、SaaS側でSAMLの実装の仕様が異なっているのが現状だと思います。
SP側でSAMLの設定を間違えたままSAMLを有効化してしまい誰もログイン出来なくなる
最後に「SP側でSAMLの設定を間違えたままSAMLを有効化してしまい誰もログイン出来なくなる」ですが、設定ミスをしたままSAMLを有効化してログアウトしてしまうとその後SAMLでのログインしか出来ないため、誰もログインできなくなるといったことが起きる場合があります。
これは自分も一度やってしまったのですが、SAML有効化するとメールアドレスでのログインができなくなり、その結果SAMLの設定を間違たままログアウトしてしまうと誰もログイン出来ず、SAMLの設定を修正することも出来ないためメールでSAMLの解除を依頼する形になったことがあります。
管理者ユーザーのみはSAMLを有効化してもメールアドレスでログインできるSaaSや、テスト機能がありそこで動作確認は行えるなどの機能が実装されているSaaSは良いのですが、そういった機能が無い場合はSAML連携をする際は注意が必要になります。
終わりに
今後はSSOの機能に加えて、ユーザーを同期する機能なども追加することで、SaaS側でユーザーを作る必要もなく、アプリを連携するだけで、対象のSaaSのアカウント作成、ログインが行える様な形にしていければと思っています。
また、SaaS事業者向けに Ruby on Rails のアプリケーションにSAMLを使用したSSO機能を簡単に実装するライブラリも作りましたので、興味ある方はみていただけるとありがたいです！
