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

最近、認証設定の変更に気づいた場合
3 月 15 日の週より、SAML シングル サインオンやその他の設定を新しい認証ポリシーに移行し始めました。変更の詳細

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

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

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

ユーザーが SAML シングル サインオンによってログインできる場合も、アトラシアン製品へのアクセス権を引き続き付与する必要があります。この方法については「製品アクセス設定の更新」をご参照ください。

G Suite でサイトのユーザーを管理する場合は、G Suite が提供する SSO 機能を使用する必要があります。 

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

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

認証ポリシーによってセキュリティ設定を適用する場合は、SAML または G Suite SSO を認証ポリシー内で強制する必要があります。その方法については認証設定とメンバーの編集をご参照ください。

はじめる前に

ユーザーの Atlassian アカウントに SAML シングルサインオンを適用する前に、いくつかの手順を完了しておく必要があります。

  1. 1 つ以上のドメインを検証する – 組織のドメインの検証についてご確認ください

  2. Atlassian Access をサブスクライブする。

また、次の点を確認しておくことをおすすめします。 

  1. Atlassian 製品とご利用のアイデンティティ プロバイダーの両方が相互の通信に HTTPS プロトコルを使用すること。また、設定された製品のベース URL が HTTPS のものであること。

  2. SAML 認証リクエストは限られた期間のみ有効であるため、アイデンティティ プロバイダー サーバーの時間が NTP を使用して同期されていること。SaaS アイデンティティ プロバイダーを使用している場合は、時間がすでに同期されているはずです。

  3. SAML シングル サインオンを設定する前に、SAML 構成に誤りがあった場合に備えて組織へのアクセスを保持するための Atlassian アカウントを作成します。このアカウントは、以下を満たす必要があります。

    • 組織について検証したドメインのメール アドレスを使用していないこと。これによって、ログイン時にアカウントが SAML シングル サインオンにリダイレクトされなくなります。

    • サイト管理者アクセス権と組織管理者アクセス権の両方が付与されていること。

    このアカウントは一時的なものと考えてください。SAML シングル サインオンがユーザーの期待通りに動作していることを確認したら、管理者アクセス権を削除できます。

SAML シングル サインオンのセットアップ

このセクションでは、SAML シングル サインオンをセットアップする方法について説明します。

  • 管理対象ユーザーに対して SAML シングル サインオンをセットアップするには、Atlassian Access をサブスクライブ済みである必要があります。この方法の詳細については「Atlassian Access について理解する」をご参照ください。

  • SAML シングル サインオンの構成中は、ユーザーは Atlassian クラウド製品にログインできません。SAML への移行日時のスケジューリングやユーザーへの事前通知を検討してください。

SAML シングル サインオンの設定を開始する前に、SAML シングル サインオンに関するこのビデオをご確認ください。 

ご利用のアイデンティティ プロバイダーが以下に記載されている場合は、アイデンティティ プロバイダーの指示に従って SAML シングル サインオンをセットアップします。

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

ご利用のアイデンティティ プロバイダーが表にない場合も、以下の手順で SAML シングル サインオンをセットアップできます。

1. ID プロバイダーへの Atlassian 製品の追加

この手順では、SAML シングル サインオンを使用する Atlassian 製品をアイデンティティ プロバイダーに設定します。

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

アイデンティティ プロバイダーが NameId 属性を使用してメール アドレス値を送信できることを確認します。アトラシアン製品を追加したら、以下の SAML 属性マッピングをアイデンティティ プロバイダーに追加します。

SAML 属性名

アイデンティティ プロバイダーにマッピングする項目

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 に使用しないでください。

IdP-initiated SAML の場合、組織の URL をデフォルトのリレー状態として入力します。https:// を組織の URL の一部として含めます。

2. ID プロバイダーから Atlassian 組織への詳細のコピー

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

  2. [セキュリティ] > [SAML シングル サインオン] の順に選択します。

  3. [SAML 設定の追加] をクリックします。

  4. ID プロバイダーの詳細を次の表のフィールドにコピーします。

  5. 構成の保存をクリックします。

フィールド

説明

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

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

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

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

公開 x509 証明書

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

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

3. Atlassian 組織から ID プロバイダーへの詳細のコピー

Atlassian 組織の「SAML シングル サインオン」ページにアイデンティティ プロバイダーの詳細を追加すると、新しいフィールドと値が表示されます。これらの値をアイデンティティ プロバイダーにコピーします。 

すべてのコピーが終わったら、アイデンティティ プロバイダーで保存をクリックします。

4. Atlassian 組織の SAML シングル サインオンのテスト

Atlassian 組織で保存をクリックすると、SAML 設定が適用されます。ユーザーはログアウトされないため、以下の手順を使用して SAML 設定を調整しながらテストします。

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

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

サインインできてアクセス権限が期待した内容と一致することを確認します。

ログイン エラーが発生した場合は、以下の「SAML シングル サインオンのトラブルシューティング」セクションを参考に設定を調整して、再度シークレット ウィンドウでテストします。

正常にログインできない場合、設定を削除して、ユーザーが Atlassian 製品にアクセスできることを確認します。

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

2021 年 3 月中旬から 4 月末まで、認証ポリシーの適用を開始します。SAML シングル サインオンのテスト方法は変更されます。認証ポリシーが適用されたら、それを使用して SAML シングル サインオンをテストします。その実施方法については、このセクションをお読みください。

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

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

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

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

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

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

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

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

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

  2. [セキュリティ] > [認証ポリシー] の順に選択します。

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

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

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

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

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

  2. [セキュリティ] > [認証ポリシー] の順に選択します。

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

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

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

セルフ サインアップが有効化されている場合は、新規ユーザーに Atlassian アカウントを手動で作成する必要はありません。そのユーザーが SAML によって最初にログインした際に、Atlassian アカウントが自動で作成されます。

新規ユーザーが Jira、Confluence、または Bitbucket に初めてアクセスした際には、次のようになります。

  1. ユーザーは自身のメール アドレスを入力します。

  2. ご利用のアイデンティティ プロバイダーのログイン画面が表示され、ユーザーは自身の資格情報を入力して認証します。

  3. 対象のメール アドレスに、Atlassian アカウントのメール アドレスを確認するためのメールが送信されます。

  4. ユーザーはメール内の確認リンクをクリックしてログインし、アクセスしようとしていたサイト (Jira、Confluence、または Bitbucket) が開きます。

start.atlassian.com では、自身がアクセス権を持っている複数のクラウド サイトを 1 か所で確認できます。

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

すべての組織には、そのユーザーに対するログイン設定を含むデフォルト認証ポリシーがあります。新しいアカウントを提供する場合、デフォルト ポリシーに新しいユーザーを追加します。

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

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

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

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

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

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

SAML でのユーザーの無効化

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

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

異なるユーザーでのメール アドレスの再利用

ユーザーがメール アドレスを使用しなくなった場合 (退職など)、メール アドレスを別のユーザーに割り当てることができます。ただし、新しいユーザーが古いアカウントのコンテンツを取得できないようにするため、まず、新しいアカウントでメール アドレスを利用できるようにする必要があります。

メール アドレスを利用可能にするには、次の手順を実行します。

  1. [管理対象アカウント] ページから、メール アドレスが不要になったユーザーのアカウント詳細を開きます。アイデンティティ プロバイダーからアカウントを削除した場合、アカウントが非アクティブ化されます。

  2. [アカウントを削除] を選択します。詳細やアカウントの削除による影響については「管理対象アカウントを削除する」をご参照ください。

メール アドレスは削除されたユーザーのアカウントとリンクされなくなり、別のユーザーに割り当てることができるようになります。

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

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

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

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

SAML シングル サインオン設定を削除する前に、ユーザーがログインするには Atlassian アカウントのパスワードが必要となることを確認しておく必要があります。

  • SAML シングル サインオンが有効になる前から Atlassian アカウントのパスワードを設定しているユーザーは、ログインにそのパスワードを使用します。

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

SAML シングル サインオンを削除する方法:

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

  2. [セキュリティ] > [SAML シングル サインオン] の順に選択します。

  3. 次に、下にスクロールし、[構成の削除] をクリックします。削除を確認します。

アイデンティティ プロバイダーに移動し、そこで Atlassian の SAML 設定を削除することをお勧めします。

SAML シングル サインオンを削除しても、Atlassian Access は解約されないことにご注意ください。管理対象アカウントへのセキュリティ ポリシーの適用を中止する場合は、Atlassian Access を解約できます。

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

アイデンティティ プロバイダーによってエラーが表示される場合、Atlassian サポートではなく、アイデンティティ プロバイダーが提供するサポートおよびツールをご利用ください。

SAML の設定が原因でユーザーが Atlassian Cloud 製品にアクセスできない場合は、Atlassian アカウントのログイン画面に移動し、[ログインできませんか?] をクリックして指示に従います。

パスワードをリセットしても問題が解消されない場合は、設定したアカウントのトラブルシューティングを admin.atlassian.com から実行できます。

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

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

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

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

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

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

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

認証ポリシーを使用する SAML 設定のトラブルシューティング

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

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

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

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

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

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

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

公開 x509 証明書のトラブルシューティング

公開 x509 証明書エラーが発生した場合は、次のいずれかのステップを試してエラーを解決してください。

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

  2. [セキュリティ] > [SAML シングル サインオン] の順に選択します。

  3. [設定を編集] を選択します。

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

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

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

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

特定のエラーと考えられる課題をトラブルシューティング

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

エラー メッセージと解決策を表示するには、ここをクリックしてください。

エラー

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

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

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

IdP のエラー画面

ユーザーが IdP から Atlassian 製品にアクセスできないなど、アイデンティティ プロバイダーの設定による問題が発生する場合があります。IdP でチケットを起票して問題の解決を依頼します。

"Your email address has changed at your Identity Provider. Ask your administrator to make a corresponding change on your Atlassian products."

SAML ベータによる既知の問題:今後、ユーザー管理から管理アカウントのメールアドレスを変更できるようになります。

"We weren't able to log you in, but trying again will probably work."

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

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

  • "Invalid issuer in the Assertion/Response"

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

"xxx is not a valid audience for this Response"

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

"The response was received at xxx instead of xxx"

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

"The authenticated email address we were expecting was 'xxx', but we received 'xxx'. Please ensure they match exactly, including case sensitivity. Contact your administrator to change your email to match."

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

  • "We were expecting an email address as the Name Id, but we got xxx. Please ask your administrator to check that Name Id is mapped to email address."

  • "We were expecting an email address as the Name Id, but didn't get one. Please ask your administrator to check that Name Id is mapped to email address."

  • "We were expecting a user ID, but didn't get one. Please ask your administrator to check that user ID is populated in the response. See the configuration and troubleshooting guide below."

  • "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"

  • "The attributes have expired, based on the SessionNotOnOrAfter of the AttributeStatement of this Response"

  • "There is an EncryptedAttribute in the Response and this SP not support them"

  • "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"

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

  1. アイデンティティ プロバイダーはメールを NameId として返すことができます。

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

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

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

 

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

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

 

 

 

よくあるご質問

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

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

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

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

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

アトラシアンのクラウド製品のスクリプトとサービスにおける基本認証では、パスワードではなく API トークンを使用することをお勧めします。API トークンの使用に関する詳細についてご確認ください

 

その他のヘルプ