This information was last reviewed in September, 2016, by Scott Cantor.
This is not a replacement for the actual documentation and you cannot cut and paste your way to a working system. The examples are not usable without taking into consideration your local needs and requirements.
This is a page for documenting Shibboleth integration with Workday.
The official SAML documentation provided by Workday is here at the time of authoring. It requires an account in Workday's authentication system.
In the version being documented, the settings being documented in Workday are under "Workbench -> Security & Audit -> Edit Tenant Setup - Security".
Unknown: Whether a role exists for a SSO administrator to only have access to the authentication settings.
Be aware that Workday can function as both an SP and an IdP, and it can be confusing sometimes to follow their documentation and understand to which aspect they're referring. This page is only discussing its SP functionality.
Identity Provider Metadata
Workday does not consume SAML metadata, and provides a self-service interface for manually managing the IdP integration settings required. The settings apply "on the fly" any time they're changed by an administrator.
There are a large number of settings to look at and there's a lot of fast and loose use of terms, but most of the IdP information is entered by "adding" an Identity Provider (you can register more than one) and filling in these details:
- Identity Provider Name (descriptive label)
- Issuer (your entityID)
- x509 Certificate (your signing key certificate, typically in credentials/idp-signing.crt)
The SAML Logout support is so far not proving functional for me, so I haven't documented it.
Down below that section, there are details related to how the Workday SP issues its requests, and that includes a setting for the IdP's SSO Service URL, which you should set to your SAML 2 POST binding endpoint (
Service Provider Metadata
Workday does not produce SAML metadata(*), and provides a self-service interface for manually managing the SP settings used that ultimately need to be reflected in metadata for the IdP. The settings apply "on the fly" any time they're changed by an administrator, so you must be cautious to change settings in most cases only after altering the metadata. For example, you can't change the key the SP will use until you've made the key known to the IdP, and the same goes for other settings.
(*) There are references in the documentation to the ability to generate metadata, but the documentation specifically describes this as generating metadata for Workday acting as an IdP to some other SP.
There are a few different settings that influence what needs to go into the metadata you give the IdP:
- Service Provider ID (entityID, you should
The main content of the rest of the metadata consists of the various endpoints, and those seem to be based on the tenant and seem to be shown in various places throughout their documentation. There are endpoints for both standard and accessible interfaces, for some reason, and there are endpoints for logout.
An example put together from a working tenant with the details removed follows:
Making SSO work in general required filling in several redirection URLs in a generic section at the top under Single Sign-On labeled Redirection URLs:
- Login Redirect URL
- Mobile App Redirect Login URL
- Mobile Browser Login Redirect URL
Set them to the ACS location placed into the SP's metadata ().
Workday does not always include the desired ACS location to use in its requests; as a consequence, you will need to ensure that you use separate metadata with distinct entityIDs for each tenant you must support. Otherwise a request from one tenant will result in a response to whichever endpoint is the default in the metadata you create.
Workday does not appear to support XML Encryption. You may disable encryption explicitly (example below), or you may disable it generally for any SPs for which no encryption keys are available by setting the idp.encryption.optional property.
Workday's SAML Setup includes a number of options that influence how it interacts with the IdP. Most of them relate to signing of requests or including the
ForceAuthn option (the latter would bypass SSO for all users if the IdP is properly configured).
A checkbox labeled "Enable Signature KeyInfo Validation" is unclear, but from its description it should be checked.
In most cases you'll want to let Workday push users to your IdP and back, by checking the "Enable SP Initiated SAML Authentication" checkbox.
Finally, the whole thing has to be enabled with an "Enable SAML Authentication" checkbox when you're ready to test it.
Signing requests is not something most sites will require, but a common case for using it involves forcing use of particular authentication methods (typically MFA) for all users. Workday is apparently working on various approaches for "step-up" interactions, but at present it is all or nothing because it doesn't support any SAML features for requesting authentication types.
A practical way to overcome this is to configure the IdP to default to a particular authentication context class, and to require signed requests to prevent a malicious user from overriding this. Enabling signed requests requires:
- Configuring a keypair in the x509 Private Key Pair setting
- Adding that key to the SP's metadata with
use="signing"(see partial example above)
- Choosing an Authentication Request Signature Method (SHA256 suggested, though that's a digest method, not a signature method)
- Checking Sign SP-initiated Authentication Request
AuthnRequestsSigned="true"inside the SP metadata in the
Having done this, you can reliably trigger a login method by setting the
defaultAuthenticationMethods property on the "SAML2.SSO" profile configuration bean.
SAML Logout seems to be broken (bug was reported), but there is a way to configure simple redirect-based logout by setting the Logout Redirect URL to the IdP's simple logout endpoint (/idp/profile/Logout).
Example Shibboleth Configuration
Refer to the RelyingPartyConfiguration topic and be cognizant that creating overrides for every service is generally an inefficient use of the software. Consider identifying common requirements across services and create overrides tied to multiple services that share those requirements, or that reference profile configuration beans containing common settings.
Required Profile Configurations
Optional Profile Configurations
The example shown demonstrates turning off encryption (and shows why it's more advisable in most cases to simply set the property to make encryption optional).
Most sites will create identities in Workday directly as part of business processes, or possibly provision accounts into Workday using integration APIs or batch feeds if using only, e.g., the Financials portion. The only field relevant for SSO is the primary ID field in the record. There are fields available for storing alternate identifiers, but all information obtained indicates that SSO can only be based on the primary ID.
Unknown whether any form of just-in-time provisioning is supported.
Workday requires that the value in the user's primary ID field in Workday be communicated in the
<NameID> element in the assertion. The
Format of the element is ignored (in fact, the logout bug mentioned above pertains to a mistake in the
Format value communicated back to the IdP).
Because the format is ignored, you should use a constant value that is defined in the SAML specification that corresponds to the type of identifier you're sending (not common, but possible), or more likely, use a value that matches that name of the SAML Attribute that would ordinarily carry the data you are passing in the element, and that you may already be using with other SPs.
For example, if you pass an employee ID in the element, use the standard name of the "employeeNumber" attribute, "urn:oid:2.16.840.1.1137184.108.40.206".
Example Shibboleth Configuration
Refer to the NameIDGenerationConfiguration topic for a full treatment of NameID features.
Continuing with the example above, if you have an attribute definition named "employeeNumber" produced by your AttributeResolverConfiguration, release it to the Workday SP in your AttributeFilterConfiguration (example below).
Since Workday metadata must be manually supplied to the IdP, the usual way of producing the right
<NameID> format is by including a
<NameIDFormat> element in the metadata, which is illustrated in the example metadata shown earlier.
Finally, to actually produce the necessary
<NameID>, modify saml-nameid.xml as shown:
Workday does not appear to support SAML Attributes.