ADFS 3.0 and Workday Single Sign-On

This step guide has been generated to assist in the configuration of ADFS 3.0 and Workday to provide Single Sign on

Pre Requisites

  • ADFS 3.0 Infrastructure
  • ADFS Administrative Access
  • Workday Tennant
  • Workday Administrative Access

Exporting the ADFS Token Signing Certificate

In order for the 3rd party online service to trust your Active Directory Federation Service and the authentication token provided to them you must provide them with the Token signing certificate applied to your Federation Service endpoint, you can export the Token signing certificate by following the steps below.

1. Open “Server Manager” and under the “Tools” section select “AD FS Management”

2. Wait for the AD FS Management page to load and expand the “Service” folder and then select the “Certificates” folder



3. Locate and right select the “Token-signing” certificate, and select “View Certificate”


4.    On the Certificate popup, select the “Details” tab and select “Copy to File

5.    On the “Welcome to the Certificate Export Wizard” select “Next”

6.    On the “Certificate Export Wizard” page select “DER encoded binary X.509 (.CER)” for the format

7.    Specify a path and name for the exported file and select “Next”,

8.   On the “Completing the Certificate Export Wizard Page” verify you are not exporting the private key and select “Finish”




Note:    The Token signing certificate is a self-signed certificate any amendments to the certificate and or expiry will mean that the certificate will require exporting and re-assigning

Configuring the Relying Party in Active Directory Federation Services

To create a relying party trust using federation metadata follow the steps below

  1. Create the Workday metadata file by copying the text below to Notepad and entering your tenant specific information in the highlighted section and then save the file as an .mxl file type


    <?xml version=”1.0″ encoding=”UTF-8″?>

    <md:EntityDescriptor entityID=”” xmlns:md=”urn:oasis:names:tc:SAML:2.0:metadata”><md:SPSSODescriptor AuthnRequestsSigned=”false” WantAssertionsSigned=”false” protocolSupportEnumeration=”urn:oasis:names:tc:SAML:2.0:protocol”><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</md:NameIDFormat><md:NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:transient</md:NameIDFormat><md:AssertionConsumerService Binding=”urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST” Location=”https://your_workday_domain/your_tenant_name/login-saml.flex” index=”0″ isDefault=”true”/></md:SPSSODescriptor></md:EntityDescriptor>


2. Open “Server Manager” and under the “Tools” section select “AD FS Management”

3. Wait for the “AD FS Management” page to load and expand the “Trust Relationships” folder and then right select the “Relying Party Trusts” folder and select “Add Relying Party Trust”



4. On the “Welcome” page, select Start.

5. On the “Select Data Source” page, choose to “Import data about the relying party from a file” by browsing to the metadata file created in step 1.


6. On the “Specify Display Name” page type a name in “Display name”, under “Notes” type a description for this relying party trust, and then select “Next”.

7. On the “Configure Multi-factor Authentication Now?” leave the defaults and “Next”



8. On the “Choose Issuance Authorization Rules” page, select “Permit all users to access this relying party” and then select “Next”.

9. On the “Ready to Add Trust” page, review the settings, and then select “Next” to save your relying party trust information

10. If you are ready to configure the claim rules now leave the “Open the Edit Claim Rules dialog for this relying party trust when the wizard closes” option checked, if not uncheck the option and select “Close”

11. The newly created relying party trust should be displayed in the “Relying Party Trusts” folder



12. Highlight the new relying party trust and right select then select “Properties”

13. Select the “Endpoints” tab and then select “Add SAML”

14. In the “Endpoint type” drop down menu, select “SAML Logout” this should automatically change the selection in the “Binding” drop down menu to “POST”

15. In the “Trusted URL” text field enter the ADFS logout page URL which will be similar to then select “OK”



16.Confirm you have both the “SAML Assertion Consumer Endpoints” and “SAML Logout Endpoints” populated and then select “Apply”


Required ADFS settings

Workday requires that the SAML message be configured so that the XML signature applies to the entire body of the message as opposed to the default of only the Assertion element, and also allow for any time differences between that of the ADFS service and Workday, in order to configure this you can run the below PowerShell.

Run the following PowerShell commands in order on the ADFS server:

•    Add-PSSnapin Microsoft.Adfs.PowerShell (adds the ADFS snapin to server)

•    Set-ADFSRelyingPartyTrust -TargetName <relyingpartytrust> -SamlResponseSignature “MessageOnly”

•    Set-ADFSRelyingPartyTrust -TargetName <relyingpartytrust> -NotBeforeSkew 3


Configuring the Relying Party Trust Claim Rules

In order to identify any user attempting to login to the service a specific Active Directory attribute will be returned in the authentication token provided, to edit the claim rules to respond with specific attribute mappings follow the steps below.

1. Open “Server Manager” and under the “Tools” section select “AD FS Management” Wait for the “AD FS Management” page to load and expand the “Trust Relationships” folder and then select the “Relying Party Trusts” folder

2. Select the Relying Party Trust you wish to add the claim rules to, right select and then select “Edit Claim Rules”

3. Wait for the “Edit Claim Rules for (relevant) Relying Party Trust” page to load and select the “Issuance Transform Rules” tab and select “Add Rule”



4. On the “Add Transform Claim Rule Wizard” select “Send LDAP Attributes as Claims” option in the “Claim rule template” drop down menu, then select “Next”

5. Enter a name for the claim rule in the “Claim rule name” text box, and then in the “Attribute Store” drop down menu select “Active Directory”

6. In the “Mapping of LDAP attributes to outgoing claim types” table, select the drop down icon in the first column “LDAP Attribute (Select or type to add more)

7. Select the relevant AD attribute that will be used to identify the user, for the purposes of this guide I have selected “User-Principal-Name”

8. In the “Outgoing Claim Type (Select or type to add more)” column select “Name ID” then select “Finish”





9. Ensure the rule has been added then Select “Apply” and then select “OK” to close the window




Configuring Workday to use ADFS as the Identity Provider for Single Sign-On

Listed below is the information required to configure Workday to use ADFS as the identity provider broken down into the sections on the Workday “Edit Tenant Setup – Security” webpage

Single Sign-on


Login Redirect URL
Logout Redirect URL /adfs/ls/?wa=wsignoutcleanup1.0
Timeout Redirect URL /adfs/ls/?wa=wsignoutcleanup1.0
Mobile Redirect URL /adfs/ls/idpinitiatedSignon.aspx?loginToRp=https://

SAML Setup


Enable SAML AuthenticationEnabled
Identity Provider NameName of ADFS Identity Provider
Enable IdP Initiated LogoutEnabled
Logout Response URLhttps:// /adfs/ls/?wa=wsignoutcleanup1.0
Enable Workday Initiated LogoutEnabled
Logout Request URLhttps:// /adfs/ls/?wa=wsignoutcleanup1.0
Service Provider IDhttp://
Enable SP Initiated SAML AuthenticationEnabled
IdP SSO Service URLhttp://
Sign SP-initiated Authentication RequestEnabled


About the author