SAPシングルサインオン（SSO）とは？SAML2とX.509証明書の基本・設定確認・障害対応

SAPのシングルサインオン（SSO）は、利用者が認証基盤で一度認証された後、SAPシステムへ個別のパスワードを繰り返し入力せずにログインできる仕組みです。実務では、認証基盤、SAP側の信頼設定、SAPユーザーとの対応付け、ロールによる権限付与を分けて確認すると、障害の切り分けが安定します。

01SAP SSOの基本構造

SSOでは、利用者、認証を担当するIdP（Identity Provider）、SAP側のサービス提供者（Service Provider）が連携します。利用者がSAP GUIやブラウザからログインを開始すると、認証基盤が本人確認を行い、その結果をSAP側へ渡します。SAPは受け取った情報を検証し、対応するユーザーとしてセッションを開始します。

重要なのは、SSOが担当するのは主に本人確認であり、SAP内で何を実行できるかは別の認可処理で決まる点です。ログインできてもトランザクションやアプリケーションを利用できない場合は、SSOではなくロールや権限の確認が必要です。権限設計の整理には、SAPのロール設計の基本も参照できます。

{{VISUAL:summary}}

02SAML2によるSAP認証

SAML2は、XML形式のアサーションを使って認証結果を連携する標準プロトコルです。IdPが発行するアサーションには、利用者を識別する情報、発行者、対象サービス、発行時刻、有効期限などが含まれます。SAP側は署名を検証し、信頼できるIdPから適切な宛先へ発行された情報だけを受け入れます。

設定時は、双方のメタデータ、エンティティID、ACS URL、署名証明書、有効期限、ユーザー識別子の対応を同じ設計書で管理します。特に、IdPが送信する識別子とSAPユーザーを結び付ける属性を先に確定すると、認証後にユーザーが見つからない問題を減らせます。

ブラウザの開発者ツールやSAMLトレースで、リクエストとレスポンスの宛先、Issuer、NameIDまたは利用属性、署名、時刻条件を確認できます。パスワードそのものはSAMLアサーションに含めず、ログやトレースの共有時も個人情報とトークンを適切に保護します。

03X.509証明書を使うSSO

X.509証明書を使う方式では、利用者または端末が保持する証明書と秘密鍵を用いて本人確認を行います。SAP側は証明書チェーン、発行者、サブジェクト、拡張属性、有効期限、失効状態などを確認し、証明書の情報をSAPユーザーへ対応付けます。

運用では、ルートCAと中間CAの信頼関係、証明書の配布先、秘密鍵の保護、更新時期を管理します。証明書が有効でも、SAP側で識別属性の対応付けが一致しなければログインは成立しません。ブラウザや端末の証明書選択、プロキシ、TLS終端装置も確認対象になります。

SAML2とX.509証明書は、本人確認に使う情報と連携経路が異なります。SAML2ではIdPのアサーション、X.509では証明書と秘密鍵を中心に調査し、どちらも最終的にはSAPユーザーとの対応付けと権限を個別に確認します。

{{VISUAL:body-1}}

04認証と権限を分けて確認する

SSO障害の初動では、次の順番で状態を分けます。

1. 認証基盤で利用者の本人確認が完了しているか確認する。
2. SAP側がSAML2アサーションまたは証明書を受信しているか確認する。
3. 受信した識別子が対象のSAPユーザーに対応しているか確認する。
4. SAPユーザーがロック、無効、期限切れになっていないか確認する。
5. ログイン後に必要なロールと権限が割り当てられているか確認する。

ログイン画面へ戻される場合は、信頼設定、リダイレクト先、署名、時刻、セッションを優先して調べます。ログイン後に権限エラーが表示される場合は、ロール設計と権限値を調べます。ユーザーの状態を確認する際は、SAPユーザータイプの整理が判断材料になります。

05SSO設定の実装手順

1. 利用方式と識別子を決める

対象のSAP製品、接続方式、利用者範囲、IdP、ユーザー識別子を確定します。識別子はメールアドレスやログオン名など、組織内で重複せず、変更時の運用を定義できる値を選びます。複数のSAPシステムを扱う場合は、システムごとのユーザー対応付けを一覧化します。

2. 信頼関係を交換する

SAML2ではメタデータと署名証明書を交換し、サービスプロバイダーとIdPの情報を双方に登録します。X.509ではCA証明書、証明書の用途、証明書チェーン、失効確認の方法を登録します。証明書の更新担当者と更新後の検証手順も同時に決めます。

3. SAPユーザーへ対応付ける

認証後に渡される識別子とSAPユーザーの値を一致させます。大文字・小文字、前後の空白、ドメイン表記、重複値を確認し、テスト用ユーザーで成功と失敗の両方を検証します。

4. 権限を付与する

SSO成功後に必要な業務処理を実行できるよう、ロールと権限を設計します。認証方式を変更しても、権限要件は別途維持します。権限オブジェクト単位の調査が必要な場合は、SAP権限オブジェクトの確認方法を使って対象処理を絞り込みます。

5. 段階的に切り替える

管理者、運用担当者、代表的な業務ユーザーの順にテストし、接続元、ブラウザ、SAP GUI、ネットワーク経路ごとの結果を記録します。従来のログイン経路を管理手順として安全に保持し、障害時の連絡先と復旧判断を明確にします。

06SSO障害の切り分け

認証基盤で失敗する場合

IdPのサインインログで、利用者の状態、条件付きアクセス、MFA、端末条件、アプリケーション割り当てを確認します。ここで認証が完了していなければ、SAP側の設定を変更しても改善しません。

SAP側でアサーションを拒否する場合

Issuer、Audience、ACS URL、署名証明書、有効期限、時刻差を確認します。証明書更新後に失敗した場合は、旧証明書から新証明書への切り替え順序と、双方のメタデータが一致しているかを確認します。

ユーザーが見つからない場合

アサーションまたは証明書から得た識別子を確認し、SAPユーザーの対応する属性と照合します。ユーザーのロックや有効期限、削除済み状態も確認します。パスワード失敗によるロックが疑われる場合は、SAPログイン失敗回数によるロックの確認も関連します。

ログイン後に処理できない場合

SSO自体が成功しているため、対象トランザクション、アプリケーション、組織値、権限オブジェクト、ロール割り当てを確認します。ユーザーの属性やグループをロールへ自動連携している場合は、連携値とSAP側のマッピングを照合します。

{{VISUAL:body-2}}

07証明書とメタデータの運用

証明書には有効期限があるため、期限切れの直前ではなく、検証期間を確保して更新します。更新作業では、対象システム、証明書の用途、現在の有効期限、新しい証明書、切り替え日時、切り戻し手順を記録します。

SAML2の署名証明書やX.509のCA証明書を更新した後は、管理者だけでなく代表的な業務ユーザーでもログインを検証します。SAP GUIとブラウザで経路が異なる場合は、それぞれを確認します。監視には認証失敗、証明書期限、メタデータ変更、ユーザー対応付けエラーを含めます。

08SSO導入時の確認チェックリスト

• IdPとSAPの担当範囲、連絡先、障害時の確認順を文書化する。
• SAML2のIssuer、Audience、ACS URL、署名証明書を台帳に登録する。
• X.509のCAチェーン、証明書用途、更新期限、秘密鍵の保管場所を管理する。
• SAPユーザーへ渡す識別子と、ユーザーのライフサイクルを定義する。
• 認証成功と権限不足を別のテストケースとして記録する。
• 証明書更新後、複数の接続方式と代表ユーザーで検証する。
• ログには個人情報や認証トークンを残しすぎず、保存期間とアクセス権を管理する。

SSOはパスワード入力を減らすだけの機能ではなく、認証基盤、SAPユーザー、ロール、証明書、監視を一つの運用として扱う仕組みです。問題が起きたときは、認証基盤、連携データ、ユーザー対応付け、権限の順に境界を切り分けると、変更範囲を小さく保てます。