Enabling single sign-on via ADFS


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

Table of Contents

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. 2023-10-11_15-01-50.png

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.



Check your Issuer URL

Make sure to confirm your ADFS server's Issuer URL, since some will send http://yourdomain.com instead of https://yourdomain.com. If this is different from the configuration you set in Robin, we won't be able to match incoming requests to your account. You can fix this by updating the URL in Robin to match the actual issuer sent by your identity provider.

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:

ADFS SAML Configuration

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

Option 1: Powershell

You'll need to download this first RelyingPartyTrustClaimRules.xml

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.

Add a trust party wizard

Select Enter data about the relying party manually.

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

Display name for relying trust party

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.

Add your SSO URL for Robin

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

Robin 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.

SHA 265 for SAML

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)

AD FS Claim to SAML Attribute mapping

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

Map Name ID to email

Troubleshooting InvalidNameIDPolicy

If you've followed these steps and still can't log in successfully, check your Event Viewer logs in ADFS for extra information. If you see messages like "Actual NameID properties: null" in the response, it means the email address wasn't found with the attribute mapping above.

Depending on your configuration, you may need to change the "Incoming claim type" to Windows account name. The NameID is a required field, and InvalidNameIDPolicy errors generally mean ADFS is unable to find a matching field for "Email".


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.

View certificate in ADFS

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.



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.


Did this article help?