Configuring Authentication for an Application Link

When you configure authentication for an application link, you are defining the level of trust between Crucible and the application that it is linked to.

On this page:

Choosing Authentication for an Application Link

The level of authentication that you should configure for your application link depends on a number of factors.

Do the two applications trust each other? In other words, are you sure that the code in the application will behave itself at all times and that the application will maintain the security of its private key?
Do the two applications share the same user base?
Do you have administrative access to the application you are linking to?

Common scenarios include:

If the two applications you are linking trust each other and share the same user base, configure two-way authentication using Trusted Applications for both incoming and outgoing authentication. For example, you may link your internal Crucible server to an internal JIRA server.
If the two applications you are linking trust each other but do not share the same user base, configure two-way authentication using OAuth for both incoming and outgoing authentication. For example, you may link your internal Crucible server to an external (customer-facing) JIRA server.
If you do not have administrative rights to the application that you are linking to (for example, linking to a public Crucible server), configure a one-way outgoing link authenticated using basic HTTP authentication or do not configure any authentication for the link. For example, you may link your external Crucible server to a partner organisation's Crucible server. An unauthenticated link will still allow the local application to render hyperlinks to the remote application or query anonymously-accessible APIs.

The flowchart below provides a guide to what authentication you should configure for your application link.

Read the following topics for information on how to configure authentication for an application link:

Configuring Authentication for an Application Link

Flowchart above: Determining what authentication to configure for an Application Link

Security Implications for each Authentication Type

If you configure Trusted Applications authentication for your application (meaning that your servers have the same set of users and they fully trust each other) please be aware of the following security implications:

信頼できるアプリケーションがセキュリティリスクを引き起こすかもしれません。信頼できるアプリケーションの認証を設定すると、1 つのアプリケーションに対し、他のアプリケーションへのアクセスをユーザーとして許可することになります。これは、組み込まれているセキュリティ対策すべてを回避します。信頼できるアプリケーションのすべてのコードがつねに適切に動作することを把握しており、アプリケーションがセキュリティのプライベートキーを維持する確証がない限り、信頼できるアプリケーションを設定しないでください。
両方のサーバーのユーザー群が同一であり、サーバーが相互に完全に信頼している場合にのみ、信頼されたアプリケーション認証を使用してください。

If you configure OAuth authentication for your application (meaning that your servers have different sets of users and they fully trust each other) please be aware of the following security implications:

Adding an OAuth consumer requires the transmission of sensitive data. To prevent 'man-in-the-middle' attacks, it is recommended that you use SSL for your applications while configuring OAuth authentication.
Do not link to an application using OAuth authentication, unless you trust all code in the application to behave itself at all times. OAuth consumers are a potential security risk to the applications that they are linked to because of the ability to impersonate users. If your server is compromised, the data there and on linked servers is at risk.
New application links now use OAuth by default and enable both 3-legged OAuth (3LO) and 2-legged OAuth (2LO).
When updating older application links (that perhaps used Trusted Apps authentication) to use OAuth, 3LO is enabled by default, but you need to explicitly enable 2LO using the Allow 2-legged OAuth check box in the application link configuration settings.
Only use the 2LO with impersonation option in the application link configuration settings if your servers both have the same set of users and the servers fully trust each other.

Screenshot above: Configuring authentication during application link setup

About Primary Authentication Types

You can configure multiple authentication types for each application link. When a feature makes a request using an Application Link, it will use one of the configured authentication types. If more than one authentication type is configured, it will by default use the authentication type that is marked as the primary authentication type. The default authentication type is indicated by the green tick

next to the authentication type on the list application link screen.

You cannot configure which authentication type is the primary authentication type. The primary authentication type is determined automatically by Application Links and depends on a weight defined by each authentication type method. However, every feature that uses Application Links can also choose to use a specific authentication type and might not use the default primary authentication type.

About Impersonating and Non-Impersonating Authentication Types

OAuth 認証

OAuth 認証はユーザーがリモートアプリケーションにログインするようにリダイレクトします。その後、ユーザー用に生成されたトークンが、ローカルアプリケーションから生成されたリクエストの認可に使用されます。リクエストを処理するリモートアプリケーションは、そのリモートアプリケーションにログインしたユーザーのアカウントのアクセス権限を使用します。

一般的なシナリオには以下が含まれます。

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

See OAuth security for application links for more information.

偽装を伴う OAuth

偽装機能を持つアトラシアンの OAuth を使用することで、ユーザーはアトラシアンアプリケーション間の緊密な連携を簡単に活用することができます。

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

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

アトラシアンの偽装を伴う OAuth は、アトラシアンのアプリケーション間のアプリケーションリンクにのみ使用できることにご注意ください。また、2 つのアプリケーションが同じユーザーベース (通常は LDAP を使用した外部ディレクトリで管理) を共有する場合にのみ使用します。

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

アプリケーションリンクをセットアップしましたが、ユーザーは引き続き定期的に認証を受ける必要があります。これはアプリケーションリンクが同じユーザーベースを共有しないように設定された場合に発生することがあります。アプリケーションが同じユーザーベースを共有しない場合、アプリケーションリンクを編集する際に、OAuth (偽装) を選択することで、アプリケーションリンクを更新することができます。