ybmmm•6mo ago

Splunk SAML authentication performs a second redirect back to Zitadel before login succeeds

Hello everyone, Environment Zitadel version : v3.2.2 Load Balancer: F5 We're running a self-hosted Zitadel behind an F5 load balancer and latest Splunk Enterprise version. In Zitadel we have a SAML application configured with all the necessary information from the SP Metadata XML which was generated by Splunk in the SAML Configuration section. When a user hits our external link, they get redirected once to Zitadel (this is initiated by F5), successfully log in the first time, but then we get prompted for Zitadel authentication a second time but this time initiated by Splunk. Looking at the session on the F5 it it is missing the "Roles" argument, but on the second request initiated by Splunk contains all of the necessary information, including "Roles" argument. I'm using one of the examples from the action scripts page:

function setCustomAttribute(ctx, api) {
    const user = ctx.v1.getUser()
    if (ctx.v1.user.grants == undefined || ctx.v1.user.grants.count == 0) {
        return;
    }
    let roles = [];
    ctx.v1.user.grants.grants.forEach(grant => {
        grant.roles.forEach(role => {
            roles.push(role)  
        })
    })
    api.v1.attributes.setCustomAttribute('Roles', '', ...roles)
  }

function setCustomAttribute(ctx, api) {
    const user = ctx.v1.getUser()
    if (ctx.v1.user.grants == undefined || ctx.v1.user.grants.count == 0) {
        return;
    }
    let roles = [];
    ctx.v1.user.grants.grants.forEach(grant => {
        grant.roles.forEach(role => {
            roles.push(role)  
        })
    })
    api.v1.attributes.setCustomAttribute('Roles', '', ...roles)
  }

Has anyone seen Splunk silently drop the first SAML response under these proxy/LB conditions ? Are there specific IdP metadata or assertion flags Zitadel needs for Splunk’s SP to accept the first assertion ? Any tips on settings that ensure Splunk’s session cookie “sticks” so only a single SSO redirect is required? Thanks in advance!

11 Replies

Rajat•6mo ago

hey @ybmmm it’s very likely due to F5 not putting the SAML session cookie or missing role attributes in the first assertion. Let me look into this more and will get back to you.

ybmmmOP•5mo ago

Hi @Rajat, thanks for your reply, would you have any idea what the problem might be ? Because I'm struggling to understand why is the initial request from the F5 is missing the "Roles" attribute, but the second one, initiated by Splunk does have it ? Thought that if the second request has the "Roles" attribute, that it shouldn't be a problem with the "Actions" script, but I'm having doubts about it. I've tried changing up the script by adding/removing in attributes, but that didn't have any effect on the F5s request, would mainly end up having an error on Splunk that's it's missing SAML group attributes and that's it. What I'm struggling to understand is where this problem is at, is it with the "Actions" script being incorrect and not passing the attributes, is it with the F5 being miss-configured. I'll be waiting on your response, thanks ! Hi @Rajat did you have time to take a look in to my issue ? Would really appreciate some input, thanks !

Jim Morrison•5mo ago

Happy Tuesday @ybmmm, I'll bring @fcoppede into the fold here to help aid support with Rajat out of the office. Thanks!

fcoppede•5mo ago

👋 Hello @ybmmm To better troubleshoot this issue, could you please share with me a network trace of the complete login flow? Please make sure you start to record the network trace before clicking on "login". Sample steps to create a network trace using Chrome: Step 1: Open Chrome Developer Tools Navigate to the page where you want to start the trace. Press: F12 or Ctrl + Shift + I (Windows/Linux) or Cmd + Option + I (Mac) Step 2: Go to the "Network" Tab In DevTools, click the “Network” tab (top of the panel). Make sure the red recording dot 🔴 is active. Step 3: Enable “Preserve Log” Option Check the “Preserve log” box at the top. Step 4: Start the Trace Click the Clear button (⛔ symbol or right-click > Clear) to remove previous entries. Perform the action you want to capture Step 5: Save the HAR File Important: HAR files can include PII, you can remove this by editing the HAR file as a text file and removing passwords or any other data that could be recorded.

ybmmmOP•3mo ago

Hi @fcoppede 👋 Sorry for such a delay in responding, as requested I've attached the redacted HAR file going through this login flow of two authentications. Let me know if you see anything strange in there. I've also looked into the configuration for our F5 and nothing seemed out of the ordinary, because I already have another system set up the same way and it has no issues like we're encountering with Splunk. Looking forward to a response and many thanks !

splunk-zitadel-auth-...

ybmmmOP•3mo ago

Hello @fcoppede did you have time to look in to this please ? Would greatly appreciate it 🙂

fcoppede•3mo ago

hello @ybmmm apologies for the delay, the problem is that in the first SAML response sent from Zitadel to the SP there is no "roles" attribute, and that must be triggering the 2nd auth request on your end. I'm currently unsure why the 2nd time the roles attribute is added correctly. Can you make sure the SAML app you are using has the following checkbox disabled?

ybmmmOP•3mo ago

Hello @Federico, No worries, thanks for the reply. Yes, I can confirm that the "Use new Login UI" option is disabled on our SAML project. Could there be some problem with the "Actions" script then ? I've attached the script and Splunk mappings as well, if you could take a look and see if you can find any issues with it, would greatly appreciate it. I've also tried setting custom attributes which you'll see detailed in an attachment below, but that did not impact the SAML response.

Action_script.txt

ybmmmOP•2mo ago

Hi @fcoppede, any updates on my previous question ?

fcoppede•2mo ago

Hello @ybmmm, thanks for the additional insights, I do not see any issue in the code you shared. Another thing that I noticed is that the first ACS URL being used by Zitadel is https://siem<redacted>.de/saml/sp/profile/post/acs and the second one is different: https://siem<redacted>.de/saml/acs, I'm not sure this is the root cause of the issue but it's worth checking which one is the correct ACS for your app. I believe this issue is happening because you have configured different ACS URLs in your SAML app in Zitadel depending on the binding, the first one is a redirect, while the second one is a POST. In the second scenario, the roles are added correctly and your users are logged in. As a summary of this, I would suggest the following: 1. Double check which is the correct ACS URL for your SP (Service Provider) 2. Double check your SP settings to make sure which is the right binding it should be using. I hope this makes sense, apologies for th delay in getting back to you.

ybmmmOP•2mo ago

Hi @Federico, thanks for your update, I'm still looking into this, but we can close this thread off while I'm now more certain that this is not an issue with how Zitadel is handling this and it's more likely due to the SP.

Splunk SAML authentication performs a second redirect back to Zitadel before login succeeds

Did you find this page helpful?