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 つ以上のドメインを確認する – 組織のドメインの検証についてご確認ください。
Atlassian Access をサブスクライブする。
また、次の点を確認しておくことをおすすめします。
Atlassian 製品とご利用のアイデンティティ プロバイダーの両方が相互の通信に HTTPS プロトコルを使用すること。また、設定された製品のベース URL が HTTPS のものであること。
SAML 認証リクエストは限られた期間のみ有効であるため、アイデンティティ プロバイダー サーバーの時間が NTP を使用して同期されていること。SaaS アイデンティティ プロバイダーを使用している場合は、時間がすでに同期されているはずです。
SAML シングル サインオンを設定する前に、SAML 構成に誤りがあった場合に備えて組織へのアクセスを保持するための Atlassian アカウントを作成します。このアカウントは、以下を満たす必要があります。
組織について検証したドメインのメール アドレスを使用していないこと。これによって、ログイン時にアカウントが SAML シングル サインオンにリダイレクトされなくなります。
サイト管理者アクセス権と組織管理者アクセス権の両方が付与されていること。
このアカウントは一時的なものと考えてください。SAML シングル サインオンがユーザーの期待通りに動作していることを確認したら、管理者アクセス権を削除できます。
SAML シングル サインオンのセットアップ
このセクションでは、SAML シングル サインオンをセットアップする方法について説明します。
管理対象ユーザーに対して SAML シングル サインオンをセットアップするには、Atlassian Access をサブスクライブ済みである必要があります。この方法の詳細については、「Atlassian Access のセキュリティ ポリシーと機能の適用」を参照してください。
SAML シングル サインオンの構成中は、ユーザーは Atlassian クラウド製品にログインできません。SAML への移行日時のスケジューリングやユーザーへの事前通知を検討してください。
SAML シングル サインオンの設定を開始する前に、SAML シングル サインオンに関するこのビデオをご確認ください。
ご利用のアイデンティティ プロバイダーが以下に記載されている場合は、アイデンティティ プロバイダーの指示に従って SAML シングル サインオンをセットアップします。
アイデンティティ プロバイダー | セットアップ手順 |
---|---|
Active Directory フェデレーション サービス | |
Microsoft Azure AD | |
Auth0 | |
Google Cloud | |
Idaptive (旧称: Centrify) | |
Okta | |
OneLogin | これらのページを表示するには、OneLogin にログインする必要があります。 |
PingIdentity |
他のアイデンティティ プロバイダー向けの 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。
|
IdP-initiated SAML の場合、組織の URL をデフォルトのリレー状態として入力します。https://
を組織の URL の一部として含めます。
2. アイデンティティ プロバイダーから Atlassian 組織への詳細のコピー
- [セキュリティ] > [SAML シングル サインオン] を選択します。
admin.atlassian.com で、ご利用の組織から、
[SAML 設定の追加] をクリックします。
アイデンティティ プロバイダーの詳細情報を次のフィールドにコピーします。
フィールド
説明
アイデンティティ プロバイダー エンティティ ID
この値は、製品が認証リクエストを許可するアイデンティティ プロバイダーの URL です。
アイデンティティ プロバイダー SSO URL
この値はユーザーがログイン時にリダイレクトされる URL を定義します。
公開 x509 証明書
この値は、「-----BEGIN CERTIFICATE-----」で始まります。
この証明書には、受信したすべての SAML 認証リクエストがアイデンティティ プロバイダーで発行されていることを検証するために使用する公開鍵が含まれています。
構成の保存をクリックします。
3. アトラシアンの組織から ID プロバイダーへの詳細のコピー
Atlassian 組織の「SAML シングル サインオン」ページにアイデンティティ プロバイダーの詳細を追加すると、新しいフィールドと値が表示されます。これらの値をアイデンティティ プロバイダーにコピーします。
すべてのコピーが終わったら、アイデンティティ プロバイダーで保存をクリックします。
4. アトラシアン組織の SAML シングル サインオンのテスト
Atlassian 組織で保存をクリックすると、SAML 設定が適用されます。ユーザーはログアウトされないため、以下の手順を使用して SAML 設定を調整しながらテストします。
ブラウザで新しいシークレット ウィンドウを開きます。
検証済みドメインのいずれかのメール アドレスを使用してログインします。
サインインできてアクセス権限が期待した内容と一致することを確認します。
ログイン エラーが発生した場合は、以下の「SAML シングル サインオンのトラブルシューティング」セクションを参考に設定を調整して、再度シークレット ウィンドウでテストします。
正常にログインできない場合、設定を削除して、ユーザーが Atlassian 製品にアクセスできることを確認します。
ログイン エラーが発生した場合、以下の「SAML シングル サインオンのトラブルシューティング」セクションを使用して設定を調整し、再度シークレット ウィンドウでテストします。
正常にログインできない場合、設定を削除して、ユーザーが Atlassian 製品にアクセスできることを確認します。
認証ポリシーによる SAML シングル サインオンのテスト
2021 年 3 月中旬から 4 月末まで、認証ポリシーの適用を開始します。SAML シングル サインオンのテスト方法は変更されます。認証ポリシーが適用されたら、それを使用して SAML シングル サインオンをテストします。その実施方法については、このセクションをお読みください。
認証ポリシーによって、組織内のユーザー セットごとに異なるセキュリティ レベルを設定する柔軟性が得られます。また、認証ポリシーによって、会社全体にロールアウトする前にユーザーのサブセットでさまざまなシングル サインオン設定をテストできるため、リスクを軽減できます。
以下を実行してください。
組織全体でロールアウトする前に、比較的小さいユーザー グループでシングル サインオン (SSO) または 2 段階認証をテストして、正しく設定されていることを確認します。
管理アカウントごとに異なるポリシーを設定することで、ログインして SSO ポリシーをトラブルシューティングするか、プロバイダー統合を特定できます。
認証の設定をテストするには、SAML シングル サインオンを設定して適用する必要があります。次のセクションでは、その手順について説明します。
認証ポリシーを使用する SAML シングル サインオンの設定と適用
SAML を設定して保存し、認証ポリシーで SAML シングル サインオンを適用する必要があります。
認証ポリシーからの SAML シングル サインオンの設定:
admin.atlassian.com で [認証ポリシー] に移動します。
設定するポリシーの [編集] を選択します。
SAML シングル サインオンの使用を選択すると、[認証ポリシー] から SAML SSO 設定ページにリダイレクトされます。
SAML SSO の設定を完了すると、ポリシーで SSO を適用する必要があります。
シングル サインオンの適用:
admin.atlassian.com で [認証ポリシー] に移動します。
強制するポリシーの [編集] を選択します。
[Enforce single sign-on (シングル サインオンの強制)] を選択します。
SAML でのジャストインタイム プロビジョニング
セルフ サインアップが有効化されている場合、新規ユーザーに対して Atlassian アカウントを手動で作成する必要はありません。そのユーザーが SAML を使用して最初にログインした際に、Atlassian アカウントが自動的に作成されます。
新規ユーザーが Jira、Confluence、または Bitbucket に初めてアクセスした際には、次のようになります。
- ユーザーは自身のメール アドレスを入力します。
- ご利用のアイデンティティ プロバイダーのログイン画面が表示され、ユーザーは自身の資格情報を入力して認証します。
- 対象のメール アドレスに、Atlassian アカウントのメール アドレスを確認するためのメールが送信されます。
- ユーザーはメール内の確認リンクをクリックしてログインし、アクセスしようとしていたサイト (Jira、Confluence、または Bitbucket) が開きます。
start.atlassian.com では、自身がアクセス権を持っている複数のクラウド サイトを 1 か所で確認できます。
認証ポリシーを使用したジャストインタイム プロビジョニング
すべての組織には、そのユーザーに対するログイン設定を含むデフォルト認証ポリシーがあります。新しいアカウントを提供する場合、デフォルト ポリシーに新しいユーザーを追加します。
ジャストインタイム プロビジョニングで認証ポリシーを活用するには、デフォルト ポリシーに SAML シングル サインオンを適用する必要があります。
デフォルト ポリシーに SAML シングル サインオンを適用したくない場合、SCIM でユーザーにプロビジョニングできます。ID プロバイダーでメール アカウントを変更すると、自動的に Atlassian アカウントが変更されます。
ジャストインタイム プロビジョニングなしでメールの更新をトラブルシューティングする
ID プロバイダーでメールを変更する場合は、Atlassian アカウントから手動で更新する必要があります。
最初の Atlassian メールを更新しない場合、ユーザーのログイン時に 2 つ目のメール アカウントが作成されます。このアカウントでは、サイトや製品にアクセスできません。これを修正するには、最初のメール アカウントを更新するか削除できます。元のアカウントのメールを更新します。
SAML でのユーザーの無効化
ユーザーによる REST API 経由での組織データの取得を防止するには、組織とアイデンティティ プロバイダーの両方でユーザーを無効化します。
組織でユーザー プロビジョニングもセットアップ済みの場合、アイデンティティ プロバイダー側でのユーザーの無効化のみが必要です。
異なるユーザーでのメール アドレスの再利用
ユーザーがメール アドレスを使用しなくなった場合 (退職など)、メール アドレスを別のユーザーに割り当てることができます。ただし、新しいユーザーが古いアカウントのコンテンツを取得できないようにするため、まず、新しいアカウントでメール アドレスを利用できるようにする必要があります。
メール アドレスを利用可能にするには、次の手順を実行します。
- [管理対象アカウント] ページから、メール アドレスが不要になったユーザーのアカウント詳細を開きます。アイデンティティ プロバイダーからアカウントを削除した場合、アカウントが非アクティブ化されます。
- [アカウントの削除] を選択します。詳細情報やアカウントの削除による影響については、「管理対象アカウントの削除」を参照してください。
メール アドレスは削除されたユーザーのアカウントとリンクされなくなり、別のユーザーに割り当てることができるようになります。
2 段階認証およびパスワード ポリシーを備えた SAML シングル サインオン
組織で Atlassian パスワード ポリシーおよび 2 段階認証が設定されている場合、SAML シングル サインオンを設定すると、ユーザーはそれらの対象ではなくなります。つまり、ログイン プロセスで、パスワード ポリシーと 2 段階認証は基本的に「スキップ」されます。
代わりにアイデンティティ プロバイダーが提供する同等の仕組みを使用することをお勧めします。
SAML シングル サインオンの削除
SAML シングル サインオン設定を削除する前に、ユーザーがログインするには Atlassian アカウントのパスワードが必要となることを確認しておく必要があります。
- SAML シングル サインオンが有効になる前から Atlassian アカウントのパスワードを設定しているユーザーは、ログインにそのパスワードを使用します。
- SAML シングル サインオンが有効になってから参加したユーザーは、次回ログイン時に Atlassian アカウントのパスワードをリセットする必要があります。
SAML シングル サインオンを削除する方法:
- [セキュリティ] > [SAML シングル サインオン] を選択します。
admin.atlassian.com で、ご利用の組織から、
- 次に、下にスクロールし、[構成の削除] をクリックします。削除を確認します。
アイデンティティ プロバイダーに移動し、そこで Atlassian の SAML 設定を削除することをお勧めします。
SAML シングル サインオンを削除しても、Atlassian Access のサブスクライブが中止されるわけではないことに注意してください。管理対象アカウントへのセキュリティ ポリシーの適用を中止する場合、Atlassian Access を解約できます。
SAML 設定のトラブルシューティング
SAML 構成が原因でユーザーがアトラシアンのクラウド製品にアクセスできない場合は、Atlassian アカウントのログイン画面に移動し、[ログインできませんか?] をクリックして指示に従います。
パスワードをリセットしても問題が解消されない場合は、設定したアカウントのトラブルシューティングを admin.atlassian.com から実行できます。
SAML 設定のトラブルシューティング
SAML を設定する前に、未検証のドメインからのメールで Atlassian ユーザー アカウントを作成します。
そのユーザーを組織管理者にします。
SAML で認証する必要がないため、このアカウントでログインしてトラブルシューティングします。
組織の SAML シングル サインオン ページに移動して、すべてのユーザーの SAML シングル サインオンを修正するか無効化します。
問題が解消されない場合は、SAML 設定を削除して Atlassian アカウントのパスワード認証に戻します。
SAML 設定を削除すると、パスワード ポリシー画面ですべてのユーザーのパスワードを無効化することができます。これによって、Atlassian アカウント パスワードのパスワード リセット プロセスを利用するようにユーザーに要求できます。
認証ポリシーを使用する SAML 設定のトラブルシューティング
SAML を設定する前に、未検証のドメインからのメールで Atlassian ユーザー アカウントを作成します。
そのユーザーを組織管理者にします。
SAML シングル サインオンを適用せずに、認証ポリシーにユーザーを追加します。
SAML で認証する必要がないため、このアカウントでログインしてトラブルシューティングします。
組織の SAML シングル サインオン ページに移動して、すべてのユーザーの SAML シングル サインオンを修正するか無効化します。
SAML 設定を削除する場合は、認証ポリシーで SAML シングル サインオンが使用されていないことを確認します。
ユーザーのロックアウトを防ぐには、ユーザーを SAML シングル サインオンを適用しないポリシーに移動する必要があります。
公開 x509 証明書のトラブルシューティング
公開 x509 証明書エラーが発生した場合は、次のいずれかの手順を試してエラーを解決してください。
admin.atlassian.com に移動します。
- [SAML シングル サインオン]> [構成を編集] の順に移動します。
証明書をもう一度コピーして貼り付けます。その際に次を含めてください。
証明書のすべての行。
“-----BEGIN CERTIFICATE-----" から “-----END CERTIFICATE-----" まで。
ID プロバイダーから提供された証明書が不完全である可能性があります、証明書をもう一度ダウンロードして [公開 x509 証明書] フィールドにコピー & ペーストします。
特定のエラーと考えられる課題をトラブルシューティング
サポート チケットを送信する際に、SAML Tracer Firefox アドオンから検索できる SAMLRequest と SAMLResponse の各ペイロードを添付してください。課題の潜在的な原因をより迅速に特定できるようになります。
よくある質問
検証できないドメインに SAML シングル サインオンを適用することはできますか?
いいえ。製品とリソースの安全性を維持するため、所有している検証可能なドメインでのみ SAML シングル サインオンを使用できます。
ユーザーのフル ネームを変更する方法
ユーザーの氏名は、アイデンティティ プロバイダーのシステムで姓と名を更新することで更新できます。更新された名前は、ユーザーが次にログインするときに組織に同期されます。
REST API による認証の仕組みを教えてください。
アトラシアン クラウド製品でのスクリプトおよびサービスでのベーシック認証では、パスワードではなく API トークンを使用することをお勧めします。詳細については、「API トークンの使用」を参照してください。