RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

SAML認証の仕組みと認証フロー

こんにちは、tatsumiです。

今回は、前回の記事(シングルサインオン(SSO)の仕組みと認証方式)の最後にも書いた通り、ラクスの各サービスでも使われているSAML認証について解説したいと思います。

前回の記事をまだ見ていない方は、以下からご覧ください。 tech-blog.rakus.co.jp

SAML認証とは?

SAML(サムル)とは「Security Assertion Markup Language」の略称、インターネットドメイン間でユーザー認証を行うためのXMLをベースにした標準規格です。
異なるドメイン間で認証を行うことができるため、クラウドサービスのシングルサインオンとして利用されることが多いです。

実際に、Google WorkspaceやMicrosoft 365、Salesforceなどの多くのクラウドサービスがSAMLに対応しており、ラクスのサービスでもSAMLに対応しているサービスはいくつか存在します。

SAML認証における登場人物

SAML認証の解説に入る前に、SAML認証を構成する要素(登場人物)を紹介します。
SAML認証では、以下の三者間で認証が行われます。

ユーザー

利用者を指します。

IdP(Identity Provider)

ユーザーの認証情報を保存・管理するサービスを指します。
シングルサインオンを利用する場合、ユーザーはIdPへログイン認証を行う必要があります。

SP(Service Provider)

ログイン先のサービスを指します。
具体的には、先ほど例に挙げたGoogle Workspace、Microsoft 365、Salesforceなどのクラウドサービスやラクスの各サービスがこれにあたります。
SPはIdPとユーザーの認証情報をやり取りし、認証処理を行います。

SAML認証のフロー

それでは次に、先ほど紹介した三者間でどのような流れで認証が行われるかを解説します。
SAML認証ではSPを起点とする場合とIdPを起点とする場合で認証フローが異なるため、それぞれ解説します。

SP起点(SP Initiated)

SP起点とは、最初にユーザーがSPにアクセスを行うパターンになります。
ユーザーがSPにアクセスすると、SPからIdPへリダイレクトが行われてIdP側で認証が行われます。
IdP側で未ログイン状態であった場合は、IdP側のログイン画面が表示されIdPへのログインを行います。
ログインが成功すると、今度はIdPからSPへリダイレクトが行われて、IdPから受け取った認証情報を元にSP側で認証を行い、認証に成功するとユーザーはSPへログイン成功となります。

上記内容を簡単に図にまとめてみると、こんな感じになります。

ユーザー目線では、
①SPへアクセス
②IdPのログイン画面が表示される(IdP側で未ログイン状態であった場合のみ)
③IdPへログインすると、SPの画面が表示されてサービスを利用できる

上記のように、SPへのログイン画面は経由せずにサービスを利用することができます。
また、IdPへ既にログインした状態であった場合は、SPへアクセスするとIdPのログイン画面も経由せずにサービスを利用することが可能です。

IdP起点(IdP Initiated)

IdP起点とは、最初にユーザーがIdPの画面から利用したいSPを選択して利用するパターンになります。
ユーザーがIdPへログインを行い、IdPのSP一覧画面から利用したいSPを選択すると、対象のSPに認証情報が送信されてログイン認証が行われます。

上記内容を簡単に図にまとめてみると、こんな感じになります。

開発時の注意点

SP起点とIdP起点では認証フローが少し異なるため、それぞれで開発が必要となります。

SAML認証の設定

SAML認証を利用する際は、SP側とIdP側のそれぞれでお互いの情報を登録しておく必要があるのですが、どのような情報を登録しておく必要があるかを紹介します。

SP側の設定

SPにIdPの情報を登録する際に必要な情報は以下になります。

  • ログインURL
    → SPからIdPへリダイレクトを行う際のリダイレクト先URL。

  • ログアウトURL
    → SPからログアウトした後のリダイレクト先URL。
    主に、シングルログアウト時に利用されるURLで、シングルログアウトを提供していない場合は不要な項目になります。

  • エンティティID
    → IdPをグローバルに一意に認識するためのID。(IdPから取得)

  • IdPの証明書
    → IdPが認証応答の署名に用いる秘密鍵に対応する公開鍵。(IdPから取得)

IdP側の設定

IdPにSPの情報を登録する際に必要な情報は以下になります。

  • Assertion Consumer Service URL
    → IdPからSPへリダイレクトを行う際のリダイレクト先URL。

  • エンティティID
    → SPをグローバルに一意に認識するためのID。(IdPから取得)

SAML認証に対応しているSPでは、上記情報を含んだメタデータをダウンロードできることが多いです。
ダウンロードしたメタデータをIdPへアップロードすることで、IdP側の設定が簡略化できます。

IdPユーザーとSPユーザーの紐づけ

IdPとSPは別サービスで、それぞれでユーザー管理をしています。
IdPから送られてくる認証情報には、IdPで管理しているユーザーの情報が含まれているため、SP側ではそのユーザー情報がSPのどのユーザーを指すか、紐づけを行う必要が出てきます。
そこで登場するのが「NameID」です。

NameIDについて

NameIDとは、IdPとSPで共有するユーザー識別子のことです。
基本的にはIdP側で設定されたNameIDを使って、SP側でSPユーザーとの紐づけキーとして利用します。
NameIDに何が設定されるかはIdPのサービス毎に異なり、IdPによってはNameIDに何を設定するかを変更することも可能です。

IdPユーザーとSPユーザーの紐づけ方法

紐づけ方法としては、SAML認証での初回ログイン時にIdPとSPの両方でログイン認証をさせる方法があります。(2回目以降はIdP側のログインのみで認証可能)
認証フローとしては、以下のようなイメージになります。

ただし、上記方法では初回ログイン時のみではありますが、ユーザーは2回ログインする必要があります。
NameIDはIdP側で設定されるものになり、NameIDに何が設定されるかをIdP側で確認することが可能です。
確認したIdPをSP側に設定することで、予めIdPユーザーとSPユーザーを紐づけることができます。
上記を行えば、初回ログインからIdPへのログインのみでSPへログインすることが可能になります。

まとめ

今回は、SSOの認証方式の一つであるSAML認証について解説しました。
SAML認証は、今ではラクスのサービスをはじめ、様々なSaaSのサービスで実装されている認証方式になるので、仕組みについて理解しておいて損はないと思います!

Copyright © RAKUS Co., Ltd. All rights reserved.