Active Directory Federation Services is a standards-based service that allows the secure sharing of identity information between trusted business partners. ScatterSpoke supports single sign on with AD FS which means your organization can easily incorporate ScatterSpoke into your application base in AD FS. This allows you to control which users consume a seat of your Enterprise license so they can securely access ScatterSpoke.

For general information about ScatterSpoke Single Sign-On feature, refer to the Single Sign-On with ScatterSpoke document. This document describes the specific instructions you can use to integrate your AD FS with ScatterSpoke SSO.

Prerequisites

  • Relying party SAML 2.0 service url
  • Relying party trust identifier

Identity Provider Setup

Relying Party Trust

To configure Single Sign-On integration between your Active Directory Federation Services and ScatterSpoke accounts, you will need to configure AD FS to add a relying party trust.

To add a relying party of trust open the AD FS tool, expand trust relationships, select relying party trusts, and click add relying party trust.  This should open up the add relying party trust wizard. Enter the following details in the next few prompts:

Display Name: ScatterSpoke
Profile: AD FS profile
Certificate: Default

You should now be on the configure url screen. From here, select Enable support for the SAML 2.0 WebSSO protocol. ScatterSpoke will provide you with the Relying party SAML 2.0 service url. Click next.

On the next screen you add the Relying party trust identifier that ScatterSpoke provides to you during account setup.  Make sure to hit add before clicking next.

The rest of the prompts can use the default settings:

Multi-factor Authentication: I do not want to configure multi-factor authentication settings for this relying party trust at this time
Issue Authorization Rules: Permit all users to access this relying party

From there, click next on Ready to add trust, and then close.   

Editing Claim Rules for the Relying Party Trust

Next you need to edit the claim rules for the relying party trust that you just added. Right click on it, and select Edit Claim Rules.

Click Add Rule and select Send LDAP Attributes as Claims as Claim rule template. Add a claim rule name, we suggest Get EmailAddress but it can be whatever you'd like.  Next select select Active Directory as Attribute store. Under the LDAP mapping section; select E-Mail-Addresses as the LDAP Attribute and select E-Mail Address as the Outgoing Claim Type from the drop-down lists. Click Finish.

In order to create a ScatterSpoke account, we need to enable sending the active directory user's email address to map it in the SAML response. Click Add Rule again. Choose Transform an Incoming Claim and click Next. Give a name for Claim rule name. Select E-Mail Address as Incoming claim type, Name ID as Outgoing claim type and Email as Outgoing name ID format from the drop-down lists. Make sure that "Pass through all claim values" is selected. Click Finish.

Export Certificate

The last part of setting up AD FS is exporting the x.509 certificate for ScatterSpoke. This important step helps keep the trust relationship secure between ScatterSpoke and the identity provider.

Select AD FS, services, certificates in the AD FS management tool. Right click on token signing then view certificate. Switch to the details tab and click copy to file. Choose DER encoded binary X.509(.CER) as the format, select a destination and click finish. 

ScatterSpoke requires the certificate to be in PEM format. Using openssl you can run the following command to covert the certificate:

openssl x509 -inform der -in certificate_in_name.cer -out certificate_out_name.pem

Wrapping Up

To finish up the AD FS integration you need to provide ScatterSpoke with the following:

  • SAML 2.0 Endpoint: This is the public facing SAML endpoint exposed from the setup we followed above.
  • x.509 Certificate: This is the certificate exported above in PEM format

Though not necessary, it's helpful to also to provide ScatterSpoke with a test account to verify the integration.

Did this answer your question?