SAML v2 Single Sign-On (SSO)

Getting Started

What is our SSO solution and how does it work?

Our SSO solution is Service Provider (SP) initiated, meaning the login process starts from our application and redirects users to their organization's Identity Provider (IdP) for authentication.

Where can I find training materials?

Training videos and materials are available on our internal training page. Additional resources include:

• Force Login training presentation
• Non-Standard authentication methods training
• General SAML v2 SSO documentation

Setup Requirements

What information do I need from the customer to set up SSO?

You need four pieces of information from the customer's Identity Provider (IdP):

1. EntityID - Unique identifier for the IdP
2. X509 certificate(s) - Security certificates (may be multiple)
3. Login URL - The IdP's authentication endpoint
4. Domain name(s) - Email domains that will use SSO exclusively

How do I obtain the required information from the customer?

There are two methods:

Method 1: Import metadata.xml file

• Request the metadata.xml file from the customer
• Import it directly into our configuration form
• The system will automatically populate the EntityID, X509 certificates, and Login URL if present in the file

Method 2: Manual extraction

• Request the metadata.xml file from the customer
• Manually extract the required information: 
  • EntityID: Found in the "EntityDescriptor" node (typically line 2)
  • X509 Certificate(s): Found in "X509Certificate" nodes (may be multiple)
  • Login URL: Found in "SingleSignOnService" node

What should I be careful about when importing XML files?

• Each XML import will overwrite previous Client Settings information
• The customer's XML file may not contain all required information - you'll need to contact them for missing data
• Look for XML nodes rather than specific line numbers, as these vary between customers
• Extract ALL X509 certificates if multiple are present

Configuration Settings

What are the two main login workflow options?

1. SAML Exclusively System-wide(Most Secure - Recommended) 
   • Check "Force all users to login through SAML"
   • All authentication goes through the IdP
2. Partial SAML Implementation 
   • Users can authenticate via SAML at login server
   • Alternative email/password login available at data center level

What authentication methods are supported?

Our SSO implementation supports 6 authentication methods by default:

• Password
• Password Protection Transport
• TLS Client
• X.509
• Integrated Windows
• Kerberos

What is "Use strict protocol" and should I enable it?

Strict protocol increases security by validating information from the IdP before processing it. It's enabled by default and recommended, though it requires slightly more setup and testing from the customer.

How do I handle multiple domains?

If the customer has multiple domains that need exclusive SSO access, separate them with commas in the domain field.

Domain and Email Restrictions

Can I use the same email domain for group and client configurations?

No. When creating a SAML configuration for a group, it cannot share the same email domain as a client configuration. Each email domain can only be used in one configuration instance.

Microsoft ADFS Specific Setup

What special considerations are there for Microsoft ADFS customers?

For Windows Active Directory Federation Services (ADFS), customers need to ensure both message and assertion are configured to be signed. They should:

1. Set up the application in their ADFS server
2. Open PowerShell on the ADFS server
3. Check current configuration with:
4. Get-AdfsRelyingPartyTrust

or for multiple applications:

Get-AdfsRelyingPartyTrust -Identifier <A_DILITRUST_APP_IDENTIFIER>

5. Verify SamlResponseSignature is set to MessageAndAssertion
6. If not, update it with:
7. Set-AdfsRelyingPartyTrust -TargetIdentifier "<A_DILITRUST_APP_IDENTIFIER>" -SamlResponseSignature "MessageAndAssertion"

What are the valid Dilitrust application identifiers for ADFS?

• dilitrust_gov_eu
• dilitrust_gov_na
• dilitrust_exec_eu
• dilitrust_exec_na
• dilitrust_dataroom_prod_eu
• dilitrust_dataroom_prod_na

Troubleshooting

The customer can't connect after setup - what should I check?

This is particularly common with Microsoft-driven IdPs, especially when combined with:

• Biometric authentication
• Hardware authentication keys
• Windows operating system

Solution steps:

1. Review training materials for non-standard authentication methods
2. Consider enabling non-standard authentication methods
3. Important: Confirm with R&D before enabling this option

What happens after I save the configuration?

Saving the changes generates specific metadata for that client. Each client has unique metadata even if configurations appear similar. Copy this metadata and forward it to the customer for their IdP setup.

The customer says some information is missing from their metadata.xml file - what do I do?

Contact the customer directly to obtain the missing information. Their XML file may not contain all the required Client Settings information.

Best Practices

What's the recommended security approach?

• Use SAML exclusively system-wide (force SAML login)
• Keep strict protocol enabled
• Ensure proper certificate validation
• Verify domain restrictions are correctly configured

How should I handle certificate management?

• Always extract and use ALL X509 certificates if multiple are present
• Verify certificates are valid and not expired
• Ensure certificates match between customer IdP and our configuration

What should I remember about metadata?

• Each client has unique metadata regardless of similar configurations
• Always provide the specific metadata generated after saving the client's configuration
• Customer must implement our metadata in their IdP setup for SSO to function properly