SAML 2.0設定
SAMLプロトコルをサポートするIDプロバイダーでSAML 2.0を使用したシングルサインオンを構成します。このガイドは、準拠する任意のIdPに適用可能な一般的なSAMLセットアップをカバーします。
前提条件
- SAML 2.0準拠 IDプロバイダー (Okta、Azure AD、OneLogin、PingFederateなど)
- アプリケーションを作成および構成するためのIDプロバイダーへの管理者アクセス
- SecureCodingHub組織管理者アカウント
サービスプロバイダー詳細
これらの値は、IDプロバイダーでSecureCodingHubを構成するときに必要です:
| 設定 | 値 |
|---|---|
| SP Entity ID | https://api.limeplate.com |
| ACS URL (Assertion Consumer Service) | https://api.limeplate.com/api/sch/auth/sso/callback/saml |
| SPメタデータURL | https://api.limeplate.com/api/sch/auth/sso/metadata |
| Name ID形式 | urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress |
| バインディング | HTTP-POST |
ステップ1 — IDプロバイダーを構成
ステップ2 — SecureCodingHubでSAMLを構成
ステップ3 — テスト
属性マッピング
SecureCodingHubはSAMLアサーションから次の属性を読み取ります:
| SAML属性 | SecureCodingHubフィールド | 必須 |
|---|---|---|
NameID (email形式) | メール | はい |
givenName (…/claims/givenname) | 名前 (姓と連結されて単一の表示名になる第1部) | いいえ |
surname (…/claims/surname) | 名前 (プロビジョニング時にgivenNameと結合される第2部) | いいえ |
実環境でのSAMLレスポンスの読み方
SAMLが失敗した場合、診断への最速の道はブラウザの症状ではなく実際のSAMLレスポンスを検査することです。SAMLトレーサーブラウザ拡張機能をインストールし、失敗したログインを再現し、IdPがACS URLに送信するPOSTを見ます。3つのフィールドがほぼすべてを伝えます。Issuer要素は、IdPメタデータで公開されているentityIDと一致する必要があります。Conditions内にネストされたAudience要素は、SecureCodingHubで構成されたSP Entity IDと一致する必要があります。Subject NameIDは、指定した形式でのユーザーのメールアドレスである必要があります。
これらのフィールド以外に、IdPがサポートしている場合はInResponseTo識別子を確認し、レスポンスが署名されていること (ds:Signature要素が存在) を確認し、NotBeforeおよびNotOnOrAfterタイムスタンプが現在のクロックと一貫していることを検証します。IdPとSP間の重大なクロックスキューは、それ以外の点で有効なアサーションの静かな拒否を引き起こします。レスポンスが整形されているように見えるがアサーションがまだ拒否される場合、トレーサーからbase64エンコードされたSAMLResponse値をコピーし、オフラインでデコードします。SAML 2.0仕様に対して生のXMLを読むことは、欠落した属性または誤って構成されたステートメントを見つける最も信頼できる方法です。
ヘルプをIdPチームに依頼するかSPチームに依頼するかのタイミング
ほとんどのSAMLサポートチケットは、エラーがフェデレーションのどちら側に存在するかを知っていれば、1分以内にトリアージできます。経験則として、オーディエンスとissuerの不一致はSP側の問題です: SecureCodingHubの構成は、IdPが生成していない値を期待するか、IdPが署名しているのとは異なるSP entity IDに対して構成されていました。これらは、SecureCodingHub SSO設定またはIdPアプリケーション構成のSP Entity IDとACS URLを調整することで解決されます。最初にSecureCodingHub側に連絡してください。
クレームと属性マッピングの問題は通常IdP側です。ユーザーが名がなかったり、間違ったメールアドレスや予期しないロール割り当てでSecureCodingHubに着地する場合、IdPはSPが消費できない属性を発行しています。IdP管理者は、アプリケーション構成でクレームを追加または名前変更する必要があります。証明書と署名の失敗は分割されます: IdP証明書が期限切れまたはローテーションされた場合、それはIdP側の修正です。SecureCodingHubが以前有効な署名の信頼を停止した場合、SP側に保存されているメタデータまたは証明書が古くなっており、更新する必要があります。疑わしい場合は、SAMLトレーサーの出力をキャプチャし、両方のチームと共有してください。レスポンス自体が、どちらの側が次の動きを所有するかを示します。プロトコル選択ガイダンスについてはSSO概要を参照。
SAML 2.0: よくある質問
「フェデレーテッドSAML」とは実際に何を意味しますか？
フェデレーテッドSAMLは、ユーザーがIdPで一度認証し、そのアサーションがSPによって受け入れられるように、IDプロバイダー (IdP) とサービスプロバイダー (SP) の間で確立された信頼関係を指します。フェデレーションは署名されたXML契約です: 各側が他の側のメタデータと署名証明書を信頼します。IdPメタデータをアップロードし、IdPがSP entity IDを知ると、SecureCodingHubはフェデレーションの一部になります。
ログインを壊さずにSAML証明書をローテーションする方法は？
SAML証明書のローテーションは、短い重複ウィンドウで実行するのが最適です。IdPがメタデータで複数の署名証明書の公開をサポートする場合、古い証明書を廃止する前に新しい証明書を追加し、SecureCodingHubにIdPメタデータを再フェッチさせて、両方の証明書が切り替え中に信頼されるようにします。IdPが新しいキーで署名を開始したら、1日ログインを監視し、その後メタデータから古い証明書を削除します。最も一般的なプロダクションの停止は、金曜日に重複なしでローテーションすることです。
SAML vs OAuth vs OpenID Connect — どれを選ぶべきですか？
チームがSAML vs OAuth vs OpenID Connectを比較するとき、実用的な答えは運用上の適合に従うことです。SAML 2.0は成熟したXMLベースのフェデレーション標準で、ADFSやPingFederateのようなエンタープライズIdPで支配的です。OAuth 2.0だけは認可フレームワークで、認証ではありません。OpenID ConnectはOAuth 2.0の上にIDを階層化し、Azure ADとOktaのモダンデフォルトです。SAMLまたはOIDCのいずれかが、SecureCodingHubで同等のSSOセキュリティを提供します。
失敗をトラブルシューティングするためにSAMLレスポンスをデコードする方法は？
SAMLレスポンスをデコードするには、IdPがACS URLにポストするbase64エンコードされたSAMLResponseパラメータをキャプチャします — SAMLトレーサーブラウザ拡張機能が取得する最も簡単な方法です。値を生のXMLにbase64デコードし、Issuer、Audience、NameID、タイムスタンプを検査します。ほとんどの失敗は、これらの4つのフィールドをSecureCodingHub SSO設定およびIdPのアプリケーション構成に構成された値と比較すると解決されます。