EXALATE 4.X
In Exalate 4.x, there is no need to share access credentials anymore, even if your instance requires authentication.
Starting from 4.0.0 version in the Exalate app for JIRA Server, 4.1.0 in the Exalate app for JIRA Cloud and 2.0.0 in the Exalate app for HP ALM/QC, Exalate is using a new security approach.
Learn more about Exalate security and architecture by downloading this whitepaper.
Below you can find answers to the most common security questions.
No, the invitation could be applied only to the invited side. It includes an Invitation code that helps to secure Connection data.
Once the Connection setup is finished, Exalate generates the shared secret. The secret is used to define a secure connection between both Instances.
It is shared only once to generate a JWT token. The token is temporary and is generated for every communication request between Exalate in both Instances.
The following information is exchanged between Instances:
- shared secret;
- information about the type of connection with the Destination instance;
- Connection name;
- information about the Connection initiator
- Exalate app version, including supported features
- Instance type and version ( JIRA Server, JIRA Cloud or HP ALM/QC)
- Instance URL and Exalate URL
- Instance UID, which is a unique instance identifier
The JWT token generates on every communication request between Instances. It authenticated the request so the destination side can be sure they are getting data from the expected Instance.
Instance URL, Instance version, Exalate URL, a unique instance identifier.
For more details check the Atlassian security overview.
In the configuration stage of the Exalate app for HP ALM/QC, you need to specify HP QC /ALM Instance(issue tracker) user and password. The credentials are used to communicate with the HP ALM/QC Instance.