Trusted Applications: Support Authentication Context Passing from Confluence or another Application to JIRA

Use Case: A user makes a request to application A. To complete this request, A needs to retrieve information from application B with that user's credentials.

Example: The JIRA Issues Macro in Confluence currently can only show issues that are public (available to all users) or to a specific user/password encoded in plain-text in the macro's issue URL. Instead, we want to pass the name of the user viewing the page containing the macro to JIRA and then show all issues that user can see.

We need a secure way to pass a user's credentials around between applications. As the password is not stored, passing that around is not an option. Using Crowd, or any other SSO solution, the user's SSO token can be passed around, but we need a solution that works when not under SSO as well.

In short this involves creating trusted relationships between applications. For instance, a Confluence administrator requests a trusted connection from it to JIRA. The JIRA URL is entered and a conversation is initiated that involves a key exchange, then a JIRA administrator is required to authorise the Confluence application as trusted. Confluence is then notified that it is a trusted application, and any requests from it will contain special headers containing encrypted information identifying the application, the user and the time of the request (to stop replay attacks). The requested application should have several options to specify the security levels required such as net-mask (to tie the requesting application to a specific IP or range), time-out (for replay attacks) and secure key exchange (eg. only over HTTPS).

Note: it is anticipated this is a core Atlassian component, but individual applications will need to provide client and server facilities like key persistence and configuration user-interface.