SAML 認証の仕組み、そして、エンタープライズカスタマーにとって今も必要である理由

SAML 2.0（セキュリティアサーションマークアップ言語）は、クロスドメインシングルサインオン（SSO）を提供するために作られたオープン基準です。言い換えると、ユーザーがシステム内で認証し、各自の認証の証明を提供することで、他のシステムにアクセスできるようになります。

SAML は、2005年から使用されていますが、B2B および B2E アプリケーションの ID フェデレーションでは今も頻繁に使用されています。このように広範囲で使われていることが、持続的な成功につながっています。一般的には、ビジネスと企業の間でシームレスな SSO を提供しようとする場合、SAML を処理できることが必要です。実際に、SAML 2.0 プロトコルは、主に企業や政府のアプリケーションに使用されています。

SAML は、XML を用いて、ユーザーの ＩD データを表示し、データ転送メカニズムにシンプルな HTTP を使用しています。

この記事では、SAML とは何か、他の ID 標準とどう違うのかについてご説明します。また、Auth0 などのID 管理パートナーは、どのように方程式に当てはまるのかを考察していきます。

SAML は、XML ベースの認証プロトコルで、ID プロバイダー(IdP)（ユーザーの認証情報を管理・保管する事業体）は、エンドユーザーが、仕事やウェブサイトで毎日利用するアプリのコレクションなどサービスプロバイダー（SP）にアクセスできるようにする、デジタル署名入りの XML ドキュメント（SAML アサーション）をエクスチェンジします。

ＩD プロバイダー（IdP）との間でデータのリクエストと受信を行うサービスは、リライングパーティ（RP）として知られ、SAML アサーションの中に収められているユーザー ID データは、属性（例：メールアドレス、氏名、電話番号）という形になっています。

現実世界でいうところの海外旅行のようなものです。自分の国から米国に行きたい旅行者のことを考えてみてください。国境に着くと、認証とおそらくアクセスの認可のためにパスポートを求められます。旅行者がパスポートを所持していない場合は、パスポートを取得するために自国政府にリダイレクトされます。

旅行者にパスポートがあれば、国境取締局の職員に ID を証明することができます。国境ではパスポートの有効性とパスポートの ID データを確認し、旅行者を入国させるか否かを判断します。

In この場合：

• 旅行者の母国が、ID プロバイダーです
• 米国政府を代表する国境取締局の職員は、リライングパーティーです。
• 国家としての米国は、サービスプロバイダーです
• パスポートは、 SAML アサーションです

米国は、予備協定を結んでいる国のパスポートのみを受け入れると考えてください。

この現実世界のシナリオをコンピューターシステムに当てはめることができます。

仮に、あなたが複数のアプリケーションを持つ企業の、ユーザー認証の中央ポイントに勤務しているとしましょう。 仮に、提携会社には似たような組織があり、特定のプロジェクトに関わる提携会社の数人の社員が、あなたの勤め先のアプリケーションにアクセスしなければならないとします。SAML を2つのシステム間の信用を確立する予備協定とし、海外旅行のシナリオにたとえることができます。

提携会社の社員は、あなたの勤務先のアプリケーションにアクセスしようとします。提携会社の社員であるユーザーは、あなたの勤務先に所属していないため、勤務先のシステムは、ID の証明を取得するよう、ユーザーを提携会社のシステムにリダイレクトします。提携会社のシステムは、ユーザーを認証し、ユーザーに SAML アサーションを提供します。勤務先のシステムは、そのアサーションを確認し、ユーザーにアクセスを許可します。

認証ワークフローは、SAML を使って、サービスプロバイダーまたは ＩD プロバイダーのいずれかによって開始することができます。IdP-initiated 認証は、社員が会社のダッシュボードにログインし、会社が購入したツールを外出先で使いたい場合に行われる場合があります。この場合、IdP は、自動的に社員がログインできるようウェブブラウザを経由し SAML アサーションを送信します。

SP-initiated 認証は、社員が社外サイト（SP）にログインしようとする際に行われます。サイトは、社員を会社のシングルサインオン（SSO）のログインページにリダイレクトして、各自の認証情報を入力し、認証を行います。認証後、社員はその ID を証明する SAML アサーションとともに外部サイトにリダイレクトされます。

開発者は時として、なぜSAML プロトコルを実装しなければならないのかと質問することがあります。なぜ、SAML に時間を割く価値があるのか？ テクニカルチュートリアルでより詳しくご説明しますが、メリットとして以下が挙げられます：

標準化：オープン基準プロトコルである SAML は、相互運用性を可能にします。

ユーザー体験：ユーザーは、認証を繰り返すことなく、たった1回サインインするだけで、複数のサービスプロバイダーにアクセスすることができるので、迅速かつ良好なサービスを体験することができます。また、パスワードリセットや回復などのパスワード管理の問題を集中化することができます。

ディレクトリの疎結合：SAML は、ディレクトリの間でユーザー情報を保持したり、同期したりする必要がありません。

セキュリティの強化：SAML は、安全な IdP で発生する、単一の認証ポイントを提供します。クレデンシャルレプリケーション（シャドウアカウント）および同期化を回避することで、SAML はID 盗難の攻撃ポイントを減らします。

サービスプロバイダーのコスト削減：SAML があれば、複数のサービスにわたってアカウント情報を保持する必要がありません。ID プロバイダーがこの責任を負います。

コンプライアンスの強化：データプライバシー時代では、オンザフライで属性を受け取り、不要になるとそれらを忘れる機能は、会社の法的責任を軽減します。業務を遂行するためのシャドウアカウントを作成する必要はありません。

社内でのSAML 2.0 の実装は、ややこしく、うっかり XML 署名や暗号にクラックを残したままにしてしまい、アプリが攻撃されやすくなってしまうと、開発者は断言します。ただし、Auth0 のような ＩD パートナーがいれば、SAML 認証をシンプルにかつセキュアにすることができます。

Auth0 の ユニバーサルログインを利用すれば、すばやくSAMLを設定し、御社の企業顧客に提供できます。Auth0 を使えば、SAML のすべてのメリットを得られるだけでなく、単独の ID プロバイダーとしての責任とリスクを軽減します。

Auth0 は、あらゆる言語や API に接続できます. ID プロバイダー、サービスプロバイダー、または両方の役割を務めることができます。

SAML SP を実装し、Auth0 をID プロバイダーとして利用すると、ユーザーは、Auth0 にリダイレクトされてログインし、Auth0 がユーザーを認証します。Auth0 は、認証接続については不可知論者であり、ソーシャルプロバイダー、データベース、LDAPディレクトリ（アクティブディレクトリなど）、その他のSAML IdPs を使うことができます。

御社のアプリケーションが Auth0 を使って SAML SP に送信する場合は、Auth0 はそのリクエストを SAML 認証リクエストに翻訳して、SAML IdP にそれを転送します。Auth0 への送信にはどんなプロトコルを使っても構いません。

IdaaS プロバイダーであるAuth0 は、御社がユーザーに 複数の ID プロバイダーを提供できるようにします。このように、他のユーザーがデータベース接続をする一方で、1つの組織のユーザーが、各自の G-Suite クレデンシャルでログインすることができます。

他のプロトコルに加えて、OAuth や OpenID Connect などの SAML 2.0 を提供するエンタープライズカスタマーを集客したい SaaS 企業にとっては、長年そうしたプロトコルを使用してきたカスタマーのニーズにも十分に柔軟に対応できることを、シンプルにアピールできます。

[IAM 入門ページ]（https://auth0.com/intro-to-iam/）で、さらに多くの、ID とアクセスの管理に関するトピックをご覧ください。