SAP Fiori認証とSSOの基礎：信頼関係の設定とトラブルシューティング

SAP Fiori LaunchpadのSSOは、利用者が一度認証した情報を使って、複数のSAP Fioriアプリケーションへ追加のパスワード入力なしでアクセスする仕組みです。実際の運用では、ブラウザ、Web Dispatcherまたはリバースプロキシ、Fioriフロントエンドサーバー、バックエンドのABAPシステム、そしてIdentity Provider（IdP）が連携します。認証が成功してもタイルが表示されない、アプリ起動時だけログインを求められる、といった事象は、認証と認可を分けて確認すると切り分けやすくなります。

01SAP Fioriの認証構成

SAP Fioriのログイン処理では、ブラウザがアクセスするURLと、認証情報を検証するシステムを最初に整理します。代表的な構成では、利用者がFiori LaunchpadのURLへアクセスし、Web Dispatcherがリクエストを受けてFioriフロントエンドサーバーへ転送します。フロントエンドサーバーはIdPとの認証結果を受け取り、ABAPユーザーへ対応付けたセッションを作成します。

この構成で重要なのは、認証が成立することと、業務アプリケーションを実行できることが別の段階である点です。Launchpadまで到達できても、カタログ、スペース、ページ、ロール、バックエンド権限のいずれかが不足すると、利用者には空の画面や権限エラーとして見える場合があります。

02SSO方式と信頼関係

ブラウザベースのFiori SSOでは、SAML 2.0を使ったIdP連携が一般的です。IdPは利用者を認証し、サービスプロバイダーとして登録されたFiori側へ署名付きの認証アサーションを返します。Fiori側は、登録済みのIdP証明書を使ってアサーションの署名を検証し、アサーション内のユーザー識別子をABAPユーザーへ対応付けます。

信頼関係は片側だけに登録して完了するものではありません。IdPにはFiori側のサービスプロバイダー情報、Fiori側にはIdPのメタデータまたは証明書を登録します。双方で次の値をそろえて管理します。

• エンティティID
• Assertion Consumer Service（ACS）URL
• ログオンURLとリダイレクト先
• 署名証明書と有効期限
• NameIDまたはユーザー識別子の形式
• HTTPSのホスト名とポート

ホスト名は利用者が入力するURL、証明書のSubjectまたはSAN、SAMLメタデータのURLと一致させます。Web Dispatcherを経由する構成では、内部ホスト名を外部へ返さないように外部URLと転送設定をそろえます。時刻同期も重要で、IdP、Web Dispatcher、Fioriフロントエンドサーバーの時刻差が大きいと、アサーションの有効期間チェックで拒否されます。

03Fiori LaunchpadのSSO設定手順

設定は、設計情報を固定してから一つずつ検証します。変更前に現在のメタデータ、証明書の有効期限、プロファイルまたはWeb Dispatcher設定、対象ユーザーの識別子を安全な場所へ保存します。

1. 外部アクセスURLを確定する

利用者が入力するHTTPS URLを決め、DNS、ロードバランサー、Web Dispatcherの名前解決を確認します。ブラウザから到達するURLと、SAMLのACS URLに異なるホスト名が混在すると、リダイレクトループやアサーションの宛先不一致につながります。

2. IdPへサービスプロバイダーを登録する

Fiori側が提供するメタデータを使用し、IdPにサービスプロバイダーを登録します。署名要求の扱い、アサーションの暗号化要否、NameIDの形式、ユーザー属性のマッピングを組織の認証設計に合わせます。テスト用ユーザーは本番の管理者アカウントと分け、最小限の権限で確認します。

3. Fiori側へIdP情報を登録する

IdPのメタデータまたは署名証明書をFiori側へ登録します。証明書はファイル名だけで管理せず、発行者、フィンガープリント、有効期限、更新担当者を台帳に記録します。証明書更新では、旧証明書をすぐ削除せず、切り替え時間とロールバック方法を決めてから変更します。

4. ユーザー識別子を対応付ける

IdPが送るNameIDまたは属性値と、ABAPユーザーの識別子を一致させます。メールアドレスを使う場合は、大文字・小文字、ドメイン、別名、退職者アカウントの扱いを事前に確認します。対応付けが一致しないと、IdPで認証が成功してもFiori側でユーザーを特定できません。

5. Launchpadと業務アプリを確認する

テストユーザーでLaunchpadへ入り、タイル表示、アプリ起動、バックエンドデータ取得の順に確認します。タイルがない場合はロールとスペースを確認し、タイルはあるが起動できない場合はサービスの有効化、宛先、バックエンド権限を確認します。ユーザーやロールの設計は、SAPログインとロール設計の基本も参照できます。

認証方式全体の考え方を整理する場合は、SAPログインとSSOの概念でログオン、認証、認可の関係を確認してください。

04認証エラーの切り分け

エラー画面だけで判断せず、失敗した段階を特定します。次の順序で確認すると、IdP、ネットワーク、Fiori、バックエンドの担当範囲を分けやすくなります。

1. URL到達性：DNS解決、HTTPS接続、証明書の有効性、Web Dispatcherの応答を確認します。
2. リダイレクト：IdPのログイン画面へ遷移するか、戻り先URLが正しいかを確認します。
3. SAML検証：Issuer、受信者、ACS URL、署名証明書、有効期間を確認します。
4. ユーザー対応付け：NameIDまたは属性値がABAPユーザーと一致するかを確認します。
5. セッション：ブラウザの古いCookie、複数タブ、プロキシのCookie処理を確認します。
6. 権限：Launchpadのロール、カタログ、スペース、ページ、ODataサービス、バックエンドロールを確認します。

IdPのログで認証成功が確認でき、Fiori側でユーザー不明になる場合は、ユーザー識別子のマッピングを優先して確認します。Fiori側まで到達せずに502や504が返る場合は、Web Dispatcherの転送先、バックエンドのポート、名前解決、ファイアウォールを確認します。

05よくある症状と対応

ログイン後に再びログイン画面へ戻る

外部URL、ACS URL、Cookieのドメイン、HTTPS終端位置を確認します。Web Dispatcherの外側がHTTPSで内側がHTTPの場合、転送ヘッダーとセッションCookieのSecure属性が構成と合っている必要があります。ブラウザのプライベートウィンドウで再現し、古いCookieの影響を分離します。

ログインは成功するがタイルが表示されない

認証は成立しているため、対象ユーザーへ割り当てたロール、カタログ、スペース、ページを確認します。ロール変更後はセッションを再作成し、キャッシュの影響を切り分けます。ユーザー管理を整理する場合は、SAPユーザー管理とSU01の基本も関連します。

アプリ起動時に権限エラーになる

Launchpadの表示権限と、アプリケーションを実行するバックエンド権限を分けて確認します。ODataサービスの有効化、システムエイリアス、RFC接続、バックエンド側の業務ロールが対象ユーザーに割り当てられているかを確認します。

証明書更新後にSSOが失敗する

IdPとFiori側の双方で新しい証明書が登録済みか、署名検証に使われる証明書が一致しているかを確認します。更新作業には切り替え時刻、旧証明書の保持期間、テストユーザー、ロールバック手順を含めます。証明書の有効期限監視を定期運用に組み込み、期限直前の変更を避けます。

06運用時の確認項目

SSOは一度設定して終わりではありません。次の項目を定期的に点検します。

• IdPとFioriの証明書の有効期限
• SAMLメタデータの変更履歴
• Web DispatcherとFioriフロントエンドサーバーの時刻同期
• 外部URL、DNS、ロードバランサー、転送先ポート
• 退職者・異動者のIdPおよびABAPユーザー状態
• Launchpadのロール、カタログ、スペース、ページ
• バックエンドサービスと業務ロール
• 失敗ログイン、リダイレクトループ、502・504応答

障害対応では、発生時刻、利用者、アクセスURL、ブラウザ、IdPの結果、Fioriのログ、バックエンドのエラーを一つの記録にまとめます。SAMLアサーションには個人情報や認証情報が含まれる場合があるため、ログを共有する際は必要な項目だけを抽出し、保管期間とアクセス権を管理します。

07安全な変更手順

認証設定の変更は、利用者全体へ影響するため、テスト環境または限定ユーザーで実施します。作業前に、現在の設定、証明書、メタデータ、Web Dispatcher設定、ロール割り当てをバックアップします。変更後は、認証成功、ログアウト、再ログイン、Launchpad表示、主要アプリ起動、権限エラーの各項目を確認します。

証明書更新では、IdP側とFiori側の登録順序、旧証明書の有効期間、切り戻し条件を明記します。ユーザー識別子の変更では、少なくとも管理者用、一般利用者用、業務ロール別のテストアカウントで確認します。変更結果とログをチケットへ残すことで、次回の障害時に同じ切り分けを再利用できます。

08まとめ

SAP FioriのSSOは、IdPによる認証、Fiori側の信頼検証、ユーザー識別子の対応付け、Launchpadとバックエンドの権限という複数の層で成立します。設定では外部URL、ACS URL、証明書、NameID、時刻同期をそろえ、障害時は到達性、リダイレクト、SAML検証、ユーザー対応付け、権限の順に確認します。認証と認可を分けて記録すると、担当チーム間の引き継ぎと復旧判断が安定します。