Our time attendance portal entered a redirect loop after our identity provider updated their metadata yesterday. Users click the SSO login button and get stuck in an endless redirect between Workday and the IdP. The SAML assertion format appears to have changed based on what I’m seeing in browser dev tools.
I’ve tried re-importing the IdP metadata into Workday but the loop persists. The strange thing is that SSO works fine for other Workday modules - only time attendance is affected. Is there something specific about how time attendance handles SAML assertions that might be incompatible with the new IdP metadata format?
The redirect loop you’re experiencing is caused by three interrelated issues stemming from the IdP metadata update:
1. SAML Assertion Format Change:
Your IdP changed how it structures the SAML assertion. The new format likely uses different attribute names or namespaces. Time attendance is particularly sensitive to this because it validates specific attributes before establishing a session. Compare the old and new SAML assertions to identify attribute changes.
2. IdP Metadata Certificate Mismatch:
When you re-imported the IdP metadata, the new signing certificate wasn’t properly propagated to all Workday modules. Time attendance maintains its own certificate cache that doesn’t automatically refresh. You need to force a certificate refresh specifically for time attendance:
Navigate to Security Administration > Integration Systems > SAML Identity Provider
Select your IdP configuration
Click “Refresh Certificate Trust” and specifically select “Time and Attendance Module”
Save and test
3. Redirect Loop Root Cause:
The loop occurs because time attendance can’t validate the SAML assertion with the new certificate, so it redirects back to the IdP. The IdP sends a new assertion (properly signed with the new certificate), but time attendance still has the old certificate cached, creating an endless loop.
Resolution Steps:
Clear the Workday session cache for time attendance to remove any cached certificate references
Update the SAML attribute mapping to match the new assertion format - specifically check if these attributes changed:
NameID format (was it “email” now “persistent”?)
Email attribute name
Employee ID attribute location
Verify the RelayState parameter is being preserved through the redirect chain - add logging to track its value
Test with a single user account first before rolling out to all users
Prevention:
Set up monitoring to alert when SAML assertion validation fails. This would have caught the certificate mismatch immediately. Also coordinate with your IdP team to get advance notice of metadata changes so you can test in a non-production environment first.
The reason other modules work fine is they likely don’t perform the same level of assertion validation that time attendance does. Time attendance has stricter security requirements due to regulatory compliance needs around time tracking data.
This draft is based on general Workday knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
The redirect loop typically happens when the RelayState parameter gets corrupted or when the assertion consumer service URL doesn’t match what’s configured in your IdP. Check if the time attendance module has a different ACS URL than your other modules. Also look at the SAML response in your browser - is the InResponseTo attribute present and correct?
I checked the ACS URL and it matches across all modules. The SAML response does have an InResponseTo attribute but I’m not sure if it’s matching the original request ID. How can I verify that? Also noticed the new IdP metadata includes a different signing certificate - could that be causing the issue even though I re-imported the metadata?
The signing certificate change is definitely relevant. When you re-imported the metadata, did you also update the certificate trust chain in Workday’s security configuration? Time attendance might have a separate certificate validation path. Go to Security Administration > Certificates and verify that the new IdP certificate is trusted. Also check if time attendance has any module-specific SSO settings that override the global configuration.
I’ve dealt with this exact scenario. The redirect loop in time attendance specifically is usually caused by session cookie scope issues after IdP metadata changes. The new SAML assertion format might include different attribute names or namespaces that time attendance doesn’t recognize, causing it to reject the session and redirect back to the IdP. Check your SAML attribute mappings in the time attendance configuration - they might need to be updated to match the new assertion structure. Also verify that the NameID format in the assertion matches what time attendance expects.
That’s helpful - where exactly do I find the time attendance specific SAML attribute mappings? I can see the global SSO configuration but not seeing module-specific settings.
Time attendance doesn’t have separate SAML mappings in the UI - they’re inherited from the global config. But the module does have specific session handling that can cause issues. Check if your IdP is sending the email attribute in a different format now. Time attendance uses email as the primary identifier and if the attribute name changed from “email” to “mail” or “emailAddress”, it won’t recognize the user.