アイデンティティ プロバイダーを使用して SAML シングル サインオンを設定する

現在、SAML シングル サインオンは、ID プロバイダーを管理している場所と同じ場所にあります。これを見つけるには、[セキュリティ] > [ID プロバイダー] の順に移動します。ID プロバイダーの詳細についてご確認ください。

Atlassian Access の SAML シングル サインオン

Atlassian Access をサブスクライブすると、SAML シングル サインオンを利用できます。Atlassian Access を開始する方法をご参照ください。

SAML シングル サインオンについて

セキュリティ アサーション マークアップ言語 (SAML) は、パーティ間、特にアイデンティティ プロバイダーとサービス プロバイダー間で認証データと認可データを交換するためのオープン標準です。

ユーザーは SAML SSO (シングル サインオン) によって、Atlassian Cloud 製品にログインする際に企業の ID プロバイダーを介して認証できます。ユーザーは SSO によって一度認証した後は、そのセッション中は複数の製品にアクセスする際に各製品の認証が不要になります。SSO は検証済みドメインのユーザー アカウントにのみ適用されます。

ユーザーが SAML シングル サインオンによってログインできる場合も、Atlassian 製品とサイトへのアクセス権を付与する必要があります。製品アクセス設定のアップデート方法ユーザーがサイトにアクセスする方法を確認ください。

サイトのユーザーを Google Workspace によって管理する場合は、Google Workspace が提供する SSO 機能を使用する必要があります。

認証ポリシーによる SAML シングル サインオン

SSO を SAML または Google Workspace によって設定する場合は、認証ポリシーによってユーザーのサブセットに SSO を適用する必要があります。認証設定とメンバーの編集方法に関する詳細をご確認ください。

はじめる前に

SAML シングル サインオンをセットアップする前に次のことを実行する必要があります。

組織から Atlassian Access をサブスクライブします。詳細については、「Atlassian Access のセキュリティ ポリシーと機能」をご参照ください。

自身が Atlassian 組織の管理者であることを確認します。「組織の管理」の詳細についてご確認ください

組織内で 1 つ以上のドメインを検証します。「ドメイン検証」の詳細についてご確認ください

組織に ID プロバイダー ディレクトリを追加します。ID プロバイダーを追加する方法の詳細についてご確認ください

認証済みドメインを ID プロバイダー ディレクトリにリンクします。ドメインをリンクする方法の詳細についてご確認ください

Atlassian 製品とご利用の ID プロバイダーが HTTPS プロトコルを使用して通信していて、設定された製品のベース URL が HTTPS の URL であることを確認します。

SAML シングル サインオンをセットアップする前に、次を実行することをお勧めします。

ID プロバイダー サーバーの時計が NTP と同期していることを確認します。SAML 認証リクエストは限られた回数のみ有効です。

SAML 構成をセットアップしてテストするためのダウンタイムを計画します。

SAML 構成をテストするための認証ポリシーを作成します。
ユーザーをテスト ポリシーに追加します。SAML をセットアップした後で、シングル サインオンをこのテスト ポリシーに対して有効にできます。

サポートされるアイデンティティ プロバイダー

SAML SSO のセットアップは、使用する ID プロバイダーによって異なります。アトラシアン サポート チームは、サポートされている ID プロバイダーのセットアップ手順をサポートできます。このセクションでは、サポートされている ID プロバイダーの SAML シングル サインオンを設定する方法について説明します。

利用できる SAML 属性

ID プロバイダーをセットアップする際には、次の SAML 属性を使用します。

手順説明

SAML 属性

ID プロバイダーへのマッピング

任意

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname

ユーザーの名

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname

ユーザーの姓

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name, または

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

変更されないユーザーの内部 ID。

ユーザーのメール アドレスをこの ID に使用しないでください。

必須

NameID

ユーザーのメール

アイデンティティ プロバイダーから Atlassian 組織への詳細のコピー

  1. admin.atlassian.com で、ご利用の組織から[セキュリティ] > [ID プロバイダー] の順に選択します。

  2. ID プロバイダー ディレクトリを選択します。

  3. [SAML シングル サインオンをセットアップ] を選択します。

  4. SAML の詳細を追加します。

  5. SAML 設定を保存

SAML の詳細

説明

アイデンティティ プロバイダー エンティティ ID

この値は、製品が認証リクエストを許可するアイデンティティ プロバイダーの URL です。

アイデンティティ プロバイダー SSO URL

この値はユーザーがログイン時にリダイレクトされる URL を定義します。

公開 x509 証明書

この値は、「-----BEGIN CERTIFICATE-----」で始まります。

この証明書には、受信したすべての SAML 認証リクエストがアイデンティティ プロバイダーで発行されていることを検証するために使用する公開鍵が含まれています。

次の URL を Atlassian 組織から ID プロバイダーにコピーする

  • サービス プロバイダーのエンティティ URL

  • サービス プロバイダーのアサーション コンシューマー サービス URL

  1. URL をコピーする際に [保存] を ID プロバイダーで選択します。

他のアイデンティティ プロバイダー向けの SAML シングル サインオンを設定する

オンプレミスのアイデンティティ プロバイダーを使用する場合、ユーザーは内部ネットワークまたは VPN 接続からアイデンティティ プロバイダーにアクセス可能な場合にのみ認証することができます。

認証ポリシー無しの SAML シングル サインオン構成をテストする

認証ポリシーを表示できない場合は組織にアクセスするために使用できる一時的な Atlassian テスト アカウントを作成します。この組織で検証されていないドメインの一時的なアカウントには、メール アドレスを使用します。これによって、ログイン時にアカウントが SAML シングル サインオンにリダイレクトされなくなります。

[設定を保存] を選択すると、SAML が Atlassian 組織に適用されます。ユーザーはログアウトされないため、次のステップに従って SAML 構成をテストできます。

  1. ブラウザで新しいシークレット ウィンドウを開きます。

  2. 検証済みドメインのいずれかのメール アドレスを使用してログインします。

サインインしていることを確認します。ログイン エラーが発生した場合は「SAML シングル サインオンのトラブルシューティング」に移動して構成を調整し、シークレット ウィンドウで再びテストします。

正常にログインできない場合は、構成を削除してユーザーが Atlassian 製品にアクセスできるようにします。

認証ポリシーで SAML シングル サインオンをテストする

認証ポリシーによって、組織内のユーザー セットごとに異なるセキュリティ レベルを設定する柔軟性を得られます。また、認証ポリシーによって、会社全体にロールアウトする前にユーザーのサブセットでさまざまなシングル サインオン設定をテストできるため、リスクを軽減できます。

以下を実行してください。

  • 組織全体でロールアウトする前に、比較的小さいユーザー グループでシングル サインオン (SSO) または 2 段階認証をテストして、正しく設定されていることを確認します。

  • 管理アカウントごとに異なるポリシーを設定することで、ログインして SSO ポリシーをトラブルシューティングするか、プロバイダー統合を特定できます。

認証の設定をテストするには、SAML シングル サインオンを設定して適用する必要があります。次のセクションではその手順について説明します。

認証ポリシーを使用する SAML シングル サインオンの設定と適用

SAML を設定して保存し、認証ポリシーで SAML シングル サインオンを適用する必要があります。

認証ポリシーからの SAML シングル サインオンの設定:

  1. admin.atlassian.com で [認証ポリシー] に移動します。

  2. 設定するポリシーの [編集] を選択します。

  3. [SAML シングル サインオンを使用] を選択すると、認証ポリシーから SAML SSO 構成ページにリダイレクトされます。

  4. SAML SSO の設定を完了すると、ポリシーで SSO を適用する必要があります。

シングル サインオンを適用するには、次を実行します。

  1. admin.atlassian.com で [認証ポリシー] に移動します。

  2. 強制するポリシーの [編集] を選択します。

  3. [Enforce single sign-on (シングル サインオンの強制)] を選択します。

SAML でのジャストインタイム プロビジョニング

SAML ジャスト イン タイムによってユーザーをプロビジョニングする場合は、次の 2 ステップを完了する必要があります

  1. ドメインをアイデンティティ プロバイダー ディレクトリにリンクする

  2. SAML シングル サインオンを既定の認証ポリシーで強制する

ステップを完了した後にユーザーが SAML で初めてログインすると、そのユーザーの Atlassian アカウントが自動で作成されて ID プロバイダー ディレクトリに SAML を介してプロビジョニングされます。
ID プロバイダー ディレクトリの詳細についてご確認ください。

SAML ジャスト イン タイムによってユーザーをプロビジョニングする場合は、1 つ以上のドメインをご利用の ID プロバイダー ディレクトリにリンクする必要があります。ドメインをリンクすると、ドメインのユーザー アカウントがこのディレクトリに自動で関連付けられます。

ドメインをディレクトリにリンクするには、次の手順に従います。

  1. admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。

  2. [セキュリティ] > [ID プロバイダー] の順に選択します。

  3. 表示するディレクトリを選択します。

  4. [ドメインを表示] を選択して、ドメインをディレクトリにリンクします。

  5. [ドメインをリンク] を選択します。

  6. このディレクトリにリンクする 1 つ以上のドメインを選択します。

リンクされたドメインの詳細についてご確認ください。

認証ポリシーを使用したジャストインタイム プロビジョニング

すべての組織には、そのユーザーに対するログイン設定を含む既定の認証ポリシーがあります。新しいアカウントをプロビジョニングすると、新しいユーザーが既定のポリシーに追加されます。

  • ジャストインタイム プロビジョニングで認証ポリシーを活用するには、デフォルト ポリシーに SAML シングル サインオンを適用する必要があります。

  • SAML シングル サインオンを既定のポリシーに適用しない場合は、ユーザーを SCIM でプロビジョニングできます。ID プロバイダーのメールを変更すると、Atlassian アカウントが自動でアップデートされます。

認証ポリシーの詳細を確認

ジャストインタイム プロビジョニングなしでメールの更新をトラブルシューティングする

  1. ID プロバイダーのメールを変更する場合は、Atlassian アカウントのメールを手動でアップデートする必要があります。

  2. 最初の Atlassian メールをアップデートしない場合は、2 つ目のメール アカウントがユーザーのログイン時に作成されます。このアカウントでは、サイトや製品にアクセスできません。これを修正するには、最初のメール アカウントをアップデートまたは削除します。アカウントのメールをアップデートする

自動ユーザー プロビジョニングおよびプロビジョニング解除をセットアップする

自動ユーザー プロビジョニングによって、アイデンティティ プロバイダと Atlassian Cloud 製品間の直接同期を実現できます。つまり、社員の入社時や、新しい部門への異動時などに、手動でユーザー アカウントを作成する必要がなくなります。

プロビジョニング解除を自動化すると、退職した社員のアクセス権を削除して情報漏えいのリスクを軽減できます。社員が会社やグループを退職した際は、該当する社員を自動で削除します。これによって請求を管理できます。ユーザー プロビジョニングのオプションを次に示します。

  • SCIM によるプロビジョニング - Atlassian Access をサブスクライブすると、Atlassian Cloud 製品をアイデンティティ プロバイダと直接同期し、ユーザーやグループの自動プロビジョニングおよびプロビジョニング解除を有効化できます。

  • Google Workspace によるプロビジョニング - Atlassian Cloud ツールを Google Workspace と同期してプロビジョニングできます。ただし、グループの分類はサイトに反映されません。

SAML でのユーザーの無効化

ユーザーによる REST API 経由での組織データの取得を防止するには、組織とアイデンティティ プロバイダーの両方でユーザーを無効化します。

組織でユーザー プロビジョニングもセットアップ済みの場合、アイデンティティ プロバイダー側でのユーザーの無効化のみが必要です。


2 段階認証およびパスワード ポリシーを備えた SAML シングル サインオン

組織で Atlassian パスワード ポリシーと 2 段階認証が設定されている場合に SAML シングル サインオンを設定すると、ユーザーはそれらの対象外になります。つまり、パスワード要件と 2 段階認証はログイン プロセスで基本的に「スキップ」されます。 

代わりにアイデンティティ プロバイダーが提供する同等の仕組みを使用することをお勧めします。

SAML シングル サインオンの削除

SAML シングル サインオン構成を削除する前に、ユーザーがログインするためのパスワードを持っていることをご確認ください。

  • SAML シングル サインオンを有効にする前は、ユーザーは自分の Atlassian アカウント用に保持しているパスワードを使用できます。

  • SAML シングル サインオンを有効にした後に参加したユーザーは、次回ログイン時に Atlassian アカウントのパスワードをリセットする必要があります。

SAML シングル サインオンを削除するには、次の手順に従います。

  1. admin.atlassian.com に移動します。複数の組織がある場合は、組織を選択します。

  2. [セキュリティ] > [ID プロバイダー] の順に選択します。

  3. 表示するディレクトリを選択します。

  4. [SAML 構成を表示] を選択します。

  5. [構成を削除] を選択します。

また、SAML 構成を ID プロバイダーから削除することをお勧めします。

SAML シングル サインオンを削除しても、Atlassian Access のサブスクリプションは引き続き残っています。登録解除する場合は Atlassian Access を登録解除に移動します。


SAML 設定のトラブルシューティング

エラーが ID プロバイダーで発生する場合は、アトラシアン サポートではなく ID プロバイダーが提供するサポートとツールをご利用ください。

SAML シングル サインオンのトラブルシューティング (認証ポリシー無し)

  1. SAML を設定する前に、未検証のドメインからのメールで Atlassian ユーザー アカウントを作成します。

  2. そのユーザーを組織管理者にします。

  3. SAML で認証する必要がないため、このアカウントでログインしてトラブルシューティングを行います。

  4. 組織の SAML シングル サインオン ページに移動して、すべてのユーザーの SAML シングル サインオンを修正するか無効化します。

問題が解消されない場合は、SAML 設定を削除して Atlassian アカウントのパスワード認証に戻します。

SAML 設定を削除すると、パスワード ポリシー画面ですべてのユーザーのパスワードを無効化することができます。これによって、Atlassian アカウント パスワードのパスワード リセット プロセスを利用するようにユーザーに要求できます。

SAML シングル サインオンのトラブルシューティング (認証ポリシー付き)

  1. SAML を設定する前に、未検証のドメインからのメールで Atlassian ユーザー アカウントを作成します。

  2. そのユーザーを組織管理者にします。

  3. SAML シングル サインオンを適用せずに、認証ポリシーにユーザーを追加します。

  4. SAML で認証する必要がないため、このアカウントでログインしてトラブルシューティングを行います。

  5. ID プロバイダー ディレクトリの SAML シングル サインオンに移動して、すべてのユーザーに対して無効にします。

SAML 設定を削除する場合は、認証ポリシーで SAML シングル サインオンが使用されていないことを確認します。

ユーザーのロックアウトを防ぐには、SAML シングル サインオンを適用しないポリシーにユーザーを移動する必要があります。

公開 x509 証明書エラーをトラブルシューティングする

証明書エラーが発生した場合は、次のいずれかの手順を試してエラーを解決してください。

  1. 証明書をもう一度コピーして貼り付けます。その際に次を含めてください。

    1. 証明書のすべての行。

    2. “-----BEGIN CERTIFICATE-----" から “-----END CERTIFICATE-----" まで。

  2. ID プロバイダーから提供された証明書が不完全である可能性があります。証明書をダウンロードして [公開 x509 証明書] フィールドにコピー & ペーストします。

その他のエラーをトラブルシューティングする

サポート チケットを送信する際に、SAML Tracer Firefox アアプリドオンから検索できる SAMLRequest と SAMLResponsアプリアプリe の各ペイロードを添付してください。課題の潜在的な原因をより迅速に特定できるようになります。

エラー

発生する可能性がある問題

"The authenticated email address we expected was 'xxx,' but we received 'xxx.’ (必要な認証済みメール アドレスは 'xxx,' でしたが 'xxx.’ を受信しました)Please ensure they match exactly, including case sensitivity (大小文字を含めて正確に一致するようにご確認ください).Contact your admin to change your email to match (メール アドレスが一致するように、管理者にお問い合わせください)."

ユーザーが Atlassian アカウントとは異なるメール アドレスで IdP にログインしようとしました。ユーザーが正しいメール アドレスでログインしていることをご確認ください。メール アドレスも大小文字が区別されます。

"The response was received at xxx instead of xxx"

IdP SAML 設定のアサーション コンシューマー サービス URL が正しくない可能性があります。正しい URL を使用していることを確認し、再度実行してください。

  • "We were expecting an email address as the Name Id, but we got xxx (Name Id のメール アドレスが必要でしたが xxx でした).Please ask your administrator to check that Name Id is mapped to email address (Name Id がメール アドレスにマッピングされるように、管理者にお問い合わせください)."

  • "We were expecting an email address as the Name Id, but didn't get one (Name Id のメール アドレスが必要でしたが取得できませんでした).Please ask your administrator to check that Name Id is mapped to email address (Name Id がメール アドレスにマッピングされるように、管理者にお問い合わせください)."

  • "We were expecting a user ID, but didn't get one (ユーザー ID が見つかりませんでした).Please ask your admin to check that user ID is populated in the response (管理者に、ユーザー ID がレスポンスで生成されているかどうかをお問い合わせください).See the configuration and troubleshooting guide (構成およびトラブルシューティング ガイドをご参照ください)."

  • "Unsupported SAML Version."

  • "Missing ID attribute on SAML Response."

  • "SAML Response must contain 1 Assertion."

  • "Invalid SAML Response. Not match the saml-schema-protocol-2.0.XSD"

  • "Invalid decrypted SAML Response. Not match the saml-schema-protocol-2.0.XSD"

  • "Signature validation failed. SAML Response rejected"

  • "No Signature found. SAML Response rejected"

  • "The Assertion of the Response is not signed, and the SP requires it (レスポンスのアサーションが登録されていないため、SP が必要です)."

  • "The attributes have expired, based on the SessionNotOnOrAfter of the AttributeStatement of this Response (このレスポンスの AttributeStatement の SessionNotOnOrAfter に基づいて、属性の期限が切れています)."

  • "There is an EncryptedAttribute in the Response, and this SP does not support them (EncryptedAttribute がレスポンスにあります、この SP ではサポート対象外です)."

  • "Timing issues (please check your clock settings)"

  • "The Response has an InResponseTo attribute: xxx while no InResponseTo was expected"

  • "The InResponseTo of the Response: xxx does not match the ID of the AuthNRequest sent by the SP: xxx. (レスポンスの InResponseTo: xxx は、SP: xxx. によって送信された AuthNRequest の ID と一致しません)"

サポートされていない IdP を使用している可能性があります。以下の点を確認して IdP 設定を確認してください。

  1. ID プロバイダーはメールを NameId として返せます。

  2. ユーザー Id は一意かつ不変であり、upn または name SAML 属性にマッピングされます。

  3. SAML レスポンスは署名されており、暗号化されていません。

  4. アイデンティティ プロバイダーの時間は NTP と同期されています。




内部のユーザー ID は不変でなければならないことにご注意ください。この ID をユーザーのメール アドレスにしないでください。

必要に応じて、upn または name 属性を一意で不変の値に変更できます。その Atlassian アカウント用の SAML ID は、ユーザーの次回ログイン時に新しい値にアップデートされます。










"We couldn't log you in, but trying again will probably work (ログインできませんでしたが、再試行するとできる可能性があります)."

ログインプロセス中にそのユーザーの SAML 設定が無効化されました。SAML 設定を確認して再度実行してください。

"xxx is not a valid audience for this Response (xxx はこのレスポンスの有効な対象ではありません)."

アイデンティティ プロバイダーの SAML 設定にあるサービス プロバイダー エンティティ ID が正しくない可能性があります。正しいエンティティ ID を使用していることを確認し、再度実行してください。

"Your email address has changed at your Identity Provider (ご利用のメール アドレスは ID プロバイダーで変更されています).Ask your admin to make a corresponding change on your Atlassian products (管理者にお問い合わせのうえ、対応する変更を Atlassian 製品に加えてください)."

SAML ベータによる既知の問題:ユーザー管理から管理アカウントのメール アドレスを変更できる機能を今後提供予定です。

Atlassian ブランドのない通常のエラー画面

IdP とのネットワーク接続に問題がある可能性があります。ページを更新して問題が解決されるか確認します。

IdP のエラー画面

ID プロバイダー構成に課題がある可能性があります。たとえば、ユーザーが IdP から Atlassian 製品にアクセスできない場合などがあります。チケットを IdP で登録して、問題を修正してください。

  • 予期しないアイデンティティ プロバイダー エンティティ ID が到達しました。管理者に連絡し、Atlassian の SAML の設定を確認してください。xxx ですが xxx を予期していました。

  • "Invalid issuer in the Assertion/Response"

SAML 設定の ID プロバイダー エンティティ ID が正しくない可能性があります。正しいエンティティ ID を使用していることを確認し、再度実行してください。

よくあるご質問

検証できないドメインに SAML シングル サインオンを適用することはできますか?

いいえ。製品とリソースの安全性を維持するため、所有している検証可能なドメインでのみ SAML シングル サインオンを使用できます。

ユーザーのフル ネームを変更する方法

ユーザーの氏名は、を ID プロバイダーのシステムで更新することで更新できます。更新された名前は、ユーザーの次回ログイン時に組織に同期されます。

REST API による認証の仕組みを教えてください。

Atlassian Cloud 製品のスクリプトとサービスによる基本認証では、パスワードではなく API トークンを代用することをお勧めします。SAML を適用しても、API トークンとスクリプトは引き続き機能します。API トークンの使用に関する詳細についてご覧ください。



その他のヘルプ