Anaplan での SAML 認証

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) のデジタル署名
• 最小サイズが 2048 ビットの SAML RSA キー
• IdP アサーション用の HTTP REDIRECT SAML バインディング プロファイル
• HTTP REDIRECT (GET) を使用した、SP が開始する SAML
• Microsoft ADFS、Okta、Ping Federate などのフェデレーション サーバー ベンダーのサポート

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