This page last changed on Mar 08, 2011 by ggaskell.
Configuring authentication for an application link is essentially defining the level of trust between JIRA and another application. |
|
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 you are linking trust each other? i.e. 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 you are linking share the same set of users and user names?
- Do you have administrative access to the application you are linking to JIRA?
Common scenarios include:
- If the two applications you are linking trust each other and share the same set of users and user names, configure two-way authentication using Trusted Apps for both incoming and outgoing authentication. For example, you may link your internal JIRA server to an internal FishEye server.
- If the two applications you are linking trust each other but do not share the same set of users or user names, configure two-way authentication using OAuth for both incoming and outgoing authentication. For example, you may link your internal JIRA server to an external (customer-facing) Confluence server.
- If you do not have administrative rights to the application that you are linking to (e.g. linking to a public FishEye 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 Confluence server to a partner organisation's Confluence 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:
Flowchart above: Determining what authentication to configure for an Application Link
Security Implications for each Authentication Type
If you configure Trusted Apps authentication (i.e. both applications fully trust each other and have the same set of users and user names), please be aware of the following security implications:
- Trusted applications are a potential security risk. When you configure trusted apps authentication, you are allowing one application to access another as any user. This allows all of the built-in security measures to be bypassed. Do not configure a trusted application unless you know that all code in the application you are trusting will behave itself at all times, and are sure that the application will maintain the security of its private key.
If you configure OAuth authentication (i.e. both applications fully trust each other but have different sets of users or user names), 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.

Screenshot above: Configuring authentication during application link setup
About Primary Authentication Types
Multiple authentication types can be configured for each Application Link using Unified Application Links (UAL). 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 UAL and depends on a weight defined by each authentication type method. However, every feature that uses UAL can also choose to use a specific authentication type and might not use the default primary authentication type method.
About Impersonating and Non-Impersonating Authentication Types
UAL makes the following distinction between authentication type methods:
- Impersonating authentication types will make requests on behalf of the user that is currently logged in. This includes OAuth and Trusted Apps authentication.
- Non-impersonating authentication types always use a pre-configured user when making a request. This includes basic HTTP authentication.
To determine which is the right authentication type to configure, you should refer to the documentation for the feature that is using UAL.
In general, impersonating authentication types are a good fit for the following:
- A feature with functionality that displays information that is only visible to the logged in user from a remote application.
- A feature with functionality where actions are performed on behalf of the current user in the remote server.
In general, non-impersonating authentication types are a good fit for the following:
- A feature that relies on having a certain permission at the remote application, regardless of whether the current logged-in user has the permission.
|