Configuring authentication for an application link is essentially defining the level of trust between the two linked servers.
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 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 user base or not?
- 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 authentication
Excerpt Include |
---|
| _Definition_Incoming_Authentication |
---|
nopanel | true |
---|
| _Definition_Incoming_Authentication |
---|
|
and outgoing authentication Excerpt Include |
---|
| _Definition_Outgoing_Authentication |
---|
nopanel | true |
---|
| _Definition_Outgoing_Authentication |
---|
|
. For example, you may link your internal Confluence instance to an internal JIRA instance. - 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 authentication
Excerpt Include |
---|
| _Definition_Incoming_Authentication |
---|
nopanel | true |
---|
| _Definition_Incoming_Authentication |
---|
|
and outgoing authentication Excerpt Include |
---|
| _Definition_Outgoing_Authentication |
---|
nopanel | true |
---|
| _Definition_Outgoing_Authentication |
---|
|
. For example, you may link your internal Confluence instance to an external (customer-facing) JIRA instance. - If you do not have administrative rights to the application that you are linking to (e.g. linking to a public FishEye instance), 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 JIRA instance to a partner organisation's JIRA instance. 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:
Include Page |
---|
| _gliffyAuthenticationTypesFlowchart |
---|
nopanel | true |
---|
| _gliffyAuthenticationTypesFlowchart |
---|
|
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 (your servers have the same set of users and they fully trust each other), please be aware of the following security implications:
Include Page |
---|
| _securityTrustedApps |
---|
| _securityTrustedApps |
---|
|
If you configure OAuth authentication for your application (your servers have different sets of users and they fully trust each other), please be aware of the following security implications:
Include Page |
---|
| _securityOAuth |
---|
| _securityOAuth |
---|
|
Screenshot above: Configuring authentication during application link setup
Anchor |
---|
| primaryauthenticationtypes |
---|
| primaryauthenticationtypes |
---|
|
About Primary Authentication Types
Include Page |
---|
| _aboutPrimaryAuthTypes |
---|
nopanel | true |
---|
| _aboutPrimaryAuthTypes |
---|
|
About Impersonating and Non-Impersonating Authentication Types
Include Page |
---|
| _aboutImpersonatingAuthTypes |
---|
nopanel | true |
---|
| _aboutImpersonatingAuthTypes |
---|
|