OAuth security for application links

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

When you connect Atlassian applications using application links you get the security of the industry-standard OAuth authorization protocol. For a great introduction to how the OAuth authorization flow works, see this blog post.

To update an application link to use just OAuth, see Update application links to use OAuth.

If you want to create an application link between two Atlassian applications, see Link Atlassian applications to work together.

For version 5.2 and later, application links no longer support the Trusted Applications or Basic Access authentication types.

 

There are two OAuth security models that you can use with Atlassian application links:

 

OAuth 認証

偽装を伴う OAuth

説明
  • The user is redirected to log in to the remote application, after which tokens generated on their behalf are used to authorize requests made from the local application.
  • The remote application handling the request uses the access permissions of the account with which the user logged in on that remote application.
  • The local application makes requests on behalf of the user who is logged in to the application.
  • The remote application handling the request uses the access permissions of the account with which the user logged in on the local application.
利点
  • Can be used where the applications have different userbases (so a user can have different accounts on each application).
  • The user's credentials are never sent between applications, and so can only be compromised with difficulty.
  • Users see only the information that they have permission to see. 
  • Users don't need to authenticate when they request restricted resources from the remote application.
  • Users see only the information that they have permission to see. 
要件
  • A user has to authenticate on the remote application when first requesting restricted resources there (subsequent requests use the same token until the token expires).
  • The Development panel in the Jira Software issue view only supports OAuth authentication.
  • 両方のアプリケーションはアトラシアン アプリケーションでなければなりません。
  • Both applications must share the same userbase (typically managed with an external directory using LDAP).

You shouldn't link to a non-Atlassian application using OAuth authentication, unless you trust the other application. Applications connected using application links have the ability to use OAuth to impersonate users and so are a potential security risk for the applications they connect to. If your server is compromised, the data there and on linked servers is at risk.

 

OAuth authentication redirects a user to log in to the remote application, after which tokens generated on their behalf are used to authorize requests made from the local applicationThe remote application handling the request uses the access permissions of the account with which the user logged in on that remote application.

通常のシナリオには以下が含まれます。

  • 同じユーザーのセットを共有しない2つのアプリケーション間のアプリケーション リンクをセットアップします。
  • パブリック サインオンが可能になったアプリケーションへのリンクや、以前共有ユーザーベースで設定されたリンクを使用し続ける場合、アプリケーション リンクを編集する際に、OAuth (偽装OAuth に変更することで、アプリケーション リンクを更新することができます。

See Update an existing link on this page for instructions.

 

偽装を伴う Atlassian OAuth は、Atlassian アプリケーション間の深い統合の恩恵を簡単に受けることができるようになります。

  • 他のアプリケーションで自動的に認証され、リクエストの認可を求められません。
  • 表示する権限のある情報が表示されます。 

偽装認証は現在ログイン中のユーザーに代わりリクエストを行います。

Note that Atlassian OAuth with impersonation can only be used for application links between Atlassian applications. Furthermore, it should only be used when the two applications share the same userbase, typically managed with an external directory using LDAP.

一般的なシナリオは以下のとおりです。

  • You've set up an application link but your users still have to authenticate regularly. This can occur when the application link has been configured to not share the same userbase. If those applications do share the same userbase, you can update your application link by selecting OAuth (impersonation) when editing the application link.

See Update an existing link on this page for instructions.

 

以下の場合は、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 証明書 (自己署名証明書ではありません) を使用する必要があります。

最終更新日 2017 年 9 月 13 日

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

はい
いいえ
この記事についてのフィードバックを送信する

このセクションの項目

Powered by Confluence and Scroll Viewport.