OSLC Architecture Recommendations

Enterprise architectures are more complex than ever. Some will use private clouds they manage. Some will use Cloud provider solutions and just manage their own service in a move to IAAS or PAAS. Some will prefer leveraging the skills of dedicated SAAS providers and rely on their expertise to only focus on how to use tools rather than on how to administer them.

And more than often, one will use a mix of these options.

Setting up the digital thread, through enabling OSLC in the Enterprise, can sometimes be challenging because of these very topologies.

We will discuss below the minimal requirements, the default and recommended architecture, the various more complex architectures we support, as well their strengths and potential weeknesses. We’ll then review the ways to overcome those.

General Requirements

Minimal Requirements (MUST)

Servers MUST be discoverable

That is a very basic requirement for an OSLC Enterprise Architecture, as much as your end-users need to be able to reach the servers hosting the OSLC Applications, those servers need to be able to communicate with each other.

So the DNS configuration needs to be correctly set up for them to communicate both ways. This may sometimes require your IT team opening some specific routes in addition to the configuration of the DNS itself.

Last but not least, this also means the required ports on firewalls of each servers will have to be opened.

Servers MUST use their public server name

OSLC interactions notably offer means to create links between your OSLC Applications. When you create a link, the URL of the link is directly related to the URL of the remote application. As a consequence, it is recommended that your server’s public name is always used.

This first means: never use an IP address. Ever. The IP address of your server might not even be static, so every link you created would just be lost when your server receives a new IP lease from the DHCP server.

This also means you should always prefer using their Fully Qualified Domain Name (FQDN). A server always exists inside a network, and the combination of both makes up the FQDN.

server + domain = FQDN

oslc-app-a + example.com = oslc-app-a.example.com

This is because on a given network, the FQDN is the full name that uniquely identifies a server, and as such will more easily traverse the various networks of an enterprise deployment.

Servers MUST use valid certificates

For the proper behavior of OSLC interactions, HTTPS must be enabled. This means that all servers must have certificates. These certificates must be valid and generated by a legitimate Certificate Authority. You may get some level of feature, at some point, with self-signed certificates. Still, it’s highly discouraged to use those since browser’s security measures tend to consider those more and more like invalid certificates, which may block OSLC interactions.

Authentication

In an OSLC Application, resources are protected (with the exception of base discovery services). As a consequence, when querying for resources, authentication will occur. In rare cases, the authentication process will fail due to incompatibility with a custom sign-on extension.

Additional recommendations (SHOULD)

OSLC Applications SHOULD be under a single private domain

For the reminder to what private domain means, please review Understanding OSLC Architectures > Simple is best.

OSLC interactions occur both at the server level, and at the browser level. In that second context, browsers have seen major security enhancements over what was previously possible. Since OSLC interactions occur between two applications, browsers will consider them to be safe by default if and only if both applications are on the same private domain. Typically, you will consider everything below example.com to be ok. But sometimes, when deploying on different infrastructures, you can end up with multiple domains for your applications, such as oslc-app-a.example.com and oslc-app-b.example.cloud. Same when leveraging a third-party SAAS provider, with applications servers such as oslc-app-a.example.com and oslc-app-b.thirdparty.com. In both those cases, the browsers will prevent OSLC interactions by default and we’ll need to go through setting up a few security measures to keep our OSLC Enterprise Architecture relevant.

The major impact of using different domains for your OSLC Applications is that it requires specifying what is known as SameSite with the value None. You can dive into more details around SameSite at Auth0. This is a little security drawback, so we’ll see further down how we can either strictly limit the impact or just simply avoid it.

OSLC Applications SHOULD live behind a reverse proxy

Reverse proxies provide great flexibility in a deployment, notably into setting specific security headers, and enabling easy migration. That will be the default for some applications. For those where it is not the case, you should set up one.

OSLC Applications SHOULD share the user directory

Since multiple OSLC Applications are always involved, it’s better having those share the same user directory.

Architectures

Below architectures are listed in a growing complexity sorting strategy.

Recommended Architecture

Single Cloud Enterprise Architecture

OSLC Applications A and B are hosted together and managed by the same entity (either the Enterprise or a third-party).

This topology is the most common, as well as the most secure one. OSLC Applications are located in the same infrastructure, and on the same network. Even if named in 2 different sub-nets, this topology would keep its best-in-class properties of being in the same cloud solution, and overall network.

Supported Complex Architecture

Mixed Cloud Enterprise Architecture

OSLC Applications A and B are hosted separately, yet managed by the same entity (either the Enterprise or a third-party).

When devising their infrastructure, some customers will go for a mixed-cloud solution. Part of their infrastructure will be in an IT-managed infrastructure, and part of it will be hosted at a Cloud provider of their choice. This kind of split typically means that both OSLC Applications won’t be hosted on the same domain. Two situations can happen as detailed in the table below.

Semi-SAAS Enterprise Architecture

OSLC Application A is hosted and managed by the Enterprise whereas OSLC Application B is hosted and managed by a third-party provider (SAAS).

Leveraging the expertise of a third-party SAAS provider is often a choice from companies, including those wanting to make use of OSLC Applications. All providers we know of offer those services on their own private domain, which is necessarily different from the company’s private domain.

Full SAAS Enterprise Architecture

Both OSLC Applications A and B are hosted and managed by different third-party providers.

Same as in the Semi SAAS Enterprise Architecture, leveraging a third party that will use its own domain to provide you with a service for an OSLC Application implies some configurations.