OSLC & Security
The OSLC standard is a secure way for your environments to integrate and collaborate. Occasionally, comprehensive IT standards can conflict with the way OSLC collaborates. This because many of these internal standards broadly exclude server to server collaboration as allowable. The net result is that browsers will enforce security rules provided by either your proxies or web application servers that prevent normal OSLC collaboration.
The Basics of OSLC
OSLC has two important features when discussing browser security.
Authentication (Oauth)
OAuth is an authentication protocol that allows us to delegate authentication for a user between servers without sharing passwords. In the simplest sense, we can authenticate directly to one server, which will provide an authorization token that allows access to the content on behalf of you on another server. In the form of cookies, these tokens allow us to use data from one site in another site with our specific identity. For example, this is how in DOORS Next, I can access Jira content in a rich preview with a complete and auditable path. And critically, I never share my Jira user password with DOORS Next.
Practically, as a user, you can see this when you want to access the content; you see a login prompt on a link within Jira.
And when you click login, the Jira triggers the source tool to provide a login prompt to verify your identity and then provide the Oauth token for Jira’s usage on your behalf.
After that first Oauth “dance,” you will have a token for that web-session that allows the source tool (in this case, Jira) to access DOORS data with your user id and permission model, but without sharing your DOORS password with Jira.
It is secure and it is safe.
Delegated dialogs (iframes)
Delegated dialogs are how we provide the integrated experience in OSLC tools. OSLC, and the web, provide the flexible ability to embed content from one site into another. This is how in Jira I can open a Test Case selection dialog (picker) from ETM, or in Polarion how I can leverage the Jira creation dialog. These smooth integrations are based on iframes where the content is sourced from another server. Consider that a tool like Jira creates an iframe and then embeds the contents from DOORS. As a user, you get a smooth and integrated experience with this web technique.
As a user, you see this very subtly. For example, when in Polarion, if I attempt to create a Jira artifact. I remain within the Polarion tool, but embedded in a Polarion popup is content from Jira.
This is a great example where Polarion provides the opportunity to embed content, and then Jira provides the content all negotiated through the OSLC Standard. This means these frames expand and contract to meet the provider's needs and result in a smooth user interface.
We see similar content when in Jira, and we want to link an artifact to a test case. In this case, Jira is the host of the content, and it embeds content from ETM all in the context of your user without leaving the context of Jira.
The same usage of web patterns is used for the ubiquitous “rich hovers” that provide a preview of the other tool's contents. In the below situation, we can view a preview from DOORS Next while in Jira, eliminating extra navigation and giving users seamless access between tooling.
The ability to use these techniques is what makes OSLC a great tool integration technology between tools. It embeds behaviors, provides users seamless navigation, and provides flexible integration points where the source tool invokes, but the target tool provides the content.
How Aggressive Security Breaks OSLC
The above behavior is what we expect from OSLC using these critical web technologies. Unfortunately, many of the great web features that we use for OSLC can be perceived as security issues. Most standard penetration tests are focused on the malicious usage of these techniques. These security tests avoid scenarios with valid server-to-server interactions. If an environment doesn’t expect server-to-server interaction, then standard security patterns will break the OSLC chain. Standard corporate security rules prohibit server embedding of content from another site.
These security patterns are implemented in the network devices such as the web application servers (that would host tools like Jira or ELM) and/or on a proxy/load balancer sitting in front of these web applications.
What is unique about OSLC is that their embedded behavior is not random, it is planned and expected. Friending between servers is specifically about what servers we want to interact with and trust each other.
Below we describe the most common observed security rules that impact OSLC performance.
Don’t share the cookies
A recently identified issue for browser security is to prevent the sharing of cookies between servers on different domains. While this does appear to be a reasonable action, this behavior will now prevent sharing your authentication tokens between servers and disabling that Oauth path to complete the authorization between servers on your behalf. The providers of these cookies can be explicit and indicate that they can be shared, but this requires a change in your web application to make sure this happens.
A basic explanation of what is happening and why it is happening can be found here → https://web.dev/samesite-cookies-explained/.
For OSLC to work, some cookies will need to be shared. The common appearance of this issue can be authentication prompts reappearing/flashing. More details and resolutions can be found here → Embedded Content or Authentication Isn't Working between OSLC Applications or a video demonstrating the issue and resolution → Understanding Multidomain Architectures Issues.
Prevent Embedding Content
The common concern with iframes around security is the same reason why it is so valuable to OSLC. What iframes allow, from the user perspective, is embedded content that feels like we have never left the current site. We wouldn’t want undesired content embedded in your web page because it can be a security hole that a user overlooks. They know what website they went to, so they expect all content that they see is both safe and valid, whereas the embedded content could ask, for example, for user information maliciously.
There are two behaviors that web developers can demand from their served content to manage these behaviors. First, a web-fragment can demand that it restricts what sites it can be embedded in. Second, a web-fragment can demand what sites it can embed from. These rules can be enacted directly by the application or by the later configuration of the web-server or a proxy device.
The goal of security teams is to limit malicious behavior. One of the ways they do this is to use these techniques to broadly limit the embedding of content. They activate these features on the web applications and proxies to limit all server-to-server interaction that is cross-site. This is effective for basic security when no cross-server interaction is expected. The browser will enforce these rules, and embedded dialogs will no longer be rendered.
For OSLC to work, we must allow the embedding of content. This is done either by
Preventing the use of these headers (less secure but in private networks, this is not an issue)
Specifically using these headers to allow from specific domains and disallow others (most secure but challenging to deliver)
What is good about OSLC is that with the definition of Friends (collaborating servers), we know which servers should be allowed to interact and collaborate. It is then up to the configuration of allowing the interactions between these friends and limiting interactions between other servers.
The common ways to enact these policies (prohibiting and enabling interaction) are X-Frame-Options and Content-Security-Policy. You can find more details about them both below.
X-Frame-Options. This is an older technology, mostly targeting Internet Explorer, but commonly found in security guidelines. It is difficult to configure, and we custom guide usage when required (and recommendation not to use).
Content-Security-Policy. This is the current technology that provides significantly more flexibility. This includes where embedded and what can be embedded in different configurations. It provides a much simpler description to execute well, and we do recommend its usage in security-conscious environments, and recommendations can be found here → Content Security Policy Recommendations with OSLC .
Summary
OSLC by design is secure. The methods and technologies of collaborating are sound and flexible. However, as security guidance changes, we must be more explicit in how we want our web applications to behave and how we want our servers to operate. The best answer is to understand your topology and follow the guidance above on how to balance the collaborative nature of OSLC with security configurations that specifically enable their collaboration (and disallow others). It is only when we configure our servers not to communicate that we have issues with OSLC. An OSLC architecture and security guide is a necessity for every enterprise.