Hi Jamie,

Service Provider metadata files should indeed be generated at Skyline.

The contents of this file vary from customer to customer and depend on the IdP metadata and their internal setup.

Here's why (you can skip to TLDR too):

The image above represents the HTTP exchange that occurs between each participant during a SSO. In our case the Service Provider is DataMiner. When not using the HTML5 apps, CUBE assumes the role of the browser.

However, SP and IdP are distinct independent systems. In order to be able to talk to each other, they have to establish a trust relationship.
This is achieved with the metadata files, where each file describes their entity configuration, so that a basis for communication can be found.

This is an SP metadata example similar to one deployed at one of our customers:

The important settings are:

EntityID - The identifier name for the Service Provider (the IdP looks at this to distinguish between talking to multiple SPs).
AuthnRequestsSigned - Whether the SAML requests made by DataMiner should be signed.
WantAssertionsSigned - Whether DataMiner wants the received SAML assertions to be signed by the IdP.
AssertionConsumerService - The endpoint(s) address at the Service Provide (DMA) to where the IdP will send its assertions.

TLDR:

With minimal SSO and SAML knowledge, the deployer or account manager heading the configuration should be able to easily compose an SP Metadata file which complies with both DataMiner and the IdP supported configurations.

There are good service provider metadata generator tools that can be used, i.e. https://www.samltool.com/sp_metadata.php

Alternatively these can be created manually too. The example above serves already as a reasonable template.

Remarks regarding configuration support:

• Does not support Signing of AuthnRequest message but it's coming soon.
• Only asymmetric algorithms for digital signatures are supported for now (ex RSA).

Finally, there will be SAML explained/tutorial videos coming up soon here on Dojo. So keep an eye out.