This is the documentation for FishEye 3.3. View the latest version of

Unknown macro: {spacejump}

or visit the latest FishEye documentation home page.

When you configure authentication for an application link, you are defining the level of trust between FishEye and the other application.

On this page:

Basic HTTP authentication allows FishEye to provide a specific set of user credentials to a remote application and vice versa. Once authenticated, one application can access specified functions on the other application on behalf of that user. For example, if you supply the credentials of a FishEye administrator on your FishEye server to a remote application, the remote application will be able to access all functions on your FishEye server that the FishEye administrator can access.

OAuth is a protocol that allows a web application such as FishEye to share data and resources with any other OAuth-compliant application. These applications could be another web application (such as a JIRA site), a desktop application or a mobile device application, provided that they are accessible from within your network or available on the Internet.

A typical scenario is to set up an application link between two applications which trust each other, have the Application Links plugin installed, but do not share the same set of users. In this case, you would configure OAuth for both outgoing and incoming authentication.

Trusted Applications authentication allows one application to gain access to specified functions within another application on behalf of any user, without the user having to log in to the second application.

A typical scenario is to set up an application link between two applications which trust each other, have the same set of users and have the application links plugin installed. In this case, you would configure Trusted Applications for both outgoing and incoming authentication.

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 other 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 FishEye 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 FishEye 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 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 FishEye server to a partner organisation's FishEye server. An unauthenticated link will still allow the local application to render hyperlinks to the remote application or query anonymously-accessible APIs.

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

 

 

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:

  • Trusted applications are a potential security risk. When you configure Trusted Applications 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 you are sure that the application will maintain the security of its private key.
  • Only use Trusted Applications authentication if both your servers have the same set of users and the servers fully trust each other.

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

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.

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 application. The remote application handling the request uses the access permissions of the account with which the user logged in on that remote application.

Typical scenarios include:

  • You are setting up an application link between two applications that do not share the same set of users.
  • You want to continue using a link to an application that now allows public sign-on and the link was previously configured with a shared userbase. You can update your application link by changing OAuth (impersonation) to OAuth when editing the application link.

See OAuth security for application links for more information.

Atlassian OAuth with impersonation makes it easy for your users to benefit from the deep integrations between Atlasssian applications:

  • they're automatically authenticated on the other application and don't get asked to authorize requests.
  • they'll only see the information that they have permission to see. 

Impersonating authentication makes requests on behalf of the user who is currently logged in.

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.

A typical scenario is:

  • 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 OAuth security for application links for more information.

When you configure authentication for an application link, you are defining the level of trust between the two linked servers. When configuring a link from one application to another, you can set up:
  • Incoming authentication (authentication of requests coming from a linked application into this application).
  • Outgoing authentication (authentication of requests sent from this application to a linked application).

  • No labels

 

 

 Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.