Skip to main content
Skip table of contents

Understanding OSLC Architecture

When preparing to deploy OSLC Connect for Jira or OSLC Connect for Confluence, you need to consider the overall OSLC Architecture that you are going to set up.

What is an OSLC Architecture?

An OSLC Architecture is made of:

  • the various OSLC-enabled applications, and their public URI;

  • and whether you wish to have any kind of links created between those.

You might end up with something similar to the below:

Formalizing your OSLC Architecture will help you:

  • identify possible drawbacks of such architecture and decide for improvements or mitigation strategies;

  • prepare the traceability model for your projects;

  • determine how the IT must open the network for these server to server communications to be possible.

Understanding OSLC Architectures

Simple is best!

If we were to pick only one characteristic to describe an OSLC Architecture, which would make it either good or complex, it would be the combination of domains used among this architecture:

  • relying on a single private domain makes the architecture more secure;

  • relying on multiple private domains requires either updating or further securing the architecture.

To clarify the “private domain”, let’s break it down to a simple rule.

Considering .com, .net, .org, etc. are top-level domains, a private domain is whatever 2nd-level domain you can think of. With an example very close to us, sodius.com, willert.de, and sodiuswillert.com all are private domains. And the best OSLC architecture, to remain both simple and secure, will settle on using a single one of those!

Note that adding more levels (simply put: more .!) to the domain doesn’t change the corresponding private domain: both jira.demo.sodiuswillert.com and confluence.test.sodiuswillert.com are on the sodiuswillert.com private domain.

Limitations to that best scenario

Having an application in this architecture with a base URL being the server name, rather than the Fully Qualified Domain Name (FQDN), e.g. https://jira:8443/ rather than https://jira.sodiuswillert.com:8443/, means that you are using 2 domains: jira, and sodiuswillert.com.

As a consequence, we recommend all applications be exposed through their FQDN.

Down to the details

We have written a detailed article on what you should be considering when setting up your OSLC Architecture. This will give you all the details you need, now that you know more about what an OSLC Architecture is.

Some checks before moving on…

Check your Applications' FQDN are OSLC friendly

The two applications must not share the same FQDN and port (see: OSLC Connect for Jira, Known Limitations).

Note that even though they should not share the same FQDN and port, you can still have them on the same FQDN, but on different ports. It’s even highly preferred to have them on the same domain. Having your applications on different domains brings Samesite Cookies issues.

Since version 2.8.0 of OSLC Connect for Jira, the plugin comes with a Security configuration that handles these issues. You may want to read the Security page documentation for additional details.

Following the image above, you could have a different hostname for each application, but it’s recommended to use the same domain.

For example:

Check your server has valid certificates

Your applications must use HTTPS with a valid certificate.

You can check that by looking at the lock icon standing next to the website’s URL when you are visiting your OSLC applications. If there is a warning or an open lock, it means the site is not secure. If there is a green or closed lock, it means the site is secure.

Related documentation:

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.

Contact Support Close