SAP Analytics CloudのLive Data Connectionを設定する：SAML連携

2020.06.24

この記事を書いたメンバー：

清野宏

SAP Analytics Cloudは、SAP社が提供するSaaS型のデータ分析クラウドサービスです。
今回、SAP Analytics Cloudとオンプレミスのシステムとのデータ連携検証する機会がありましたので、設定する上で重要と感じた内容を2つ、その設定ポイントを説明したいと思います。内容は下記になります。

SAML連携
CORS対応

全2回に分け、今回は ”SAML連携” について説明します。
SAP Analytics Cloud関連ブログはこちらをご覧ください。

SAP Analytics Cloudとは？

まず初めに、SAP Analytics Cloudについて簡単にご紹介します。
冒頭に書きましたように、SAP Analytics Cloud（以降、SACと略します）は、SAP社が提供するクラウドベースの分析ソリューションです。SAP社のSAP Cloud Platform 上で稼働し、クラウド、オンプレミス問わず、企業が有するデータの分析・可視化、予算・計画管理、予測・相関分析などの機能を提供します。
分析対象となるデータのソースシステムとSACのデータ接続方式には、大きく2種類あります。

Live Data Connection
Import Data Connection

出典：SAP

どちらのデータ接続方式を利用するかは、対応するソースシステム、ソースシステムが置かれているネットワーク環境等に応じて検討が必要ですが、それぞれの特徴は次のとおりです。

Live Data Connection
- SACにデータ複製しない
- 大量データ転送が発生しない
- リアルタイムなデータアクセス
- SACから「画面構成」「グラフ定義」等のメタデータのみを読み込み
- 機微データをセキュアに分析
- 既存のデータモデルをそのまま分析に使用
Import Data Connection
- SACにデータ複製する
- 手動もしくはジョブでのデータアップロード
- SAP HANAのパワーを生かした高速分析
- すべてのアナリティクス機能が利用可能
- データモデリングのセルフサービス化

これらデータ接続方式のうち、Live Data Connectionは、上記のとおりSACにアクセスするブラウザ上で、画面やデータモデル等の分析ロジックをSACから、分析データを直接ソースシステムから取得し分析するため、データを外部に移動する必要がない点が最大の特徴です。

SACにログイン後、ブラウザ上で動作するJavaScriptにより、Ajax通信でソースシステムからデータ取得、取得したデータの分析といった一連の動作を実行します。
ここで1つ認証に関して、検討ポイントがあります。
ブラウザから複数システムにアクセスが発生するため、それらシステムへの認証がそれぞれ必要になりますが、パスワードを用いた複数システムへの認証を都度実行するのは少々面倒です。連携用のシステムユーザーのようなものを用い、パスワードといったクレデンシャル情報を登録しておけば回避できそうですが、パスワード変更対応やユーザーに応じたアクセス制御が煩雑になります。
この点に関して、SACはSAMLに対応しており、SACへのログイン以外に複数システムに対してもシングルサインオンできる機能があります。
今回はこのLive Data Connectionでシングルサインオンする際のSAML連携について設定ポイントを説明したいと思います。
なお、SACのデータ接続には、接続方式ごとにサポートされるソースシステムの製品、バージョン等の前提条件がありますのでご利用前にご確認ください。

システム構成

今回、設定検証したシステム構成は下記になります。

SACのソースシステムはオンプレミスのシステムを想定したSAP BWです。
SACとSAP BWのログイン認証には、IdP（IdPといったSAML用語は後ほど説明します）にAzure ADを利用してSAMLによるシングルサインオンを設定します。SACとSAP BW間はブラウザを介してLive Data Connectionでデータ接続します。
各システムのSAML連携における役割は下記のとおりです。

IdP
- Azure AD
SP
- SAP Analytics Cloud
- SAP BW

Live Data ConnectionでSAMLによるシングルサインオンを設定する場合、SACとソースシステムは同じIdPを利用する必要があります。

SAP Analytics CloudのSAML連携

それでは、SAP Analytics CloudのSAML連携の設定ポイントを説明します。詳細な手順は本記事の参考リンクを参照ください。
説明するにあたって、予めSAML独特な用語とSAML認証シーケンスを理解しておくと、設定やトラブル対応時に混乱せずに済みます。そこで、初めにSAML概要を説明し、続いてSAP Analytics CloudのSAML連携の設定ポイントを説明したいと思います。

（１）SAML概要

SAMLとは？

SAML（Secure Assertion Markup Lauguageの略）は、複数システムで認証情報を共有するためのXML仕様です。

エンティティ（セキュリティ情報をやり取りするSAMLの登場人物）間で信頼関係を作り、認証等のセキュリティ情報（アサーションと呼ぶ）をやり取りし、マルチドメイン環境でのシングルサインオンを実現するフレームワーク
エンティティは下記3つから成る
- ユーザー：　SPが提供するWebサービスの利用者（実体はWebブラウザ等）
- Identity Provider（IdP）：　ユーザーの資格情報を認証して、そのIDやIDの持つ情報の正当性を保証しセキュリティ情報を提供するサイト
- Service Provider（SP）：　セキュリティ情報を受け取り、その有効性を検証の上、Webサービスを提供するサイト
IdP/SP間で事前にSAMLの信頼関係を設定する
- 信頼関係はPKIと暗号化により実現する
- IdPはSPの、SPはIdPのPKI証明書を持つことでそれぞれを信頼する
IdP/SP間で事前に信頼関係を設定する必要があることから、エンタープライズ系のアプリケーションでの利用実績が多い

SAML仕様（用語説明）

SAMLは次のような仕様をXML形式で規定しています。

SAMLアサーション
- 認証、属性、認可に関する情報を規定
SAMLプロトコル
- エンティティ間でSAMLアサーションを交換する要求・応答の手順を規定
SAMLバインディング
- SAMLプロトコルを実際の通信プロトコル（HTTP、SOAP）にマッピングする方法を規定
SAMLプロファイル
- 特定のユースケースを実現するためのアサーション、プロトコル、バインディングの組み合わせを規定
SAMLメタデータ
- プロファイルの実現に必要な情報を規定（アサーションをやり取りするためのエンドポイントURLや利用するバインディング、PKI証明書等）

SAML認証シーケンス

SAMLはIdP/SPのどちらを起点としてSAML認証シーケンスを開始するかで2種類に分けられます。

SP-Initiated・・・SPを起点としたSAML認証シーケンス
IdP-Initiated・・・IdPを起点としたSAML認証シーケンス

どちらを利用するかは、SPがどちらをサポートしているかに依ります。
さらに、バインディングの違いにより下記のように分類されます。（Web Browser SSOプロファイルの場合）

SP-Initiated SSO:Redirect/POST Bindings
SP-Initiated SSO:POST/Artifact Bindings
IdP-Initiated SSO:POST Binding

SACおよびSAP BW(NetWeaver)は、「SP-Initiated SSO:Redirect/POST Bindings」のSAML認証をサポートしています。フローは下図を参照ください。

出典：Security Assertion Markup Language V2.0 Technical Overview

「SP-Initiated SSO:Redirect/POST Bindings」の由来となる、上図のポイントは下記になります。

ステップ①：SPを起点として認証シーケンス開始（SP-Iinitiated）
ステップ②：SPの認証要求メッセージAuthnRequestをIdPにリダイレクト（HTTP Redirect Binding）
ステップ⑥：IdPからの認証情報メッセージAuthnResponseをSPにPOST（HTTP Post Binding）

ユーザー（Browser）を介してアサーションをやり取りするため、IdPとSPが直接通信が不要な点がメリット（IdP/SP間のネットワーク、ファイアウォール等の考慮不要）です。他シーケンスの詳細は、Technical Overview を参照ください。

SAML概要は以上です。以上踏まえ、設定ポイントを解説します。

（２）SACのSAML連携設定

SAML連携設定は、IdPとSP間のSAMLの信頼関係を設定することです。
Live Data ConnectionでSAML連携設定する場合、IdPであるAzure ADと信頼関係を設定するSPは、SACとソースシステム（今回はSAP BW）になります。

Azure AD と SAC 間のSAML連携設定
Azure AD と SAP BW 間のSAML連携設定

それぞれのSAML連携の設定手順は異なりますが、SAML認証シーケンスは「SP-Initiated SSO:Redirect/POST Bindings」で同じです。今回説明する設定ポイントは大きく変わりませんので、SACを例に説明します。

SAML連携設定に必要な情報

SAML連携設定で必要なIdP、SPの情報には下記のようなものがあります。SP/IdP-Initiatedの違いやIdP/SPのSAML実装により必要な情報は異なります。

IdP側の設定に必要なSPの情報
- SPのエンティティID
- バインディングのタイプ（HTTPリダイレクト等）
- Assertion Consumer Service URL
- サインオンURL
- SPのPKI証明書、等
SP側の設定に必要なIdPの情報
- IdPのエンティティID
- バインディングのタイプ（HTTP POST等）
- リダイレクトURL
- ログアウトURL
- dPのPKI証明書
- ユーザー属性とマッピング方法、等

これら情報の多くは、IdP/SPからXML形式のメタデータとして得ることができます。このメタデータを利用しSAML連携設定することも可能です。メタデータを利用しない場合やメタデータに値が無い場合は手動で設定します。

IdP(Azure AD)側の設定

まず、IdPであるAzure ADのSAML設定です。
AzureポータルでギャラリーからSAP Analytics Cloud用のSAML設定テンプレートを選択できます。

SAP Analytics CloudのSAML設定画面です。ギャラリーから選択したため、SP-Iinitiatedの場合に必須となっている「サインオンURL」が入力”必須”項目となっています。

①基本的なSAML構成
SPとの信頼関係を設定します。SPのメタデータをアップロードし設定可能です。入力必須項目の説明は下記のとおりです。

識別子（エンティティID)
- Azure AD内でSPを一意に識別します。この値は、SP側で決めるものなので、Azure ADはそれに合わせて設定します。また、ここで設定した値は、Azure ADからSPへのSAMLアサーションに含まれ、SP側はこのIDが一致しているか検証します。
応答URL（Assertion Consumer Service URL）
- SPがSAMLアサーションを受け取るURLを指定します。（「SP-Initiated SSO:Redirect/POST Bindings」ステップ⑥でアクセスするURL）
サインオンURL
- このURL（「SP-Initiated SSO:Redirect/POST Bindings」ステップ①でアクセスするURL）にアクセスすると、SPはAzure ADにユーザーをリダイレクトします。

これら情報は、SPのメタデータに下記のように設定されています。下記はSACからダウンロードしたメタデータです。

「識別子」は、<md:EntityDescriptor>要素の<entityID>属性の値です。参考リンクのチュートリアルで”Azure AD では <protocol>://<name> という形式の名前が想定されている”と記載がありましたが未確認です。一般にはIdPとSP間で一意のものとして識別できればURL形式以外でも問題ありません。

「応答URL」は、<md:AssertionConsumerService>要素の<Location>属性の値です。デフォルトバインディングが HTTP-POST になっています。

「サインオンURL」はメタデータに値は無く、SAC利用契約時にSAP社から提供されるSACテナントURLを手動で入力します。

「SPのPKI証明書」は、Azure ADではSAML設定項目としてありません。
「NameIDフォーマット」は、次のセクションで説明します。

②ユーザー属性とクレーム
ユーザー属性を設定します。
特に「一意のユーザーID」（NameID）は、IdPとSPのユーザーをマッピングする識別子として利用されます。

SPのメタデータにある「NameIDフォーマット」は、SPがIdPに対してリクエストするNameIDのフォーマットを指定するものですが、複数あるうち、実際にSACからAzure ADにリダイレクト（「SP-Initiated SSO:Redirect/POST Bindings」ステップ②）されたSAMLアサーションをトレースすると”unspecified”が指定されていました。

”unspecified”は、特定のフォーマットをリクエストしないことを意味します。
これに対するAzure ADのレスポンスは、ユーザー属性「一意のユーザーID」（NameID）の詳細にあるように、「名前識別子の形式」（NameIDフォーマット）に”電子メールアドレス”を指定しています。

実際にAzure ADからSACへのSAMLアサーション（「SP-Initiated SSO:Redirect/POST Bindings」ステップ⑥）をトレースすると、NameIDには”emailAddress”の値がセットされていました。

SP側はこれに合わせてユーザ属性を設定する必要があります。

③SAML署名証明書
IdPのメタデータをダウンロードします。このメタデータはSP側で設定に利用します。

SPのメタデータと同様に、IdPの識別子（エンティティID）、PKI証明書、利用するバインディング、リダイレクト先のURL（「SP-Initiated:Redirect/POST Bindings」ステップ②のURL）等が含まれています。

SP(SAC)側の設定

次に、SPであるSACのSAML設定です。下図は、SACログイン後のSAML設定画面です。Azure ADと比べるとシンプルです。Azure ADでの設定同様、信頼するIdPの情報を登録します。

ステップ1：サービスプロバイダメタデータのダウンロード
Azure ADのSAML設定「①基本的なSAML構成」で利用するSPのメタデータをダウンロードします。

ステップ2：アイデンティティプロバイダメタデータのアップロード
IdPとの信頼関係を設定します。Azure ADのSAML設定「③SAML署名証明書」でダウンロードしたIdPのメタデータをアップロードします。

個別に設定する項目がありませんが、Azure ADのIdPの識別子（エンティティID）、PKI証明書、利用するバインディング、リダイレクト先のURL等を設定し信頼関係を結びます。

ステップ3：アイデンティティプロバイダにマップするためのユーザ属性の選択
IdPのユーザーとマップするユーザ属性を指定します。
Azure ADのNameIDは”emailAddress”が利用されているので、ユーザ属性に「電子メール」を選択します。

ユーザ属性の「電子メール」は、SACのユーザー管理画面で表示される電子メールの値が利用されます。ここで各ユーザーの電子メールを設定しておく必要があります。

以上、SACとAzure ADのSAML設定時のポイントでした。

SAP BWに関しても同様にAzure ADとSAML設定をすると、Live Data Connection接続時、SAMLによるシングルサインオンを実現できます。

SACのSAML連携設定の注意点

SACのSAML連携設定の注意点を2つ記載します。

SAML設定するときのユーザー

SACのSAML設定するユーザーは、システムオーナーロールが割り当たっている必要があります。システムオーナーロールを割り当てられるユーザーは1ライセンスにつき1名です。
設定作業時は、システムオーナーであるユーザーでログインするか、事前に作業者のユーザーにシステムオーナーロールを転送しておく必要があります。

SAML連携が上手くいかなくなったときのリカバリ

SACの認証方法をSAMLに切り替えた際、設定不備によりSACへログイン出来なくなる可能性があります。その場合に備えて、設定修復のためのウェブサイト（アイデンティティプロバイダ管理ツール）がSAPから提供されています。

ツールを用いた設定修復には、事前にSACのSAML設定画面からツールとの接続設定をしておく必要があります。接続設定後、下記URLにシステムオーナーと同じ電子メールアドレスを持つSユーザーでログインすると修復作業ができます。

・　アイデンティティプロバイダ管理ツールURL
https://console.<data center>.sapanalytics.cloud/idp-admin/

<data center>は、SACテナントURLがhttps://<your domain>.jp10.hanacloudservices.cloud.sapの場合は”jp10”となります。詳細は下記SAPノートを参照ください。
2908073 – How to revert the IdP used by SAP Analytics Cloud when no access is available to the tenant

まとめ

SAML認証シーケンスと絡めて、SACのSAML連携の設定ポイントを説明しました。SAML用語は独特な表現が多いので、何を設定しているか分からなくなることがありますが、認証シーケンス、用語の意味を理解すれば、トラブル発生時のログ解析も意味不明になることは無いかと思います。
次回は、Live Data Connectionの ”CORS対応” について説明します。
SAP Analytics CloudのLive Data Connectionを設定する：CORS対応