
はじめに
こんにちは!KYOSOの大岩です。
「他のSAPシステムで作った画面を、SAP Build Work Zone(以下、BWZ)のポータルから見られるようにしたい」。BTP上で業務アプリを開発していると、お客様からよくいただくご要望です。しかし、連携対象によっては「ポータルに埋め込むためのSSO化」によって既存の運用に大きな影響が出ることがあります。その典型例が、SAP Analytics Cloud(以下、SAC) のダッシュボードです。
BWZとSACはそれぞれ別のシステムです。そのため、BWZにタイルを置くだけでは、クリックするたびにSACのログイン画面が表示されてしまいます。シームレスに連携するには、両システム間でSSO(シングルサインオン)の設定が必要です。その鍵となるのが、SAP Cloud Identity Services(以下、CIS)を使ったSAML SSOです。
ただし、この方法には、利用ケースによっては事前に押さえておきたい注意点があります。
本記事では、次の3点を実機検証の結果とあわせてご紹介します。
・CISを使ったSACのSAML SSO設定と、BWZへの埋め込み手順
・SSO化によって生じる「SACに直接ログインできない問題」とその理由
・この問題に対する代替案の比較とおすすめ構成
本記事は次のような方におすすめです
・BWZやFiori LaunchpadにSACのストーリーを統合したいSAP BTP開発者・基盤担当者
・SACをすでに単独で運用していて、SSO化による既存ユーザーへの影響を知りたい方
・CISを使ったSAML連携の設計ポイントを押さえたい方
実現したいこと
ゴール:BWZからSACのダッシュボードをシームレスに開く
今回のゴールは、BWZのタイルをクリックすると、SACのストーリーがBWZの画面内に埋め込み表示される状態です。その際、SAC用のログインフォームは一切表示させません。

なぜSSOが必要なのか
BWZとSACは、それぞれ独立した認証の仕組みを持っています。何も設定しないままタイルを置くと、BWZにログインした後に、SACのログインを改めて求められます。
さらに厄介なのは、埋め込み表示(in-place表示)の場合、そもそもログインできない点です。SACのデフォルトIdP(SAP Cloud Identity)は、クリックジャッキング対策の都合でiframe内にログイン画面を表示できません。SAPの公式ドキュメント でも、埋め込みにはクリックジャッキング保護を制御できるカスタムIdPが必要だと案内されています。(SAP KBA 2597946)
つまり「BWZへの埋め込み」と「SAML SSO」はセットで考える必要があります。
CISを使う理由
BWZが動くBTPサブアカウントと、SACの両方が同じIdPを信頼していれば、BWZへのログイン時に確立したIdPセッションをSAC側でも再利用できます。BTPのアプリケーション認証にCISを使っているなら、同じCISテナントをSACのIdPにするのが最もシンプルです。
メリット
①入口の一元化:BTPの業務アプリとSACの分析画面を、BWZという1つのポータルから利用できる
②ログインは1回だけ:利用者はBWZにログインするだけで、SACのダッシュボードまで到達できる
③認証ポリシーの統一:多要素認証やリスクベース認証など、CIS側の認証強化をSACにもまとめて適用できる
前提条件・環境情報
| 項目 | 内容 |
|---|---|
| SAP Analytics Cloud | 単独で利用中のテナント(データセンター:jp10)。BWZに連携するストーリーは作成済み。 |
| SAP BTP | Cloud Foundry環境のサブアカウント。SAP Build Work Zone, standard editionを有効化済み。 |
| SAP Cloud Identity Services | BTPサブアカウントとTrust設定済みのテナントを使用。 |
| 作業ユーザーの権限 | SAC:System Owner/CIS:Administrator/BTP:Subaccount Administrator |
SACのデータセンター種別を確認しておきましょう
SACのURLに含まれるデータセンターが jp10 や eu10 のように2桁の数字の場合、SACは非SAPデータセンター(ハイパースケーラー)上で稼働しています。この場合、CIS側で追加の属性設定が必要です(手順1の10・11で解説します)。
CISテナントの確認方法
SAP Cloud Identity Servicesのテナント一覧にアクセスすると、自社で現在利用できるCISテナントを確認できます。テナントURLの末尾に /admin を付けると管理コンソールにアクセスできます。ログインできない場合は、テナント一覧のDetails>Showに表示される管理者にユーザー登録と管理者権限の付与を依頼してください。

SSO設定手順
全体の流れは次のとおりです。SACとCISは「お互いのメタデータを交換する」ことで信頼関係を結びます。
事前準備:BTPサブアカウントとCISのTrust設定
手順1:CISにSAC用のアプリケーションを作成する(SACのメタデータを登録)
手順2:SACの認証方法をSAML SSOに切り替える(CISのメタデータを登録)
作業前の注意:手順2の最後に保存した瞬間から、SACのログインはCIS経由に切り替わります。既存のSAC利用者への影響は後述の「注意点」で解説しますので、本番テナントで作業する前に必ず一読してください。
事前準備:BTPサブアカウントとCISのTrust設定
BWZへのログインに、SACと同じCISを使うための設定です。すでに設定済みの場合は読み飛ばしてください。
1. BTP Cockpitで対象サブアカウントの[Security]>[Trust Configuration]を開き、[Establish Trust]をクリック

2. 使用するCISテナントを選択し、[Establish Trust]をクリック


3. [Security]>[Users]で、BWZ経由でSACを利用するユーザーを、作成したCISテナントのIdPで登録し、BWZのロールコレクションを割り当てる

手順1:CISにSAC用のアプリケーションを作成する
SACのメタデータを取得する
1.System Owner権限のユーザーでSACにログインし、[システム]>[管理]をクリック

2. [セキュリティ]タブを開き、編集アイコンをクリック

3. 認証方法の設定画面で、SACのメタデータ(XMLファイル)をダウンロードする

CISにアプリケーションを作成する
4. CISの管理コンソール(https://<テナントID>.accounts.ondemand.com/admin)にログイン

5. [Applications & Resources]>[Tenant Settings]>[IdP-Initiated SSO]が有効になっていることを確認(無効なら有効化して保存)


6. [Applications]>[Create]で、SAC用のアプリケーションを作成する(Display Nameは任意、Home URLは空欄でOK、Protocol Typeは「SAML 2.0」)



7. 作成したアプリケーションの[SAML 2.0 Configuration]を開き、手順3でダウンロードしたSACのメタデータをアップロードして保存


ユーザー識別子と属性を設定する(ココが重要)
8. [Subject Name Identifier]を開き、プライマリ属性を「Email」に設定して保存


9. [Default Name ID Format]を開き、「Email」を選択して保存


10. (非SAPデータセンターの場合のみ)[Attributes]を開き、[Self-defined Attributes]に、SACが要求する属性(メールアドレスなど)をSource「Identity Directory」で追加する

11. (非SAPデータセンターの場合のみ)同じ[Attributes]画面で、Sourceに固定値を指定できる「Expression」を選び、属性名「Groups」・値「sac」を追加して保存

No8・9で指定する識別子は、後の手順2でSAC側に指定する「ユーザー属性」と必ず一致させます。今回はメールアドレスで紐づけています。
No10・11は見落としやすいポイントです。SACが非SAPデータセンターで稼働している場合、SAMLアサーションの属性名は大文字・小文字まで決められた名前(許可リスト)に合わせる必要があります。さらに、「Groups」属性に値「sac」が入っていないと属性が認識されません(KBA 2922448)。
手順2:SACの認証方法をSAML SSOに切り替える
CISのメタデータを取得する
1.CISの管理コンソールで[Tenant Settings]>[SAML 2.0 Configuration]を開く


2. [Download Metadata File]をクリックし、CISのメタデータを保存する

SACにCISを登録する
3. システムオーナー権限のユーザーでSACにログインし、[システム]>[管理]>[セキュリティ]タブの編集アイコンをクリック


4. 認証方法で[SAML シングルサインオン(SSO)]を選択

5. 手順2で保存したCISのメタデータをアップロード

6. ユーザー属性に「電子メール」を選択し、マッピング検証用のメールアドレス(自分のアカウント)を入力して[アカウント検証]をクリック

7. 表示されたURLをコピーし、設定画面は閉じずに、シークレットウィンドウで開いてCISのアカウントでログインする



8. 検証完了の画面が表示されたらシークレットウィンドウを閉じ、元の画面で[検証チェック]をクリック


9. 「アカウント検証済」と表示されたら[保存]をクリック

No.7でシークレットウィンドウを使うのは、既存のSACセッションの影響を避けるためです。通常のウィンドウだと、ログイン済みのセッションが使われて正しく検証できないことがあります。
ヒント:No.6の設定画面には「動的ユーザー作成(Dynamic User Creation)」というチェックボックスがあります。これは後述の代替案で活用しますが、SSO設定時点ではオフのまま進め、動作確認後に有効化するのがSAP推奨の進め方です。
BWZにSACのストーリーを配置する
SSOの準備ができたら、BWZにSACのストーリーをタイルとして配置します。
手順3:SACにBWZを「信頼されたソース」として登録する
SACは、許可していないサイトからのiframe埋め込みを拒否します。そのため、まずBWZのURLをSAC側に登録します。
1. SACで[システム]>[管理]>[アプリ統合]タブを開く


2. [信頼されたソース]に、BWZサイトのURLを追加して保存する

BWZのURLは、BWZのサイトディレクトリで対象サイトの[設定]を開くと確認できます。
形式は https://<サブドメイン>.launchpad.cfapps.<リージョン>.hana.ondemand.com です。
手順4:埋め込み用のストーリーURLを作成する
1.SACで対象のストーリーを開き、[ファイル]>[共有]をクリック

2. [デフォルトリンク]からストーリーのURLをコピーする

3. URLの末尾に、埋め込み表示用のパラメータを付与する
URLの形式と、付与したパラメータは次のとおりです。
https://<SACテナント>/sap/fpa/ui/tenants/<テナントID>/bo/story/<ストーリーID>?mode=embed&pageBar=disable&page=1&lang=ja
| パラメータ | 値の例 | 用途 |
|---|---|---|
| mode | embed | 埋め込み表示モードにする(メニューバーなどを非表示) |
| pageBar | disable/show | ページ切り替えバーの表示・非表示 |
| page | 1 | 初期表示するページ番号 |
| lang | ja | 表示言語(ISO 639-1の言語コード) |
手順5:BWZにアプリとタイルを登録する
1.BWZのサイトマネージャーで[コンテンツマネージャー]を開き、[新規]>[アプリ]をクリック


2. アプリ設定に次のとおり入力する
タイトル:タイルに表示する名前
システム:システムなし
URL:手順4で作成したストーリーURL
アプリを開く:配置済(BWZ内に埋め込み表示)

3. [ナビゲーション]タブに、セマンティックオブジェクト(例:SACstory)とアクション(例:display)を入力する

4. 必要に応じて[ビジュアル化]タブでタイルのサブタイトルやアイコンを設定し、[保存]をクリック

5. 作成したアプリを、任意のロールとグループに割り当てる
※今回は既存のEveryoneロールを使用するが、任意のロールで良い


実装結果
BWZにログインすると、SACのタイルが表示されます。タイルをクリックすると、SACのログイン画面を経由せずに、ストーリーがBWZ内に埋め込み表示されます。

注意点:SACに「直接」ログインする場合もCISが必須になる
ここまでの設定で、BWZ経由のSSOは実現できました。しかし運用を考えると、見過ごせない問題が1つあります。
SACの認証方法は「どちらか一方」しか選べない
SACの認証方法は、テナント全体で「SAP Cloud Identity(デフォルト)」か「SAML シングルサインオン」のどちらか一方です。SAML SSOに切り替えると、BWZを経由せずSACのURLに直接アクセスした場合も、CISのログイン画面が表示されます。
その結果、次のような影響が出ます。
・SACだけを使っているユーザーも、CISにユーザー登録しないとSACにログインできなくなる
・SACとCISの両方でユーザーを登録・管理する必要がある(SAC側のユーザーとCIS側のユーザーはメールアドレス で紐づける)
・これまでのSACのパスワードは使えなくなり、利用者にはCISでのパスワード設定をお願いすることになる
「SAC利用者だけはSACユーザーでログイン」はできない
当社でも、「BWZ経由ではSSO、SACに直接アクセスするときは従来のSACユーザーでログイン」という並存構成を検討しました。しかし、これは実現できません。
SAPのKBA 2973936 によると、SACでSAML SSOを構成すると、SSO認証を回避する方法はありません。URLパラメータで一時的に回避することもできず、SAPのCustomer Influenceに改善要望が出されている段階です。
なお、SAC側には「OAuthクライアント」と「信頼されたIdP」を登録する仕組みもあります。これを使えば、認証方法をデフォルトのままでも、外部アプリからSAML Bearer Assertionを使ってSACのAPIを呼び出せます。ただし、これはAPIアクセス用の仕組みです。ストーリー画面のiframe表示に必要なブラウザのログインセッションは作れないため、今回の目的には使えません。
代替案の比較:「直接ログイン問題」とどう付き合うか
SAML SSOとSACのデフォルトログインを並存できない以上、選択肢は「SSOを諦める」か「SSOを前提にユーザー管理の負荷を下げる」かのどちらかです。こちらで検討した案を比較しました。
| 案 | BWZ内への埋め込み | ログイン回数 | SAC単独利用者への影響 | ユーザー管理の負荷 | 評価 |
|---|---|---|---|---|---|
| A. SAML SSO(本記事の構成) | できる | 1回 | CISへの登録が必要 | 高い(SACとCISで二重管理) | 機能は満たすが運用が重い |
| B. SSOなし+別タブのリンクタイル | できない | 2回 | なし | 低い(現状のまま) | 小規模・暫定対応向け |
| C. SAML SSO+ユーザー管理の自動化 | できる | 1回 | CISでのログインに統一 | 低い(CISで一元管理) | 当社のおすすめ |
案B:SSOを諦めて、別タブ表示のリンクタイルにする
SACの認証方法を「SAP Cloud Identity」(デフォルト)のまま変更せず、BWZのアプリ登録で[アプリを開く]を「新しいタブ」にし、SACのストーリーURLをリンクとして置く方法です。SAC側の認証方法は変えないため、SAC単独利用者には一切影響がありません。

一方で、BWZ内への埋め込みはできません。新しいタブでSACのログイン画面が表示されるため、BWZ経由で表示するさい利用者は2回(BWZ、SAC)ログインすることになります。SACのセッションが残っている間はログインを省略できるので、「SACを日常的に使う少人数のユーザー」が対象なら現実的な選択肢です。
案C:SSOを前提に、ユーザー管理を自動化する(おすすめ)
「SACとCISの二重管理が大変」という課題は、SAC標準の機能とCISの機能で大きく軽減できます。発想を変えて、ユーザー管理の起点をCISに一本化するのがポイントです。
①動的ユーザー作成(Dynamic User Creation):SACのSAML設定で有効にすると、CISで認証されたユーザーがSACに存在しない場合、初回ログイン時にSACユーザーが自動作成されます。SAML属性を使ったチームやロールの自動割り当ても可能です(KBA 2922448)。

②Identity Provisioning(IPS):CISに含まれるIdentity Provisioningには、SAC向けのコネクターが標準で用意されています。CISをソース、SACをターゲットにすれば、ユーザーとグループをCISからSACへ定期同期できます(SAP公式ブログ)。
③既存ユーザーの一括移行:SACの既存ユーザーは、CISの[Import Users]でCSVから一括登録できます。登録後にパスワード設定メールを送れば、利用者自身で初回設定を完了できます。
SAC単独利用者もCISでログインする点は変わりません。しかし「ユーザー登録はCISだけ」という運用にできれば、二重管理の負荷はほぼなくなります。さらに、多要素認証などのセキュリティ強化をSACにもまとめて適用できるのは、むしろメリットです。
さいごに
本記事では、CISを使ったSACのSAML SSO設定と、BWZへのSACストーリーの埋め込み手順をご紹介しました。
設定自体はメタデータの交換と数か所の属性設定で完了します。一方で、SSO化はSACテナント全体の認証方法を切り替える作業であり、SAC単独利用者にも影響が及ぶ点には注意が必要です。導入前に「誰がどこからSACを使っているか」を棚卸しし、ユーザー管理をCISに寄せる設計(案C)までセットで検討することをおすすめします。
SAPへの要望としては、BWZ経由のアクセスだけをSSOにして、SACへの直接アクセスでは従来のログインも選べるような、認証方法の併用をサポートしてほしいところです。KBAにもある通り改善要望は出されているので、今後のアップデートに期待しています。
今回の「CISをハブにして、各SAPクラウドサービスとBWZを1つの認証でつなぐ」考え方は、SAC以外のSAPシステムとの連携にも応用できます。同じような統合を検討されている方の参考になれば幸いです。最後までお読みいただき、ありがとうございました!
投稿者プロフィール

-
2015年入社。会計管理システムやBIシステムのパッケージ開発を経て、現在はSAP BTP案件にて開発リーダーを担当しています。
【主な技術領域】
SAP BTP関連(Fioriアプリケーションほか)、SAP Analytics Cloud、AWS
【イベント参加実績】
2022年 JSUG INFO 企画編集委員
2024年 11月 SAUG-x 2024(オーストラリア・メルボルン)
2025年 2月 SAP Inside Track TOKYO 2025(登壇)


