Security Assertion Markup Language (SAML) は XML ベースのフレームワークです。サービス プロバイダー (SP) と ID プロバイダー (IdP) 間の通信が可能になり、認証 (ログインするユーザーの本人確認) と認可 (ログインしたユーザーにアクセス権があることの確認) がスムーズになります。

SAML の使用には次のようなメリットがあります。

  • 実装に左右されず、ベンダーやプラットフォーム固有のアーキテクチャ、実装に関連する一般的な問題がなくなる、システム間の相互運用性による標準化
  • 追加の認証を行うことなく (サービス プロバイダーごとに認証するよりもスピーディ)、一度サインインするだけで複数のサービス プロバイダーにユーザーがアクセスできるようになる、質の高いエクスペリエンス
  • リセットや回復などのパスワードの問題がなくなる認証システム
  • 安全な ID プロバイダー (IdP) が唯一の認証元になることによるセキュリティの強化。資格情報は IdP のファイアウォール境界内に留まります。
  • ディレクトリの疎結合 (つまり、ユーザー情報をディレクトリ間で同期する必要がない)

SAML では自社で認証をコントロールできるため、ユーザーのパスワードが Anaplan に保存されません。 

SAML フローでは、Anaplan がサービス プロバイダー (SP)、組織が IdP になります。これらの手順では、Anaplan が SAML 認証を開始する SP であり、Anaplan が提供するフレンドリー URL をエンド ユーザーが 選択することを前提としています。フレンドリー URL の形式には固有の構成要件があります。

Anaplan では以下をサポートする標準の SAML 2.0 フレームワークを実装します。

  • 署名済み/未署名 AuthnRequests
  • 必要に応じてメッセージの暗号化が解除されている、検証済みの SAML 認証応答 (AuthnResp) のデジタル署名
  • 102048 ビット 48 ビット キー
  • Idp アサーション用の HTTP REDIRECT SAML バインディング プロファイル
  • HTTP REDIRECT (GET) を使用した、SP が開始する SAML
  • Microsoft ADFS、Okta、Ping Federate などのフェデレーション サーバー ベンダーのサポート

SAML フレームワークにはオプションの属性が用意されています。検証されるのはタイムスタンプ属性だけです。他の検証が必要な場合は、標準の SAML 2.0 フレームワークの範囲外で作業を行うことができます。

ユーザーが社内ネットワーク内にいる必要はありません。SAML の概要については、http://wso2.com/library/articles/2014/02/introduction-to-security-assertion-markup-language-2.0 を参照してください。
このウェブ ページには、IDP、SP、ブラウザー間の 3 方向の関係を示す図が含まれています。