アプリケーション リンクの OAuth セキュリティ
アプリケーション リンクを使用してアトラシアン アプリケーションを接続すると、業界標準の OAuth 認証プロトコルが提供されます。OAuth の認証フローの仕組みの概要については、このブログ投稿をご参照ください。
OAuth のみを使用するためにアプリケーション リンクを更新したい場合、「アプリケーション リンクを更新して OAuth を使用する」をご参照ください。
2 つのアトラシアン アプリケーション間でアプリケーション リンクを作成する方法については「アトラシアン アプリケーションをリンクして連携させる」をご参照ください。
アプリケーション リンクのバージョン 5.2 以降では、信頼済みのアプリケーションや基本アクセス認証タイプはサポートされません。
OAuth のセキュリティ モデル
アトラシアンのアプリケーション リンクでは 2 つの OAuth セキュリティ モデルを使用できます。
OAuth 認証 | 偽装を伴う OAuth | |
|---|---|---|
| 説明 |
|
|
| メリット |
|
|
| 要件 |
|
|
接続先が信頼済みである場合を除き、OAuth を使用して非アトラシアン アプリケーションにリンクすることは推奨されません。アプリケーション リンクを使用して接続されたアプリケーションは OAuth を使用してユーザーになりすますことができるため、接続先のアプリケーションの潜在的なセキュリティ リスクになります。サーバーが攻撃された場合、そのサーバーとリンクされたサーバーのデータが脅威に晒されます。
OAuth 認証
OAuth 認証はユーザーがリモート アプリケーションにログインするようにリダイレクトします。その後、ユーザー用に生成されたトークンが、ローカル アプリケーションから生成されたリクエストの認可に使用されます。リクエストを処理するリモート アプリケーションは、リモート アプリケーションにログインしたユーザーのアカウントのアクセス権限を使用します。
一般的なシナリオには以下が含まれます。
- 一連の同じユーザーを共有しない 2 つのアプリケーション間にアプリケーション リンクをセットアップする場合。
- パブリック サインオンが許可されるようになったアプリケーションへのリンクや、共有ユーザーベースで以前に構成されたリンクを引き続き使用したい場合。アプリケーション リンクを編集する際に、[OAuth (偽装)] を [OAuth] に変更して、アプリケーション リンクを更新することができます。
詳細な手順については、このページの「既存のリンクの更新」をご参照ください。
偽装を伴う OAuth
アトラシアンの偽装を伴う OAuth により、アトラシアン アプリケーション間での緊密な連携のメリットをユーザーに簡単に提供できます。
- ユーザーは他のアプリケーションで自動的に認証され、リクエストの認可を求められません。
- ユーザーには、自身が表示権限を持つ情報のみが表示されます。
偽装認証は、現在ログイン中のユーザーに代わりリクエストを行います。
アトラシアンの偽装を伴う OAuth は、アトラシアンのアプリケーション間のアプリケーション リンクにのみ使用できることにご注意ください。また、2 つのアプリケーションが同じユーザーベース (通常は LDAP を使用した外部ディレクトリで管理) を共有している場合にのみ使用する必要があります。
一般的なシナリオは以下のとおりです。
- アプリケーション リンクをセットアップしたが、ユーザーが引き続き定期的に認証を行う必要がある場合。これはアプリケーション リンクが同じユーザーベースを共有しないように設定された場合に発生することがあります。これらのアプリケーションが同じユーザーベースを共有しない場合、アプリケーション リンクを編集する際に、[OAuth (偽装)] を選択してアプリケーション リンクを更新することができます。
詳細な手順については、このページの「既存のリンクの更新」をご参照ください。
OAuth を使用するように既存のリンクを更新する
以下の場合は、OAuth を使用するように既存のアプリケーション リンクを更新する必要がある場合があります。
- バージョン 5.2 以降のアプリケーション リンクを使用するバージョンにアトラシアン アプリケーションをアップグレードした場合。「アプリケーション リンクのバージョン マトリクス」を参照してください。
- 既存のリンクは信頼済みアプリケーションの認証を使用しているが、チームは Jira Software 課題の開発パネルで Bitbucket Server などの開発者ツールからの要約情報を表示できない場合。
- 既存のアプリケーション リンクが OAuth を使用しているが、チームは Jira Software 課題の開発パネルで詳細ダイアログを表示できない場合。
- OAuth 認証タイプが必要なプラグインを使用している場合。
ここでは Jira Software での方法を説明しますが、他のアトラシアン サーバー製品でもプロセスはほとんど同じです。
ローカル アプリケーションの開始
ローカル アプリケーションの管理領域の [アプリケーション リンクの設定] ページに移動します。
更新が必要なリンクの横に DEPRECATED というマークが表示される場合があります。
[編集] ダイアログの [接続] 配下でリンクのローカル認証を設定します。
次のいずれかを選択します。
- OAuth (両方のアプリケーションに異なるユーザーベースがある場合)
- OAuth (偽装) (両方のアプリケーションが同じユーザーベースを共有している場合。多くの場合は LDAP を使用して外部ディレクトリで管理されます)
入力および出力方向の両方で、ローカルおよびリモート エンドの認証が一致していることを確認します。
[変更を保存] をクリックします。
リモート アプリケーションでの操作
リモート アプリケーションの管理領域の [アプリケーション リンクの設定] ページに移動します。表示している UI と一致する手順の列を選択します (いずれも同じ結果になります)。
[編集] ダイアログの [接続] 配下でリンクのローカル認証を設定します。
次のいずれかを選択します。
- OAuth (両方のアプリケーションに異なるユーザーベースがある場合)
- OAuth (偽装) (両方のアプリケーションが同じユーザーベースを共有している場合。多くの場合は LDAP を使用して外部ディレクトリで管理されます)
入力および出力方向の両方で、ローカルおよびリモート エンドの認証が一致していることを確認します。
[変更を保存] をクリックします。
[設定] ダイアログで、[送信認証] をクリックして [OAuth] タブをクリックします。
[2-Legged OAuth の有効化] を選択します。ここでは、アプリケーションは異なるユーザーベースを持っていると想定しています。
両方のアプリケーションが同じユーザーベースを共有している場合 (一般に LDAP を使用して外部ディレクトリで管理されます)、必要に応じて [2-Legged OAuth (なりすまし機能あり) の有効化] を選択します。
[更新] をクリックします。
次に、[受信認証] をクリックしてから、[OAuth] タブをクリックします。
[2-Legged OAuth の有効化] を選択します。ここでは、アプリケーションは異なるユーザーベースを持っていると想定しています。
両方のアプリケーションが同じユーザーベースを共有している場合は、任意で [2-Legged OAuth (なりすまし機能あり) の有効化] を選択します。
[更新] をクリックします。
注意:
Jira Software の開発パネルの要約データを表示できるユーザーが、その要約に集約される、詳細ダイアログの各情報 (ブランチ、コミット、プル リクエストなど) の閲覧権限を持っていない場合があります。これは、詳細ダイアログが、接続されたアプリケーションでそのユーザーが持っているアクセス権限を尊重しているためです。
開発パネルを表示するには、チーム メンバーが Jira Software で "開発ツールの表示" 権限を持っている必要があります。
Jira Software とアトラシアン開発者ツール (Bitbucket Server、Bamboo、Crucible、Fisheye) 間のアプリケーション リンクでは、信頼済みアプリケーションによる認証および Basic 認証が無効化されている必要があります。
ポート 443 でアプリケーションを実行する場合、すべての機能を利用するには、有効な SSL 証明書 (自己署名証明書ではありません) を使用する必要があります。