Single Sign-On with SAML on BOARD

Document created by arocchietti Employee on Aug 4, 2017Last modified by andreamo on Nov 13, 2019
Version 4Show Document
  • View in full screen mode
Identity management is becoming a major concern for businesses. Implementing a Single Sign-On (SSO) infrastructure enables users to sign in once and have access to all authorized resources.
In this article, we'll look at the different methods of implementing SSO with BOARD, how to set up your own identity management system for federated authentication using SAML 2.0, and how to configure BOARD to utilize your new identify provider. 





Federated authentication does not validate the user's actual password on BOARD platform either. Instead, the platform receives a SAML assertion in an HTTP POST request. The SAML assertion has a limited validity period, contains a unique identifier, and is digitally signed. If the assertion is still within its validity period, has an identifier that has not been used before, and has a valid signature from a trusted identity provider, the user is granted access to the application. If the assertion fails validation for any reason, the user is informed that their credentials are invalid. The rest of this article shows how to set this up.

Security Assertion Markup Language (SAML) provides a secure, XML-based solution for exchanging user security information between an identity provider (your company) and a service provider (BOARD).

There are three roles involved in a SAML transaction:

  • an identity provider (the asserting party),
  • a service provider (the relying party relying on the assertion), and
  • a user (the subject of the assertion).

The identity provider is the authority system that provides the user information. We will be setting up our identity provider shortly. The service provider is the system, in this case BOARD, that trusts the identity provider's user information, and uses the data to provide access to the service or application. The user and their identity combined are known as the subject.

The transaction from your identity provider to BOARD is called a SAML assertion. BOARD assumes that all data contained in the assertion from your identity provider is valid. The structure of the SAML assertion is defined by an XML schema that is specified by the OASIS SAML standard and contains header information, the subject and statements about the subject in the form of attributes and conditions such as a start and logout URL. In our examples, our SAML assertions will contain a Username from the identity provider which is guaranteed to be unique.

There are two important use cases for SAML: Identity Provider Initiated Login, where a user starts directly at their identity provider, logs in, and is then redirected to a landing page at the service provider; and Service Provider Initiated Login, where a user starts by clicking a link to the the service provider (e.g. a bookmark, mailed link, etc) and temporarily redirected to the identity provider for authentication, then returned to the link they initially requested. BOARD supports both of these use cases.

There are a number of identity solutions that support federated authentication using SAML.

In this article, our example is based on Active Directory Federation Services (ADFS 4.0) from Microsoft and BOARD cloud configuration but the same sample is applicable for on-premise environment.



Identity provider configuration

Open ADFS Management tool on the windows server where the ADFS is installed.

Go in the Relaying Party Trust folder and from action panel choose “Add Relaying Party Trust”.

Select “Claim aware” and click start.



Follow the wizard with configuration options as in the screen below:




Type any name that represent the application you are configuring. For example “BOARD Cloud”




Enable support for SAML 2.0 and  type the Url of your cloud instance as in the example below:




In the relaying party trust, add again the Url of the instance:




Set the access policy desired and click next.

Uncheck the option to configure claims, we will do that later. Click on close.





 Version previous to 10.1.2 only support SHA-1 for the hash algorithm.  If you are installing version 10.1.2 this step can be skipped and you can leave SHA-256 as default hash algorithm.

 Right click on the Relay Party trust just created and click properties. Click on advanced and choose SHA-1.



Now we have to define a claim rule. Right click on the Relay Party trust just created and click edit claim issuance policy…


Select  Send LDAP Attributes as Claims

Click on Next



Type a name for the transformation rule and choose an attribute from your Active directory that will be used as the claim type.

If the configuration that you will set, is different from the below example, please inform BOARD Cloud team about the Outgoing Claim Type chosen.



Once finished, you have to inform the BOARD support with the information related to Metadata URL.

BOARD support team will activate the service for the SSO method.

On request BOARD support can disable the standard user and password authentication method.



BOARD Web Configuration 

SAML configuration "saml2.config" file is usually located under  "C:\Program Files (x86)\Board\Board WebApi Server\App_Data\config"

By default the configuration file is empty. Below a standard configuration for MS ADFS:


<saml2configurations UseSHA256="true">
<add key="samlsso" caption="SSO Login" entityId="" modulePath="/samlsso">
<identityProvider entityId="http://myadfsserver/adfs/services/trust" loadMetadata="true" metadataUrl="https://myadfsserver/FederationMetadata/2007-06/FederationMetadata.xml" allowUnsolicitedAuthnResponse="false" />


When loadMetadata is enabled the configurations are automatically retrieved from the Identity Provider ignoring the specified configurations. In case, you don't have a metadata endpoint, then you have to specify a different configuration:


<saml2configurations UseSHA256="true">
<add key="samlsso" caption="SSO Login" entityId="" modulePath="/samlsso">
<identityProvider entityId="http://myadfsserver/adfs/services/trust" loadMetadata="false" allowUnsolicitedAuthnResponse="false" binding="HttpPost" wantAuthnRequestsSigned="false" destinationUrl="https://mysamlendpoint">
<signingCertificate fileName="C:\Board\SAML\myadfs_token_signing_certificate.cer" />


SigningCertificate tag and  filename parameter must be specified (see below how to get the Token Signing Certificate).

Destination URL parameter must be specified and is the endpoint which the Service Provider (BOARD) will send the auth requests.


Specify a different claim type:

By default, the claim type used to identify the person is “name”. Otherwise, you can specify a different type using the incomingClaimType attribute.


<add key="samlsso" ... incomingClaimType="username">




In BOARD CLOUD environment this configuration is done by the Cloud Operation Team 

IdP initiated configuration

If an IdP initiated SSO login is required an additional configuration must be done on IdP side as well as on the XML configuration file.

Start with determining the Assertion Consumer URL of the service provider (BOARD) that is usually composed in this way:


Modify the IdP endpoint in the following way by adding a SAML endpoint with Artifact binding:





Modify the XML BOARD SAML configuration and add/set the parameter allowUnsolicitedAuthnResponse = "true"


<saml2configurations> <add key="samlsso" ...allowUnsolicitedAuthnResponse="true"... </add></saml2configurations>



BOARD Server Configuration


If SAML SSO need to be used for authentication with BOARD Client, an additional configuration must be created using the SAMLConfiguration tool. The tool (SAMLConfig.exe) is usually located under "C:\Program Files\Board\Board Server" and will create an xml file used by the BOARD server to enable this kind of authentication method.


Please note that for this configuration we need to specify and load the Token Signing Certificate that you need to export from ADFS server.

In the AD FS 2.0 MMC snap-in select the certificates node and double click the token-signing certificate to view it.


Click the 'Details' tab then 'Copy to File'. Save the certificate in DER format. Then save the file under BOARD server installation folder and load it with SAMLConfigurationTool.
Restart the BOARD Server to apply the configuration.

In BOARD CLOUD environment this configuration is done by the Cloud Operation Team 




BOARD Client Configuration


To perform a SAML SSO connection with BOARD Client, create a new connection and specify SAML by ticking the option.


7 people found this helpful