Claude Duo SSO設定 — SAML IdP連携とMFA専業ゆえの注意点
ClaudeでDuoをSAML IdPとして連携する設定手順です。MFA専業のDuoは単体のIdPではなく、背後の認証基盤と組み合わせる点が要注意です。
ClaudeでDuoをSAML IdP(IDプロバイダー)として連携するには、Duo管理パネルでのCloud Application作成と、WorkOS(Anthropicの認証基盤プロバイダー)側での接続設定を両方進めます。Duoは単体で完結するIdPではなく、背後に別のIdPを必要とする点が、OktaやEntra IDを直接使う設定と最も異なる注意点です。
Duoは単体のIdPではなく認証を中継する仕組み
Duoは多要素認証(MFA)専業のサービスで、ユーザーの本来の身元情報(メールアドレスや氏名などの属性)を自前で持つディレクトリではありません。DuoをClaudeのSAML IdPにする場合、認証は次の順で流れます。
Claude/Console → WorkOS → Duo → 実際のSSO IdP(Okta・Entra ID・Google Workspaceなど)→ Duo → WorkOS → Claude/Console
つまりDuoは「WorkOSと、背後の実IdPの間に立つ中継点」であり、Duo単独ではSSO接続は完結しません。すでにDuoを自社のMFA基盤として使っていて、その配下に別のIdPでSSO Authentication Sourceを設定済みであることが前提になります。まだこの中継構成がない場合は、まず自社のIdP側でDuoとのSSO連携を構築してください(IdPごとに設定方法が異なるため、Duoが提供するIdP別ドキュメントを参照します)。
ドメイン検証やSSO必須化など、IdPを問わない共通の設定フローはClaudeのSSO設定手順で扱っています。本記事はDuo固有のSAML接続手順と、MFA専業であることに起因する注意点に絞って解説します。
導入前に確認しておくこと
- Claude側の権限: TeamプランまたはEnterpriseプランはOwnerまたはPrimary Owner、Claude ConsoleはAdmin権限が必要です
- ドメイン検証の完了:
claude.ai/admin-settings/organization(Consoleはplatform.claude.com/settings/identity)でメールドメインの検証を終えていること。未検証の場合は前述のClaudeのSSO設定手順でドメイン検証を先に完了させます - Duo Admin Panelへのアクセス: Applicationsの作成権限を持つDuo管理者が必要です
- 背後のIdPとの連携: DuoとOkta・Entra ID・Google Workspaceなど実IdPとの間で、SSO Authentication Sourceがすでに構成されていること。この部分はDuo側のドキュメントに従って設定します(Okta経由の構成例はClaude Okta SSO設定が参考になります)
いずれかが未整備の場合、Duo側のCloud Application作成に進んでもSAMLレスポンスが正しく返らず、接続がActiveになりません。
Duoの管理パネルでCloud Applicationを作成する
- Duo Admin Panelにログインし、左サイドバーの「Applications」を開きます
- 「Protect an Application」をクリックし、一覧から「Generic SAML Service Provider」(Protection typeが「2FA with SSO hosted by Duo(Single Sign-On)」の項目)を探します
- 該当行の「Protect」をクリックし、Generic SAML Service Providerの設定画面を開きます
- この画面でMetadata URLを控えます。次のWorkOS側の手順で、このURLをDuo SAML接続に登録します
WorkOSでDuo SAML接続を作成し、値を相互に登録する
- WorkOS Dashboardで対象のOrganizationを開き、「Manually Configure Connection」から「Duo SAML」をIdPとして選択し、接続に分かりやすい名前を付けて「Create Connection」をクリックします
- 作成した接続の詳細ページで、ACS URLとSP Entity ID(いずれもWorkOSが発行する値)を控えます
- 同じページのMetadataフィールドに、DuoのCloud Application設定画面で控えたMetadata URLを貼り付けます。この時点ではまだ接続はActiveになりません
- Duo側のGeneric Service Provider設定画面に戻り、Service Providerセクションの「Assertion Consumer Service(ACS)URL」にWorkOSのACS URLを、「Entity ID」にWorkOSのSP Entity IDを貼り付けます
- Single Logout URL・Service Provider Login URL・Default Relay Stateの各フィールドは空欄のままで構いません
SAML属性のマッピングとNameID・署名設定
Duoの設定画面を下にスクロールし、SAML Responseセクションで以下を設定します。
- NameID format: ユーザーの一意な識別子として使いたい属性(メールアドレスを使う場合は
<Email Address>など)に合わせます - Signature algorithm:
SHA256を選択します - Signing options:
Sign responseとSign assertionの両方にチェックを入れます - Map Attributes: WorkOSが必須とする4つの属性、
idemailfirstNamelastNameをすべてマッピングします。Duo側で該当する事前定義済みの値(<Email Address>など)を選ぶと自動的に対応する値が割り当てられます
lastNameに相当する値をユーザーが持たない場合でも、Display Nameなど別の値を代わりにマッピングしてください。4つの属性のいずれかが欠けると、WorkOSはSAMLレスポンスを拒否します。
役割ベースのアクセス制御を使う場合は、任意でRole Assignmentも設定できます。「Role Attributes」セクションでAttribute nameをgroupsとし、Claude/Console側のロール名とDuoのグループを対応付けます。その後WorkOS Dashboard側のSSO接続ページで、IdP Group IDを参照するSSOグループを作成し、ロールを割り当てます。
設定を終えたら、Duoの設定画面を最後までスクロールして「Save」をクリックします。
接続を確認してClaudeでSSOを有効にする
WorkOS Dashboardに戻り、1〜2分待つと接続名の横に緑色のバッジが表示され、ステータスがActiveに変わります。Activeを確認したら、Claudeの組織設定(claude.ai/admin-settings/organization。Consoleはplatform.claude.com/settings/identity)のAuthenticationセクションから「Setup SSO」または「Manage SSO」を開き、「Test Single Sign-on」でエラーが出ないことを確認します。
テストが通ったら、同じ設定画面で「Require SSO for Claude」または「Require SSO for Console」を有効にするかどうかを決めます。有効にすると、ユーザーはメールログインではなく「Continue with SSO」経由でのログインが必須になります。
証明書の更新とSSOの無効化
Duo(または背後のIdP)が発行するX.509署名証明書が失効・ローテーションされた場合は、Claude/Console側の設定を更新する必要があります。組織設定のAuthenticationセクションで「Manage SSO」を開き、Metadata configurationの「Edit」から証明書情報を更新して保存し、「Test sign-in」で動作を確認します。
Require SSOが有効な状態で証明書が失効すると、ログイン手段がすべてSSO経由になっているため、組織内の誰もサインインできなくなります。その場合はOwnerまたはPrimary OwnerのメールアドレスからSupportに連絡し、アクセス回復の支援を受けます。証明書の有効期限はDuoまたは背後のIdP側で事前に把握し、余裕を持ってローテーションしておくと回避できます。
SSOを一時的に任意に戻したい場合は「Require SSO」のトグルをオフにします。完全に接続を解除する場合は「Manage SSO」から「Reset connection」を選びます。これによって全ユーザーのセッションが終了し、次回はメールのログインリンクでのサインインが必要になります。
MFA専業のDuoならではのつまずき
- 背後のIdPとの連携が未構成のまま進める: DuoとOkta・Entra IDなど実IdPとのSSO Authentication Sourceが無いと、Cloud Applicationを作ってもSAMLレスポンスが正しく返らず接続がActiveになりません。この部分の設定手順はDuo側のドキュメントに従う必要があり、WorkOSやClaudeのドキュメントではカバーされません
- 属性マッピングの一部を省略する:
idemailfirstNamelastNameのいずれかを未マッピングのまま保存すると、接続はActiveに見えても実際のログイン時にWorkOSがレスポンスを拒否します - Console組織でのIdP-initiatedログインを想定する: TeamまたはEnterpriseプランの組織とSSO設定を共有しているConsole組織では、IdP側から起動するログインに対応していません。ワークアラウンドとして、IdP側に
platform.claude.com/login?sso=trueへのブックマークを作成し、SP-initiatedログインへ誘導する方法があります - 証明書の期限管理をDuo側だけで済ませる: 中継構成では、Duo-WorkOS間とDuo-実IdP間の両方に証明書が絡む場合があります。ログイン障害が起きたときは、どちらの区間の証明書か切り分けてから対応します
Duo経由と直接IdP接続、どちらを選ぶか
すでにDuoをMFA基盤として全社導入している組織以外は、OktaやEntra IDなど実IdPに直接SAML接続するほうが構成要素が少なく済みます。
| 観点 | Duo経由でSSO接続 | 実IdPに直接接続 |
|---|---|---|
| 関与するシステム | Duo経由でSSO接続Duo・WorkOS・背後の実IdPの3者 | 実IdPに直接接続実IdPとWorkOSの2者 |
| MFAの扱い | Duo経由でSSO接続Duoに一元化できる | 実IdPに直接接続各IdP自体のMFA機能に依存 |
| 障害点 | Duo経由でSSO接続Duo-実IdP間とDuo-WorkOS間の2区間 | 実IdPに直接接続IdP-WorkOS間の1区間 |
| 向くケース | Duo経由でSSO接続既存のMFA運用をDuoに統一済みの組織 | 実IdPに直接接続IdPのSSO機能だけで完結させたい組織 |
各IdPの選び方自体はClaudeのSSO設定、IdPはOkta・Google Workspace・Entra IDのどれかで比較しています。Duoから別のIdPへ切り替える場合の手順はClaude IdP切り替え、SSOリセットの7手順にまとめています。
まとめ
Duo経由のSAML連携は、Duo管理パネルでのCloud Application作成とWorkOSでの接続作成という2つの画面を往復しながら、ACS URL・SP Entity ID・Metadata URLを相互に登録する作業です。属性マッピングでid email firstName lastNameの4点を欠かさないことと、Duoの背後にある実IdPとの連携がすでに構成済みであることが、設定完了までの最大のポイントになります。ドメイン検証やSSO必須化といった共通フローは冒頭で挙げたガイド側で確認し、本記事の手順と組み合わせて進めてください。