Performance and Security Guidance for OSLC Connect for Jira
The following guide outlines performance/scalability measures as well as deployment recommendations for OSLC Connect for Jira. This document is actively updated to provide the most current information.
Atlassian Architecture, Compliance, and Verification
OSLC Connect for Jira is built according to the Atlassian API. It is a plugin installed and managed within Jira with the Jira Plugin Manager. There are no additional installations beyond the plugin jar on your Jira server.
The product is certified for both Jira Software Server and Jira Data Center. These certifications are valid and confirmed with Atlassian with the release on the marketplace.
The approval for Data Center requires an architectural review and performance testing. The procedure can be found here → https://developer.atlassian.com/platform/marketplace/dc-apps-submitting-your-app/.
Operating in a clustered environment includes actively managing these requirements → https://developer.atlassian.com/server/jira/platform/developing-for-high-availability-and-clustering/.
Additionally, approval for Jira Data Center requires testing with what Atlassian considers a large environment (https://developer.atlassian.com/platform/marketplace/testing-your-app-with-a-large-data-set/ ) and according to their protocol to assure for stable and collaborative operation in a DC instance → https://developer.atlassian.com/platform/marketplace/dc-apps-performance-toolkit-user-guide-jira/.
Our Software Server instance follows the same design and benefits the DC review and performance testing.
Licensing and License Management
Licensing of the product is based on the host URL for the Jira system. The delivery of the license is via an activation key file that imposes both server URL constraints and the duration of the license key.
There is no requirement to access the open internet or connection to SodiusWillert servers to license the product. The product will work when deployed in isolated/air-gapped networks when the activation key is delivered.
Backup and Restore
All persistence elements are stored via the Atlassian development guide. These data associated with OSLC Connect for Jira are stored in native Jira artifacts (e.g., OSLC Links) or in a few select database tables in the Jira repository. Normal Jira backup and restore procedures to apply.
Authentication and User Management
OSLC and OSLC Connect use Oauth to manage the authorization flow between servers. Authentication services remain the responsibility of the source repository and are delegated to the appropriate login prompt or SSO. This means that all actions (preview, link, create) initiated from the foreign tool will be authenticated and authorized for use. This allows local management of the permissions in repositories as well as normal audit practices for access.
Server Collaborations
Servers create direct relationships to authorize collaboration and enable collaboration at the request of another user. These relationships are named Friend relationships that identify a directional relationship from one server to another. The receiving server, Consumer, has the option to authorize or reject this relationship. This Friend relationship will serve as the foundation for the Oauth authentication flow for a specific user when a cross repository transaction occurs.
APIs and Access Points
OSLC Connect for Jira provides OSLC services to the Jira product. This enables both the standard OSLC collaboration with tools like IBM ELM or Siemens Polarion. Access to the services can be found by requesting the rootservices directory at https://myjiraserver/rest/oslc/1.0/rootservices. This will provide a directory of available services.
In addition, the product has a development guide available here → https://help.sodius.cloud/help/topic/com.sodius.oslc.app.jira.doc/html/dev/index.html?cp=0_2, to aid in the understanding of interacting. It will require some OSLC expertise, but it can access Jira artifacts via the standard.
The access to OSLC Connect for Jira is contained to your Jira server path https://myjiraserver/rest/oslc in case a team wants to monitor or shape OSLC access services via a load balancer.
Loading Scenarios for OSLC Connect for Jira
The OSLC standard focuses on small transactional loads to maximize the value while minimizing loading on servers. Additionally, leveraging the Jira plugin architecture guide and load testing ensures timely performance and minimizes overall loading.
Standard Small Loads
The standard loading is minimal in the Jira environment. This includes basic user transactions initiated from Jira or a linked tool. These are typically the following.
Link creation/destruction → Artifact retreival (GET), Artifact modification, Artifact update (PUT)
Compact (link title update) → Artifact small retrieval (GET)
Rich Hover → Artifact HTML formatted Preview (GET)
Link artifact target selection → Interactive embedded iFrame with filter request and paging response
Transactions are lightly loaded and triggered by user interaction.
Potential High Loads
Higher loads can be observed occasionally, not on a single transaction, but as an automated series of high-volume transactions. These are formulated into two forms.
TRS Feed Retrevials - IBM ELM relies on monitoring a feed for all items and their updates. It will retrieve updates on changes. If a large number of artifacts are modified in Jira and/or it is the initialization of a large project with OSLC links, we can get a transient point where IBM will request information to large numbers of resources. These are small transactions but can number 10-100k transactions. We do not see a degradation in Jira performance in these situations, but there can be enterprise effects to observing or throttling these transactions.
Custom OSLC API Applications - If an organization uses the OSLC API, they may be attempting bulk updates of artifacts. They should be aware of the volume and rate they are doing these transactions. These transactions tend to be small and low but can be subject to enterprise throttles that may change performance (usually of the user-created application and not Jira).
Enterprise Failure Modes
OSLC Applications have natural and predictable failure modes and recoveries.
Jira Down/Unavailable
If Jira is unavailable, then all OSLC services used by foreign tools will be disabled. As a user, a foreign tool, such as IBM DNG, would not search or create a link. In addition, all OSLC enablement such as logins, title updates, and rich previews will also be unavailable. You will see a service unavailable experience.
OSLC Connect for Jira Disabled (by Admin or by License)
If OSLC Connect for Jira is disabled, a similar experience to Jira Down from foreign tools will be experienced. However, the link navigation from the foreign tools to Jira will still perform.
The Jira experience will be reduced with the plugin disabled as no services for linking, preview, or update will be available for users to perform.
Foreign Tool Down/Unavailable
If a Friended tool is unavailable, then any OSLC services to that tool will be unavailable. There will be no login, title updates, or rich previews available to that tool. As well all object and link creation will not be available. Link data within Jira will persist.
Jira Database Resources
All link information is stored in the Jira database. When Jira information is restored, OSLC links in Jira will be the version from that restoration point in Jira.
Product Updates and Patches
The OSLC Connect for Jira product is updated quarterly. Updates are available from the Atlassian Marketplace (https://marketplace.atlassian.com/apps/1221984/oslc-connect-for-jira?hosting=server&tab=overview) or the SodiusWillert Download Portal (OSLC Connect for Jira Download Links)
Product Patches
Product patches may be issued between quarterly releases to address critical issues. Availability of patches will be in the marketplace or download portal.
Jira Configurations
Jira configurations may enhance or limit OSLC operation. The following are basic guidance or discussion points with your enterprise.
Content Security Policy
Your application server may implement some security policies. Common to this are the content-security-policy headers for allowing the embedding of content. It is recommended that you review our OSLC & Security guidance here → OSLC & Security. We recommend the review of how to configure your CSP headers if you are using them → Content Security Policy Recommendations with OSLC. The goal is to limit the embedding behavior between Friended repositories. If we don’t allow any embedding of content, then the engagement between applications will be non-functional.
For any mix of public/private clouds, we encourage security reviews of any setting changes.
Same site Cookies
It is advisable to review our same site guidance → Embedded Content or Authentication Isn't Working between OSLC Applications to enable cross-domain collaboration. In cross-domain situations, login tokens must be available in a 3rd party mode to enable the usage of OSLC services.
Application Server/Jira Server Configurations
It is available to Jira admins in later versions to control how requests are handled. These services can be utilized but understand they can have an impact on OSLC performance. Following is a guide to some changes in the normal load balancer behavior that could impact your environment.
Traffic Distribution
Traffic distribution (https://confluence.atlassian.com/enterprise/traffic-distribution-with-atlassian-data-center-895912660.html#:~:text=Traffic%20shaping,-While%20standard%20operation&text=Traffic%20shaping%20allows%20you%20to,specific%20node%20in%20your%20cluster. ) is a way to manage loads of particular services or capabilities in Jira DC. Unfortunately, this feature is currently not supported by OSLC Connect plugins.
Rate Limiting
Rate limiting (https://confluence.atlassian.com/adminjiraserver/improving-instance-stability-with-rate-limiting-983794911.html ) is a way to control the behavior of remote nodes (or individuals) based on how many requests (or density of requests) coming to the server. Rate limiting is not normally an issue with OSLC Connect for Jira. The situation where we have seen impact in the TRS requests from IBM LQE when a large number of artifacts have changed or the user triggers a re-indexing event. This is due to IBM behavior when throttled has inconsistent recovery mechanisms. The recommendation that any throttle for this situation come from IBM LQE/LDX rather than on the Jira side. If you are using rate limiting, please contact our support for more discussions.
Header Manipulation
In some instances, a customer may have network appliances (such as proxies) that manipulate/filter request headers. We have seen adverse effects on authentication behaviors when this occurs and generally discourage the practice of manipulating headers, except when done by the features available in our OSLC Connect plugins, such as the Security feature.