LASSIC Media らしくメディア

クラウドサービスの利用が広がるほど、社員一人ひとりが管理するIDとパスワードの数も増えていきます。サービスごとに認証がばらばらに行われていると、パスワードの使い回しや棚卸し漏れが起きやすく、情報システム部門の運用負荷も膨らんでいくものです。こうした課題への対策として企業向けのシングルサインオン（SSO）を検討する発注担当者やプロジェクトマネージャーが、ほぼ例外なく目にする規格がSAMLでしょう。

SAMLは、認可の委譲を担うOAuthや、認証情報を運ぶトークンの形式であるJWTとは役割が異なる、企業向けSSOで使われるXMLベースの認証連携の枠組みです。この記事では、SAMLがどのような課題を解決し、開発会社とのやり取りで何を確認すればよいのかを、発注者の視点から整理します。実装の細部よりも、レビューで押さえるべき勘所に重点を置いて解説していきます。

SAMLの定義とSSOが解決する課題

SAML（Security Assertion Markup Language）とは、複数のサービスに一度のログインでアクセスできるようにする、企業向けシングルサインオン（SSO）を実現するための標準規格です。

SAML 2.0は、OASIS（構造化情報標準促進協会）が2005年に承認した標準仕様であり、現在も企業向けSSOの土台として広く採用されています。役割が混同されやすいOAuthは、あるサービスが別のサービスの機能を代理で使うための「認可」を委譲する仕組みです。

JWTは、認証・認可の情報をやり取りする際のトークンの形式にすぎません。SAMLはXMLベースで企業向けの認証連携に強みを持つ規格で、この3つは扱う役割がそれぞれ別です。OAuthとJWTそのものの仕組みは、それぞれ別の記事で取り上げます。

SSOが解決する課題は、サービスごとに個別のID・パスワードを管理する煩雑さです。社員が使うクラウドサービスが増えるほど、パスワードの使い回しや失念が起きやすくなり、情報システム部門への問い合わせも増えていきます。

パスワード忘れによる問い合わせ対応や、退職時のアカウント棚卸し漏れといった運用コストは、連携するサービスの数が増えるほど積み重なっていくものです。こうした運用面の負担を軽くする手段として、SSOの導入が検討されます。

SAMLに対応したSSO基盤を導入すれば、社内の認証基盤に一度ログインするだけで、連携先の複数サービスへ利用者を橋渡しできるようになります。パスワードの管理主体を社内の認証基盤に集約できる点が、業務効率と管理の両面でメリットになるでしょう。

SAMLへの関心が高まっている背景には、企業が契約するクラウドサービスの数が年々増えてきた事情があります。連携するサービスが増えるほど、認証の窓口をどう束ねるかという論点も大きくなっていくものです。

SAMLには1.0・1.1という初期のバージョンもありましたが、現在主に使われているのはSAML 2.0です。2005年の標準化以降、大きな改版のないまま長く使われてきた規格であり、対応製品の蓄積という面でも選定の判断材料が豊富な土台になっています。

グループ会社を複数抱える企業では、親会社のIdPを中心に据え、グループ各社のシステムをSPとして連携させる使い方も見られます。組織再編や事業統合が起きた場合にも、認証の窓口を一本化しやすい点は実務上の利点になるでしょう。

IdPとSP、信頼関係が土台となる二者

SAMLの仕組みを理解するうえでの出発点は、登場する二つの役割を区別することです。IdP（Identity Provider、アイデンティティプロバイダー）は利用者の認証を担う側であり、SP（Service Provider、サービスプロバイダー）は利用者にサービスを提供する側を指します。

SPは利用者の認証結果をIdPに委ね、IdPが発行した認証情報を信頼してアクセスを許可します。両者は直接通信するのではなく、利用者のブラウザを介して情報をやり取りする点も特徴です。この信頼関係をあらかじめ結んでおくことが、SAML連携の前提条件になります。

IdPとSPは、接続に先立って「メタデータ」と呼ばれる設定情報を交換します。メタデータには、ログイン画面のURLや署名検証用の証明書といった、連携に必要な情報がまとめられているのです。

発注時に意識したいのは、自社がどちらの立場になるかという点です。企業の実務では、既存の社内アカウント基盤をIdPとして用意し、契約する複数のクラウドサービスをSPとして連携させる形が一般的でしょう。

IdPとSPの選定・設定を誤ると、意図しない利用者にアクセス権を渡してしまうリスクにつながります。どちらの役割を誰が担うのかを、契約や設計の初期段階で明確にしておくことが欠かせません。

SAMLのアサーションには、認証結果だけでなく、氏名や部署、役職といった利用者の属性情報を含められます。SPはこの属性情報を使って、利用者ごとに閲覧できる範囲を制御する場面もあり、認証の結果を業務側の権限管理につなげる橋渡し役も担っているのです。

契約するSaaSが増えるほど、IdPと結ぶメタデータ交換や信頼関係の設定件数も比例して増えていきます。SPごとに設定内容が細かく異なる場合があるため、対応表を用意して管理しておくと、後からの棚卸しが進めやすくなるでしょう。

利用者のアクセスからログイン成立までの流れ

SAMLによる認証は、おおむね次の順序で進みます。利用者がSPの保護されたリソースへアクセスを試みると、SPはその利用者がまだ認証されていないことを確認し、IdPのログイン画面へ誘導するのです。

IdPの画面で利用者がID・パスワードなどにより認証を済ませると、IdPは認証結果を示す「アサーション」と呼ばれるXML形式のデータを作成します。このアサーションには、IdPの秘密鍵によるデジタル署名が付与されるのです。

署名付きのアサーションは、利用者のブラウザを経由してSPへ渡されます。SPは、あらかじめ交換しておいたIdPの公開鍵を使って署名を検証し、改ざんされていないことと、正当なIdPが発行したものであることを確認したうえで、ログインを成立させるのです。

この一連の流れをSPが起点で開始する場合を「SP起点」、IdPの画面から始める場合を「IdP起点」と呼び分けます。どちらの方式に対応しているかは製品によって異なるため、想定する利用シーンに合わせて確認しておく必要があるでしょう。

SAMLの仕様では、これらのやり取りにHTTPリダイレクトやHTTP POSTといった通信方式（バインディング）が定められています。認証要求や認証結果をブラウザ経由でどう受け渡すかが規格として決まっているため、対応製品同士であれば個別の作り込みなしで連携できる設計になっているのです。

SAMLで発行されるアサーションには有効な期間が設定されており、その期間を過ぎると再度の認証が求められる仕組みになっています。有効期間の長さは製品の設定によって変わるため、業務での使い勝手とセキュリティのバランスを見ながら調整することになるでしょう。

SAMLレスポンスには認証の成否を示すステータス情報も含まれており、ログインに失敗した際の原因究明にも使われます。うまく連携できないときは、このステータス情報をIdP・SP双方のログで確認するところから調査を始めるとよいでしょう。

IdPとSPの間でサーバーの時刻がずれていると、アサーションの有効期間が正しく判定されず、ログインに失敗する場合があります。NTPなどの時刻同期の仕組みを両者に入れておくことも、見落とされやすい確認ポイントの一つでしょう。

OAuth・OIDCとの役割の違いを整理する

SSOの検討時に混同されやすいのが、SAMLとOAuth、OpenID Connect（OIDC、OAuthを土台にした認証の仕組み）の関係です。三者は登場する場面が異なるため、まず役割の違いを押さえておくことが遠回りを避ける近道になります。

企業の情報システム部門が既存の社内アカウント基盤と外部SaaSを連携させる場面では、歴史的にSAMLが選ばれる場面が多く、対応実績を持つSaaSも豊富です。あるサービスから別サービスのデータへのアクセスを許可する場面ではOAuthが、消費者向けサービスのログイン連携ではOIDCが使われる傾向にあります。

どの規格を使うかは、連携するサービスがどれに対応しているかで実質的に決まる場合が少なくありません。OAuthの認可の仕組みや、OIDCで用いられるJWTのトークン構造そのものについては、それぞれの専門記事で扱います。

実務では、社員向けの業務システムにはSAMLを、消費者向けサービスのログインにはOIDCを、というように用途で使い分ける企業も見られます。一つの規格に絞り込む前に、社内向けと社外向けで求められる要件が異なる点を踏まえておくとよいでしょう。

将来的にOIDCへの切り替えを視野に入れている場合でも、大半のIdP製品はSAMLとOIDCの両方に対応しているため、契約の時点でどちらか一方に縛られるとは限りません。導入前に、候補製品の対応規格を仕様書やカタログで確認しておくと、後々の選択肢を狭めずに済むでしょう。

規格そのものの利用に追加のライセンス費用はかかりませんが、対応するIdP製品やSaaS側のプランによっては、SSO連携が上位プランでのみ提供される場合があります。契約前に、利用中または導入予定のSaaSがどのプランでSAML連携に対応しているかを確認しておく必要があるでしょう。

発注・レビューで押さえておきたい六つの視点

SAMLの仕組みそのものを一から実装する場面は多くありません。実務の大半は、SAMLに対応した製品やサービスを選び、正しく設定して運用する形です。発注や仕様レビューの段階で確認しておきたい点を、六つの視点に分けて整理します。

IdPに何を使うか

IdPとして何を採用するかは、SSO全体の使い勝手とセキュリティ水準を左右する判断です。既存の社内アカウント基盤をIdPとして活用するのか、専用のID管理サービスを新たに導入するのかで、初期構築の手間や運用の負荷が変わってきます。クラウド型のID管理サービスを使うか、自社で運用するオンプレミス型の製品にするかも、あわせて検討する論点になるでしょう。

開発会社に依頼する際は、候補となるIdP製品がSAMLに対応しているか、連携先のSPと組み合わせた実績があるかを確認するとよいでしょう。IDフェデレーション（複数システム間で認証情報を連携させる仕組み）やXML署名の検証実装には専門知識が求められるため、社内エンジニアだけで一から作り込むよりも、対応製品の導入によって負担を抑える進め方が現実的です。

既存の社内アカウント基盤との連携

すでに社内で使っているディレクトリサービスや人事システムのアカウント情報と、IdPをどう連携させるかも重要な論点です。アカウントの作成・変更・削除が複数の場所で個別に行われていると、情報が食い違ったまま放置されるリスクが残ります。

IdPを中心にアカウント情報を一元管理できる設計になっているか、開発会社との打ち合わせで確認しておく必要があります。連携方式によっては既存システムの改修が発生する場合もあるため、影響範囲を早い段階で洗い出しておくと、後工程での手戻りを防げるはずです。人事異動や組織変更のたびに手作業でアカウント情報を直しているような状態であれば、IdP連携を機に見直す好機になるでしょう。

証明書の管理と有効期限

SAMLの署名検証に使う証明書には有効期限があります。証明書が失効すると、その日を境にSSO経由でのログインが一斉にできなくなり、業務システムへのアクセスが止まるという影響は避けられません。

運用開始後、証明書の更新作業を誰が・いつ・どのような手順で行うのかを、契約や運用設計の段階であらかじめ取り決めておくことが欠かせません。担当者が異動・退職した際に更新作業の引き継ぎが漏れる、という事態も想定しておく必要があるでしょう。証明書の自動更新に対応した製品を選んでおけば、更新忘れによるトラブルの芽をあらかじめ摘んでおけます。

退職者・異動者のアクセス停止

SSOを導入すると、IdP側でアカウントを無効にするだけで、連携する複数のサービスへのアクセスをまとめて止められるようになります。この一括停止の仕組みが正しく機能するかどうかは、退職者や異動者による情報漏えいリスクに直結する要素です。

IdPでのアカウント無効化が各SPへ正しく反映されるか、導入時にテスト環境で検証しておくとよいでしょう。サービスによっては反映までに時間差が生じる場合もあるため、即時性が求められる業務があるかどうかもあわせて確認しておきましょう。退職者対応の実施記録を残しておけば、後日の監査や社内でのセキュリティレビューの際にも、対応状況をすぐに提示できるでしょう。

内製と外部委託、判断の分かれ目

SAMLの実装そのものを内製する場合、IDフェデレーションの設計知識に加え、XML署名の検証やメタデータ管理といった専門領域を扱えるエンジニアの確保が課題になりやすいところです。社内に専任の担当者を置けない企業では、対応製品の導入や外部パートナーへの委託によって、この負担を避ける選び方が現実的でしょう。

外部パートナーに依頼する場合は、要件定義の段階からIdP選定・証明書運用・アクセス権の棚卸しまでを見通した設計を任せられるかどうかが、内製との大きな違いになります。単発の実装支援ではなく、運用開始後の見直しまで伴走できる体制かどうかを、選定時の基準に加えておきたいところです。

利用者への周知とテスト計画

SSOへの切り替えは、利用者のログイン手順が大きく変わる場面でもあります。切り替え時期や操作手順を事前に周知しないと、問い合わせがヘルプデスクに集中し、現場が混乱しかねません。

本番切り替えの前には、主要なSPとの組み合わせでログイン・ログアウト・エラー時の挙動を一通り確認しておくことが望ましいでしょう。対象部署を段階的に広げるロールアウト計画を立てておけば、想定外の不具合が起きた場合の影響範囲も抑えられます。

まとめ

• SAMLは、複数のサービスに一度のログインでアクセスできる企業向けSSOを実現する標準規格である。
• 認証を担うIdPとサービスを提供するSPが、署名付きのアサーションをやり取りして成り立つ仕組みである。
• 認可の委譲を担うOAuthや、トークン形式であるJWTとは役割が異なり、企業向けSSOに強みを持つ。
• 発注時は、IdPの選定・既存基盤との連携・証明書管理・退職者のアクセス停止・内製と外部委託の判断・利用者への周知という六つの視点を確認する必要がある。
• SaaS側のプランによってSSO連携の可否が変わる場合があるため、契約前に対応状況を確認しておく必要がある。
• 製品を選び、正しく設定して活かすことが、SAML導入における現実的な進め方となる。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• OASIS「Security Assertion Markup Language (SAML) V2.0」（2005年承認）
• Microsoft Learn「シングルサインオンSAMLプロトコル」
• Okta Developer「SAML」
• Wikipedia日本語版「Security Assertion Markup Language」

Tweet