The Security page is meant to:

• help resolve some of the communication challenges that may arise in certain complex OSLC Architectures
• provide additional security layers by offering to limit the communication only to registered servers.

These features can be used independently.

Sharing Cookies

In certain complex OSLC Architectures, OSLC Applications are hosted on different domains such as example.com and example.cloud. This introduces a security challenge when working with OSLC, which requires cross-site authentication. This is known as Cross-Site Request Forgery, or CSRF / XSRF. CSRF can be mitigated at two levels. First in the API through appropriate development practices, which we thrive to follow. Then in the browser, by restricting cross-site authentication through limiting cookie sharing practices. This is also known as "SameSite cookies".

For certain applications, such practice may just be to "share all my application's cookies". In ${local-app}, the decision was made to open only what was absolutely required to allow for OSLC interactions. And to open only when the request is from a Whitelisted server.

By enabling Sharing cookies, you allow ${local-app} to share the specific cookies listed under Shared cookies, only when authentication happens from a Whitelisted server.

To avoid any performance impact, this has been configured to only happen at specific authentication points. As a consequence, when your application is configured to leverage non-default authentication, or a custom login page, there is a possibility that the default configuration is not sufficient to enable the feature. In that case, you are recommended to enable the additional configuration toggle regarding advanced login solutions.

Listing a new shared cookie

In even more complex Architectures, e.g. with Single-Sign-On implementations, default Shared cookies might not be enough. In that case, you may set specific cookies through the Shared cookies list:

1. Type in the name of the cookie to share in the textfield with the placeholder New Shared Cookie
2. Click the Add button.

If everything went OK, your cookie will now be listed in the Sharing cookies table. You will need to logout then log in again for this new setting to be fully effective in your current session.

Stop sharing cookie

When your OSLC Architecture changes, you might want to unlist one or more cookies from the Shared cookies list.

1. Choose the shared cookie you want to delete and click on the delete icon located on the last column of the table.
2. Confirm your decision by clicking on the OK button in the confirmation dialog.

If everything went OK, the chosen shared cookie will no longer appear on the Sharing cookies table. You will need to logout then log in again for this new setting to be fully effective in your current session.

Outgoing

When considering communication between servers, you can choose to restrict which servers you allow including content from.

By enabling Outgoing, all pages allowing to create a link will be appended the child-src CSP directive. That directive will be set to allow all Friend servers.

Since your application may include content from more than just OSLC remote applications, you should only consider enabling this if no other plugins are including external content inside iframes.

Incoming

When considering communication between servers, you can choose to restrict which servers are allowed to include your OSLC content.

By enabling Incoming, all OSLC delegated content (dialogs, previews) requests will be appended the frame-ancestors CSP directive. This directive will be set to allow only whitelisted servers.

If other plugins are displaying your data in third-party applications, you may need to add those servers to the Whitelist.

Whitelisting Servers

When restricting incoming communications, you are always restricting to the whitelisted servers. The whitelist is the addition of two sets of servers:

• the servers that are listed as friends: friends are meant to list servers whose data you want to include in your application. Still, since OSLC communications are most often bi-directional, we offer to consider these friends as the servers you allow including data from. When the Include friends to the whitelist setting is enabled, the server is considering all existing friends as a whitelisted server. It is enabled by default.
  when enabled, friend servers are listed as tags on the line below the checkbox.

• the whitelist table: additional servers may need to be whitelisted for their application to be allowed to consume data from this OSLC application. This is particularly true of reporting or even indexing, servers.
  • To add a server to the whitelist:
    1. Type in the URL of the server to whitelist in the textfield with the placeholder New Whitelisted Server URL, including the protocol and port if it's not the default port
    2. Click the Add button.
  • To delete a whitelisted server:
    1. Choose the whitelisted server you want to delete and click on the delete icon located on the last column of the table.
    2. Confirm your decision by clicking on the OK button in the confirmation dialog.

Validating SSL Certificate Chain

By default, the Validating SSL Certificate Chain setting is enabled, meaning that certificates not signed by a publicly trusted certificate authority will be automatically rejected.

You may disable this option if your instance needs to communicate with a server using a self-signed certificate. That should be reserved to staging environments and remain temporary.