Open5

SAMLについて

abeuzZabeuzZ

参考記事

とても簡潔に表現すればユーザーをIdentity Provider(IdP)で認証させて、その認証(Assertion)を使って複数サービス(Service Provider(SP))の認証に使い回すというイメージか。

自分が携わっているサービスでもこの仕組みが用いられており、マルチサービスに対して一つずつログインするのではなく、認証がなければIdPにリダイレクトしてログインしてもらう形になっている。

abeuzZabeuzZ

ここで気になるのはOAuthとの違い。
他の記事でもOAuthとSAMLの違いとして以下の説明がなされる。

  • OAuth: 認可
  • SAML: 認可, 認証

なんとなく認証できる方がユーザーの特定までできるイメージがあるが、結局この違いが使い方としてどのような違いが生まれるのかがわからない。
わからないのでGPTに聞いてみた。

abeuzZabeuzZ

GPT解答 with 私見

OAuthとSAMLの違いについて、よく「OAuthは認可、SAMLは認証」と説明されますが、実際には両者の役割にはもう少し細かい違いがあります。ここでは、両者の違いと、それぞれの技術がどのようにユーザーを認証し、権限管理を行うかを説明します。

OAuth と SAML の主な違い

  1. OAuth (Open Authorization):

    • 認可 (Authorization) に焦点を当てたプロトコルです。
    • ユーザーがリソースにアクセスするための「トークン」を発行し、そのトークンを使ってアクセス権限を委譲します。
    • ユーザーのアイデンティティを保証することは主目的ではなく、ユーザーが特定のリソースにアクセスできる権限をアプリケーションに付与するために使われます。
    • たとえば、第三者アプリケーションがユーザーのGoogleドライブのファイルにアクセスできるように、OAuthを使って認可されます。

  2. SAML (Security Assertion Markup Language):

    • 認証 (Authentication) に焦点を当てたプロトコルです。
    • SAMLを使ってユーザーが誰であるかを特定するための情報（アサーション）が生成され、その情報がサービスプロバイダー (SP) に送信されます。
    • これにより、ユーザーのアイデンティティが確認され、シングルサインオン (SSO) が可能になります。
    • SAMLも、場合によっては権限情報（例えばユーザーが管理者か一般ユーザーかなど）を伝えることができますが、これは認証に付随する形です。

「認証」と「認可」の違い

  • 認証 (Authentication): ユーザーが誰であるかを確認するプロセス。例えば、SAMLを使ったSSOでは、ユーザーが一度ログインすれば、サービスプロバイダーは「このユーザーが本当に本人である」ということを確信します。
  • 認可 (Authorization): 認証されたユーザーがどのリソースにアクセスできるか、どのアクションを許可されているかを制御するプロセス。OAuthはこの部分に焦点を当てています。
私見

認証が個人、ユーザーを証明する。
認可が誰とかは関係なく、権限を渡してあげる感じかな？。
AWS IAMのロールによる権限付与みたいな感じか？

SAML での「認証」と権限の関係

SAMLは主に認証を行うプロトコルですが、認証が成功した後に、ユーザーの権限（ロールやアクセス権）を伝達することも可能です。この権限情報は、SAMLのアサーションに含まれ、サービスプロバイダーが受け取ることができます。

たとえば：

  • SAMLアサーションの中には、ユーザーが「管理者」なのか「一般ユーザー」なのか、あるいは特定のリソースにアクセスできるかという権限情報を含めることができます。
  • これにより、サービスプロバイダーはユーザーの役割に基づいて、どの機能やリソースにアクセスを許可するかを決定します。
私見

書いてある通り。ユーザーが特定できるなら、権限情報を含めて各サービスのバックエンドで制御可能。

OAuthでの「認可」とユーザー認証

OAuth自体は認可に特化していますが、OAuthの一部であるOpenID Connect (OIDC) を使うと、OAuthベースのプロトコルで認証も行えるようになります。OpenID Connectは、OAuth 2.0の上に構築されており、ユーザーのアイデンティティを確認する機能（認証）を追加します。

たとえば：

  • OpenID Connectでは、トークンの中にユーザー情報（IDトークン）を含めることができるため、サービスがユーザーのアイデンティティを確認することが可能です。
  • 一度ユーザーの認証が行われた後、OAuthを使ってそのユーザーがどのリソースにアクセスできるかの認可が行われます。

まとめ: 認証と認可の関係

  • SAMLは認証に焦点を当てており、ユーザーのアイデンティティを確認する役割が強いです。SAMLによってユーザーが認証されると、**権限情報（ロールやアクセス範囲）**も含めて、どのリソースにアクセスできるかをサービスプロバイダーが判断することが可能です。
  • OAuthは認可に特化しています。OAuthを使う場合、認証は別の手段（たとえばOIDCなど）で行う必要があります。OAuthでは、認証済みのユーザーが特定のリソースや機能にアクセスできるかを制御しますが、そのユーザーが誰であるかの確認自体はOAuthの範囲外です。

権限の設定は、どちらのプロトコルでも実施されますが、SAMLは認証とともに権限情報も提供する一方で、OAuthはユーザーがすでに認証されている前提で、どのリソースにアクセスできるかの認可を行います。

abeuzZabeuzZ

GPT解答 with 私見

IdP InitiatedとSP Initiatedの選択基準は、システムの要件やユーザー体験、セキュリティ、運用の観点から考慮する必要があります。以下は、どちらを採用するか検討する際のポイントです。

1. ユーザー体験

  • IdP Initiated:
    • 利点: ユーザーはまずIdPのログインページにアクセスし、一度ログインすると関連するすべてのサービスにアクセスできるため、シームレスなユーザー体験が提供されます。
    • 適しているケース: ユーザーが、複数のサービスを一度に使うことが一般的な場合や、特定のポータル（IdP）からアクセスを開始するシナリオに適しています。
  • SP Initiated:
    • 利点: ユーザーが特定のサービスに直接アクセスする場合に便利です。最初にSPのログインページにリダイレクトされ、必要に応じてIdPに認証を求められます。
    • 適しているケース: ユーザーが特定のサービス（SP）に直接アクセスするのが一般的な場合や、サービスごとに異なるアクセスパターンが存在する場合に適しています。
私見

ここが微妙によくわからん。IdP Initiatedでも結局先にSPのURLにアクセスされたらIdPにリダイレクトしそうな気が。
IdP Initiatedの場合はアクセスするまではリダイレクトすらさせないんだろうか。

2. システムの構成

  • IdP Initiated:
    • システムの構成が単純で、ユーザーが常にIdPを経由してアクセスする場合に適しています。例えば、社内ポータルなど、すべてのアクセスが特定のエントリーポイントから始まる場合に有効です。
  • SP Initiated:
    • より柔軟で、異なるアプリケーションやサービスに個別にアクセスする必要があるシステムに向いています。特定のサービス（SP）に直接アクセスできる方が便利な場合に好まれます。

3. セキュリティ要件

  • IdP Initiated:
    • セキュリティ面でのリスクとして、ユーザーが一度IdPにログインすると、複数のサービスに自動的にアクセスできるため、不正アクセスが発生した場合に複数のシステムが影響を受ける可能性があります。このため、厳密な認証管理と多要素認証（MFA）などが必要です。
  • SP Initiated:
    • セキュリティ管理がサービスごとに独立しているため、より細かく制御できます。SPごとに異なる認証・認可のポリシーを実施することが可能で、特定のサービスへのアクセスを制限しやすいです。

4. 統合と運用の複雑さ

  • IdP Initiated:
    • 簡素な統合が可能です。ユーザーがすべてのサービスにアクセスするための唯一の入口としてIdPを利用でき、統合の複雑さが軽減されます。
  • SP Initiated:
    • 柔軟な統合が可能ですが、サービスごとにアクセス制御を設定するため、より多くの設定や管理が必要になる場合があります。

5. ビジネス要件

  • IdP Initiated:
    • 従業員向けのシステムや企業内ポータルでは、IdP Initiatedがよく採用されます。すべてのサービスにアクセスする前に、まずIdPで認証を行うことで、ユーザー管理を一元化できます。
  • SP Initiated:
    • 顧客向けのアプリケーションや多様なユーザーアクセスパターンを持つサービスでは、SP Initiatedが一般的です。ユーザーが特定のアプリケーションに直接アクセスするため、柔軟な認証が求められる場合に向いています。
私見

実装するとしたら結局この視点が大事そう。
toC向けは基本SP Initiatedか。

まとめ

  • IdP Initiated: ユーザーが特定のIdPから一元的にサービスを利用する環境や、シームレスなユーザー体験を重視する場合に向いています。
  • SP Initiated: ユーザーが特定のサービスに直接アクセスする頻度が高く、より柔軟なアクセス管理が必要な場合に適しています。

採用する基準は、ユーザーのアクセスパターン、セキュリティ要件、運用の複雑さ、ビジネスのニーズに基づいて決定されます。