---
category: [Administration & Integrations, Administration & Integrations/Custom Integrations & Apps, Platform and Product Extensions, Platform and Product Extensions/Workday Extend, Platform and Product Extensions/Integration]
nav: wcp_docs
parent_url: /wcp_docs/
title: Configure SAML for the Workday Developer Site
layout: subsection
---

### Context

<a id="context_N1002B_N10028_N10001"></a>
<b>Note:</b> This feature is available to Extend Pro customers only.

SAML authentication for the Workday Developer Site (developer.workday.com) enables developer single sign-on through your enterprise's centralized identity provider. On the <b>Account</b> dashboard of the Developer Site, Company Administrators can configure, test, and activate SAML authentication. Once you activate SAML, users in your account are required to use SAML authentication to sign in to the Workday Developer Site instead of using Extend's time-based one-time passcode (TOTP) authentication flow.

<b>Important:</b> While Workday can currently only assist with troubleshooting Azure, Okta, and Ping Identity SAML IdPs, you can still configure other identity providers for use with Extend.

### Steps

1.  <a id="step_N10035_N10032_N10028_N10001"></a>On the <b>Account</b> dashboard of the Workday Developer Site, select the <b>SAML</b> tab.
2.  <a id="step_N10046_N10032_N10028_N10001"></a>As you complete the form, consider:

<table><thead><tr><th>    Option</th><th>    Description</th></tr></thead><tbody><tr><td><b>Display Name</b></td><td>Identifies your SAML identity provider (IdP).</td></tr><tr><td><b>Entity ID</b></td><td>The unique URL that identifies your identity provider as the recipient of SAML requests.</td></tr><tr><td><b>Domain Name</b></td><td>Select an email domain that you have set up in Workday Extend.</td></tr><tr><td><b>Name ID Format</b></td><td>The name identifier format supported by the identity provider. We currently only support <code>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</code>.</td></tr><tr><td><b>B64 Encoded Public Key</b></td><td>Your base-64 encoded X.509 public key.</td></tr><tr><td><b>Sign On Endpoint</b></td><td>The URL to which the Extend Developer Site redirects users for authentication.</td></tr><tr><td><b>Sign Out Endpoint</b></td><td>(Optional) The URL to redirect users to when they sign out of Extend.</td></tr><tr><td><b>Sign Type</b></td><td>Select <b>Assertion and Response</b>.</td></tr></tbody></table><br/>

3.  If you're using Azure as your IdP, clear the <b>Is the Authn Request Compressed</b> check box in the <b>SAML</b> tab of the <b>Account</b> dashboard.

    Azure doesn't support the compressed authentication option.

4.  <a id="step_N100BB_N10032_N10028_N10001"></a>Click <b>Save</b>.
5.  <a id="step_N100C8_N10032_N10028_N10001"></a>Review the information that your SAML identity provider (IdP) will use to authenticate to the Workday Developer Site:

<table><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><b>SP Entity ID/Audience URI</b></td><td>See the entry for your region on <a href="/wcp_docs/dlh1653340161856.html">Reference: Workday Extend API Gateways and Authorization Base URLs</a>. <p>When an IdP creates a SAML message, this field is used to indicate the intended recipient of the SAML message.</p></td></tr><tr><td><b>Signed Assertion and Signed Message</b></td><td><p>A SAML assertion is an attribute statement inside of a SAML message. If you sign only the assertion, Workday can't verify that the additional contents of the SAML message haven't been modified. However, if you sign the SAML message, Workday can validate that the message contents haven't been modified. As an added layer of security, Workday requires both by default.</p></td></tr><tr><td><b>Name ID Format</b></td><td><p>The name identifier format supported by the identity provider. We currently only support <code>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</code>.</p></td></tr><tr><td><b>Extend Public Key</b></td><td>Used if your IdP needs to validate the AuthN request. However, Extend does not currently sign the AuthN request.</td></tr><tr><td><b>Assertion Consumer Service (ACS) URL</b></td><td><p>Also known as the Extend Sign On Endpoint or Reply URL, this is the URL that your IdP will respond to.</p></td></tr><tr><td><b>Extend Sign Off Endpoint</b></td><td><p>This is only needed if you configure your IdP for single logout.</p></td></tr></tbody></table><br/>

6.  <a id="step_N100D1_N10032_N10028_N10001"></a>Test your SAML configuration by logging into Workday Extend through your identity provider.

    When you test your SAML configuration, users can still use TOTP authentication to sign in to the Workday Developer Site.

7.  <a id="step_N100DE_N10032_N10028_N10001"></a>Click <b>Activate SAML 2.0</b>.

    Once you've verified that you can sign in and out using SAML, activate the SAML configuration to require SAML authentication for your account. The <b>Activate SAML 2.0</b> button is only available once you log into Extend using your IdP.

    <b>Note:</b> Once you activate SAML 2.0, users in your account can no longer use TOTP authentication to sign in to the Workday Developer Site.

8.  (Optional) You can add an extra layer of validation by specifying a custom attribute as part of the SAML assertion. A custom attribute is a key/value pair of a particular type that's defined with your IdP. When you mirror that definition on the Developer Site, Extend rejects a user's login attempt if the custom attribute is missing from the assertion or if its value fails to match the definition.

    <b>Note:</b> Extend also rejects a login attempt if the attribute definition you create on the Developer Site isn't mirrored in the IdP. You should confirm correct mirroring before enabling the attribute.

    1.  To begin, click <b>Edit Items</b> under the <b>Advanced Settings</b> heading, then click <b>Add Item</b>.
    2.  Select a <b>Type</b> for the attribute from the drop-down list. Enter a <b>Key</b> and a required <b>Value</b>. Example: creating a String key of `deviceType` with a value of `Apple` means that a SAML assertion that lacks the attribute pair or has an incorrect value is rejected.

        <b>Note:</b> String is the only type currently available. More will be added.

    3.  Click <b>Add Item</b> to create an additional custom attribute, if required. Use the <b>Enable</b> toggle switch to include or exclude indiviual attributes in the assertion.
    4.  When you're satisfied with your defined attribute or attributes, click <b>Save</b>.



### Result

<a id="result_N100E9_N10028_N10001"></a>
Users must use SAML authentication to sign in to the Workday Developer Site.

<b>Note:</b> Once you activate the SAML 2.0 configuration, you can't change the configuration. If the configuration is incorrect, users will no longer be able to sign in to the Workday Developer Site and you'll need to create a support ticket.

### Next Steps

<a id="postreq_N100F3_N10028_N10001"></a>
If necessary, you can <b>Disable SAML 2.0</b> by logging into the Extend Developer Site and accessing the <b>Configuration</b> tab. Once you disable SAML, ensure that users reset their passwords.

Disabling SAML removes the identity provider configuration and prevents users from signing on to the Workday Developer Site using the configured identity provider. To enable users to sign on to the Workday Developer Site using SAML, you must reconfigure SAML with the correct identity provider configuration, and then reactivate SAML.

### Related Information

[Concept: Extend App Security](/wcp_docs/vel1628698852360.html)