SAML に対応していない SaaS に SSO に近い運用を作る方法

SAML(ID 管理サービスとつなぐための規格)に対応していない SaaS(インターネット経由で使う業務ソフト)があります。こうしたサービスにSSO(シングルサインオン)は使えません。それでも、担当者にパスワードを配らず、一度のログインで入れて、誰が使ったかが残る形は作れます。方法は 4 つあり、担当者がパスワードを知るか、記録がどの単位で残るか、何を前提にするかが違います。

「SSO に近い運用」で目指すこと

ID 管理サービス(Okta や Microsoft Entra ID など、社員の ID を一か所で管理する仕組み)が本人を確かめます。その結果をサービスに伝えるのが SSO です。サービス側がその知らせを受け取る作りになっていなければ使えません。password-based SSO(パスワードを代わりに入力する方式)を選ぶ場面を、Microsoft の公式ドキュメントは 2 つ挙げています。アプリが SAML に対応しないときと、ユーザー名とパスワードで認証するときです。

目指す状態は 3 つに分けられます。担当者がサービスごとの ID とパスワードを覚えず、配らないこと。使ってよい人を管理者が決め、担当が終われば外せること。誰がいつ使ったかが残ることです。Microsoft の公式ドキュメントは、ID とパスワードを配る従来の共有の欠点を挙げています。誰がアクセスできるか、誰がアクセスしたかが分からないこと。外すには変えて配り直すしかないことです。この 3 つを裏返したものが目指す状態です。

4 つの方法

方法は 4 つです。①Entra ID の password-based SSO と、②Okta の SWA(Secure Web Authentication)は、ID 管理サービスの代理入力です。③パスワードマネージャーの共有と、④パスワードを見せずに代わりに入力する仕組み(アクセス管理ツール)が残りの 2 つです。

①は、HTML のサインイン画面を持つクラウドのアプリで使えると公式ドキュメントにあります。Entra ID がアプリの ID とパスワードを暗号化して保管し、アプリのログイン画面に送ります。管理者は利用者やグループに ID とパスワードを設定でき、設定しなければ利用者が自分で入力します。共有アカウントの場合は、同じアカウントを使う人のグループを作り、そのグループにパスワードを設定します。利用者は共有パスワードを見ず、使う権限だけを持ちます。対応するアプリでは、Entra ID がパスワードを定期的に自動で更新する設定もあります。

②について、Okta の公式ヘルプは、SWA を SSO の働きを与える技術としています。対象は、SAML などに対応しない外部の Web アプリです。ID とパスワードの決め方は 5 つあります。利用者が自分で設定する形、管理者が設定する形、管理者が設定した一組を複数の利用者で共有する形などです。管理者が設定する形では、パスワードの表示の機能が使えなくなると公式ヘルプにあります。共有する形では、利用者は共有のパスワードを表示できません。共有の設定のパスワードを見たり変えたりできるのは、上位の管理者(スーパー管理者)とアプリの管理者だけです。ブラウザープラグインは、SWA のアプリのサインイン画面に着くと ID とパスワードを自動で入れると説明されています。

③について、1Password の公式ヘルプは、保管庫をメンバーやグループと共有できるとしています。共有した人は、項目を見たり編集したりできます。Teams の閲覧の権限は、隠されたパスワードの表示を含みます。Business では「表示とコピー」を別の権限に分けられます。ブラウザーの拡張機能が、サインインの画面で保存した ID とパスワードを入力します。パスワードマネージャーの働きと限界はパスワードマネージャーとはにまとめています。

④は、本人確認をした担当者に代わってツールがパスワードを入力し、担当者にはパスワードを見せない仕組みです。ID 管理サービスの代理入力と違い、使う人が ID 管理サービスにアカウントを持つことを前提にしない製品があります。対象のサービスと端末の前提は製品ごとに違います。この類型で公式の資料を確かめられたのは Junify の製品ページだけなので、表の④の列はその範囲で書いています。

比較

誰が使ったかは、ログインの手前の仕組みの記録で残します。Usage & insights のレポートでサインインのデータを見るには、Entra ID P1 または P2 の契約プランが要ります。Okta の SWA に必要な契約プランは、確認した公式ヘルプには書かれていません。

どれを選ぶか

使う人が全員 ID 管理サービスにアカウントを持ち、記録が「誰がいつアプリに入ったか」で足りるなら、①か②で済みます。すでに Okta や Entra ID があるなら、追加のツールは要りません。ID 管理サービスがある会社で残る場面はOkta・Entra ID がある会社で、それでも残る共有の管理者アカウントにまとめています。

パスワードを見てよい人だけで使うなら、③で配布と保管が整います。ただし、見た人はパスワードを知る状態になるため、担当が終わればサービス側のパスワードを変える作業が残ります。

ID 管理サービスにアカウントを作らない人(委託先、短期の担当者)が使う場合は、④が候補になります。誰がいつ使ったかを本人ごとに残したいのに①②が使えない場合も同じです。方法ごとの詳しい違いは共有アカウントを複数人で安全に使う方法の比較にあります。

4 つの方法に共通して残ること

どの方法でも、サービス側のパスワードはなくならず、サービス側の記録に残るのは共有アカウントの名前です。パスワードそのものをなくす方式との違いはパスワードレスとはにまとめています。サービス側で二段階認証を必須にしている場合、そのコードを誰が受け取るかは別に決めます。Entra ID と Okta の公式ドキュメントは、対象アプリ側の二段階認証のコードの扱いを明示していません。共有アカウントの二段階認証の考え方は共有アカウントの二段階認証を複数人で使うときの問題と選択肢にあります。