SAML シングル サインオン

robotsnoindex


最近、認証設定が変更されたことにお気づきのことと思います。
3 月 15 日の週から、SAML シングル サインオンおよびその他の設定を新しい認証ポリシーに移行し始めました。変更内容をご確認ください。



Atlassian Access をサブスクライブすると、SAML シングル サインオンを利用できます。Atlassian Access を開始する方法については、こちらをお読みください。

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

SAML シングル サインオン (SSO) は、Atlassian クラウド製品にログインするときに企業のアイデンティティ プロバイダーを介してユーザーが認証できるようにします。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 プロバイダーへのアトラシアン製品の追加

この手順では、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. アイデンティティ プロバイダーから Atlassian 組織への詳細のコピー

  1. robotsnoindex
    robotsnoindex

    admin.atlassian.com で、ご利用の組織から、

     [セキュリティ] > [SAML シングル サインオン] を選択します。

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

  3. アイデンティティ プロバイダーの詳細情報を次のフィールドにコピーします。

    フィールド

    説明

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

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

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

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

    公開 x509 証明書

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

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

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

3. アトラシアンの組織から ID プロバイダーへの詳細のコピー

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

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

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

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

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

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

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

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

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

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

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

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

2021 年 3 月中旬から 4 月末まで、認証ポリシーの適用を開始します。SAML シングル サインオンのテスト方法は変更されます。認証ポリシーが適用されたら、それを使用して 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 でのジャストインタイム プロビジョニング

セルフ サインアップが有効化されている場合、新規ユーザーに対して 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. robotsnoindex
    robotsnoindex

    admin.atlassian.com で、ご利用の組織から、

     [セキュリティ] > [SAML シングル サインオン] を選択します。

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


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

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


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

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

SAML 構成が原因でユーザーがアトラシアンのクラウド製品にアクセスできない場合は、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 シングル サインオン]> [構成を編集] の順に移動します。
  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 が正しくない可能性があります。正しい Entity 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 トークンの使用」を参照してください。


最終更新日: 2021 年 12 月 4 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.