Requirements

• Admin in Exchange
• ADFS 2.0+
• Advanced Authentication + User Management

Table of Contents

• Configuring SAML in Robin
• Configuring Robin in ADFS
  • Option 1: Powershell
  • Option 2: Manual
• Troubleshooting
  • How to get SAML logs from ADFS
  • InvalidNameIDPolicy

---

Robin supports ADFS (Active Directory) single sign-on via SAML 2.0, which is available on ADFS version 2.0 and above. For general questions about SAML support, you may find this guide helpful. Keep in mind that SAML authentication is available for organizations on Enterprise plans.

Don't worry if any of the fields below are different than your default ADFS claims. You can use transform rules inside of ADFS to make sure the right format is sent back to Robin. You will not have to change anything on the service provider side to make this work. We've written this guide using the most likely defaults, so don't panic if your configuration looks slightly different.

Adding your ADFS identity provider to Robin

1. As an administrator, go to Manage > Integrations and scroll down to the Authentication methods to find an option for SAML SSO.

2. Click Add.

3.  This opens the configuration options:

We will set up ADFS as a "Custom" type. Based on defaults for ADFS installs, the configuration options in Robin should be:

• SAML SSO URL: https://yourdomain.com/adfs/ls
• Identity Provider Issuer: https://yourdomain.com/adfs/services/trust

You can confirm your server's Federation Service Properties by right clicking the "Services" folder on ADFS, then "Edit Federation Service Properties". If you do not see this option, make sure you're on ADFS version 2.0 or higher, as ADFS 1.0 does not support SAML 2.0.

 

This guide will walk you through how to get the certificate from ADFS a bit later, for now you will need to expand Advanced Options and update two fields:

• Uncheck Encrypt Assertion
• Make sure to check "Windows" under Auth Context. You may leave "Password Protected Transport" enabled as well.

The end result should look something like this:

You can complete the rest of this set up via Powershell or manually through your ADFS management console.

Option 1: Powershell

Add-ADFSRelyingPartyTrust -Name "Robin Powered" -Identifier "https://robinpowered.com"

Import-Clixml "FULL PATH TO DOWNLOADED TRUST CLAIMS XML" | foreach-object {$samlEndpoints = foreach ($endpoint in $_.SamlEndpoints){New-ADFSSamlEndpoint -Protocol $endpoint.Protocol -Uri $endpoint.Location -Binding $endpoint.Binding -IsDefault $endpoint.IsDefault -Index $endpoint.Index -ResponseUri $endpoint.ResponseLocation}; Set-ADFSRelyingPartyTrust -TargetName "Robin Powered" -IssuanceTransformRules $_.IssuanceTransformRules -SamlEndpoint $samlEndpoints -SignatureAlgorithm $_.SignatureAlgorithm} 

Option 2: Manual Configuration

We'll use the AD FS management console to first add a new Relying Party Trust for Robin, then update the claims to include user attributes required for successfully SAML authentication.

Adding Robin as a Relying Party Trust

From the AD FS management console's Actions panel, select Add Relying Party Trust to open the set up wizard.

Select Enter data about the relying party manually.

Add a display name you'll recognize, like "Robin" or "Robin Powered," then click Next.

Select AD FS Profile, and then skip the next step. We will not need token encryption for this set up.

Select Enable support for the SAML 2.0 WebSSO protocol and enter: https://dashboard.robinpowered.com/sso/saml/custom as the relying party URL.

Enter https://robinpowered.com as the Entity ID.

Select Permit all users to access this relying party.

Once you've confirmed the settings are correct, you can save and close the wizard. With the trust for Robin created in AD, we'll need to update claims before connecting via SAML.

Adding Claims

Right click the trust created in the last section, and select Properties.

Under the Advanced tab, confirm the signature algorithm is set to SHA-256. Close the window when you're done.

Right click the trust created for Robin again, and select Edit Claims.

In the new window, open the Issuance Transform Rules tab and click Add Rule > Send LDAP Attributes as Claims

Enter a Claim rule name you'll recognize (e.g. "Robin SAML Attributes") and set Attribute store to Active Directory. Map the LDAP attributes to the Outgoing Claim Types listed below, keeping in mind that yours may be different (e.g. you may have email addresses stored in a different attribute).

The outgoing claim types for Robin are case-sensitive:

• Given-Name (LDAP) > "FirstName" (Outgoing Claim Type)
• Surname > "LastName"
• E-Mail-Addresses > "Email" (or whichever field you use for email)

Confirm the claims are set up properly by clicking "View Rule Language", where you should see something like this:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("FirstName", "LastName", "Email"), query = ";givenName,sn,mail;{0}", param = c.Value);

Click "OK" to close the current window, then Add Rule > Transform an Incoming Claim.

Name this rule something like "Robin Name ID Transform" for easy reference, then update the following fields:

• Incoming claim type: E-Mail Address
• Outgoing claim type: Name ID
• Outgoing Name ID format: Email
• Enable Pass through all claim values

View Rule Language should now look like this:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");

Click "OK" to close the current window, then Add Rule > Send Claims Using a Custom Rule

Enter a Claim rule name you'll recognize (e.g. "Robin Email Transform") and then paste the below in as a custom rule:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"), query = ";mail;{0}", param = c.Value);

If the above transform rule leads to an InvalidNameIDPolicy, you can give this transform a try instead:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] == "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress"] => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

Copy the Certificate

Via the AD FS management console, go to Service > Certificates, right click and select View Certificate.

Under the Details tab, select Copy to File to begin the export wizard.

Select Base-64 encoded X.509 (.CER), then choose a location to save your certificate. Skip through the rest of the wizard's defaults by clicking Next or OK until complete.

Copy the contents of the certificate file you just created, and paste it into the SAML configuration within Robin. Save your configuration, and SAML should now be enabled for your account.

References

• MSDN: Use a SAML 2.0 identity provider to implement single sign-on

Troubleshooting

If you've completed the steps above and still get errors, check the ADFS logs under Event Viewer. Your configuration may be different, and the Event Viewer is the fastest way to see details about the error shown to Robin. We have a complete guide for ADFS log hunting available here.