SAML シングル サインオン

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

Atlassian Access をサブスクライブすると、SAML シングル サインオンを利用できます

Atlassian Access はご利用のアトラシアン クラウド製品すべてに対して、企業全体での可視性、安全性、およびコントロールを実現します。1 つの製品からユーザーを管理したりセキュリティ ポリシーを適用したりして、ビジネスを確実に拡張できます。

Atlassian Access を開始する方法については、こちらをお読みください。


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

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

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

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

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


はじめる前に

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

  1. 組織を作成していること。詳細については「Atlassian 組織のセットアップ」をご参照ください。
  2. 1 つ以上のドメインを検証済みであること。確認方法については「組織のドメインを検証する」をご参照ください。ドメインを検証すると、検証済みドメインのメール アドレスを使用するすべての Atlassian アカウントが組織で管理されるようになります。
  3. 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 シングル サインオンの構成中は、ユーザーはアトラシアン クラウド製品にログインすることができません。SAML への移行日時のスケジューリングやユーザーへの事前通知を検討してください。

ご利用のアイデンティティ プロバイダが以下の表にある場合、それぞれのリンクをクリックし、SAML シングル サインオンのセットアップの手順に従ってください。

アイデンティティ プロバイダーセットアップ手順
AD FSActive Directory フェデレーション サービス (AD FS) を使用した SAML シングル サインオン構成
Microsoft Azure AD

参照先:

Google CloudAtlassian 用に SAML 経由での SSO を設定する
Idaptive (旧称: Centrify)
ヘルプ ページ
OktaAtlassian Cloud 向け SAML 2.0 の設定方法
OneLogin

参照先:

これらのページを表示するには、OneLogin にログインする必要があります。


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

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

  1. admin.atlassian.com で、ご利用の組織から、
     [セキュリティ] > [SAML シングル サインオン] を選択します。

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

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

    フィールド説明
    アイデンティティ プロバイダー エンティティ ID

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

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

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

    公開 x509 証明書

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

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

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

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

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

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

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

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

  1. ブラウザで新しいシークレット ウィンドウを開きます。
  2. 検証済みドメインのいずれかのメール アドレスを使用してログインします。
  3. 正しくサインインされ、期待されるアクセス権限がすべてあることを確認します。

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

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

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

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

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

  1. ユーザーは自身のメール アドレスを入力します。
  2. ご利用のアイデンティティ プロバイダーのログイン画面が表示され、ユーザーは自身の資格情報を入力して認証します。
  3. 対象のメール アドレスに、Atlassian アカウントのメール アドレスを確認するためのメールが送信されます。
  4. ユーザーはメール内の確認リンクをクリックしてログインし、アクセスしようとしていたサイト (Jira、Confluence、または Bitbucket) が開きます。

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

SAML でのユーザーの無効化

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

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


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

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

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

  1. [管理対象アカウント] ページから、メール アドレスが不要になったユーザーのアカウント詳細を開きます。アイデンティティ プロバイダーからアカウントを削除した場合、アカウントが非アクティブ化されます。
  2. [アカウントの削除] を選択します。詳細情報やアカウントの削除による影響については、「管理対象アカウントの削除」を参照してください。

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


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

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

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


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

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

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


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

  1. admin.atlassian.com で、ご利用の組織から、
     [セキュリティ] > [SAML シングル サインオン] を選択します。

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


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

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


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

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

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

パスワードをリセットしても問題が解消されない場合、admin.atlassian.com からトラブルシューティングを実行できます。SAML の構成を開始する前に、未検証のドメインのメール アドレスを使用する Atlassian アカウントを作成し、そのユーザーを組織管理者に設定しているはずです。SAML 認証を使用する必要がないため、このアカウントにログインしてシームレスにトラブルシューティングを行うことができます。

  1. 組織の SAML シングル サインオン ページに移動して、残りのユーザーの SAML サインオンを修正または無効化します。
  2. トラブルが解消されない場合、SAML 設定を削除し、Atlassian アカウントのパスワード認証に戻します。

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

サポート チケットを起票する場合、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 を使用していることを確認し、再度実行してください。

"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 シングル サインオンを使用できます。

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

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

SAML が利用できない Atlassian 製品はありますか?

SAML single sign-on isn't available yet for Trello or Statuspage, but we have plans to gradually roll out SAML single sign-on for these products. All managed Trello users will be able to log in with single sign-on starting June 1, 2020.

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

アトラシアン クラウド製品でのスクリプトおよびサービスでのベーシック認証では、パスワードではなく API トークンを使用することをお勧めします。詳細については、「API トークンの使用」を参照してください。


最終更新日 2020 年 5 月 8 日

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

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