SAML Cookie Persistence after browser/system restart and across service providers

I assume you are actually talking about leveraging F5 Access Policy Manager(APM) for this. If so, the cookie behavior is controlled under SSO/Auth Domains tab of the access policy. Check the Persistent checkbox, and it will be persistent across browser restarts.

I assume you are actually talking about leveraging F5 Access Policy Manager(APM) for this. If so, the cookie behavior is controlled under SSO/Auth Domains tab of the access policy. Check the Persistent checkbox, and it will be persistent across browser restarts.

are you connecting to a hostname? or to an IP? is the domain correctly set in the SSO configuration?

when you connect for the first time, is a cookie set at all?

For anyone curious, the response from F5 support is that cookie persistence is triggered in APM only when forwarding to a pool on the virtual server and the pool responds. Since we are configured as a SAML IdP the pool is really just a placeholder and there is nothing to respond. It was recommended we submit a feature request to add this in future updates so we're doing that.

In the meantime, they provided us with an iRule to cover the behavior and with that in place we are seeing the cookie persist beyond browser restarts and computer reboots.

Hey Michah - I'm having the same issue, do you still have that iRule to share?

Here is the rule. We apply this to each Virtual Server we create that has an SSO policy associated with it and in the SSO/Auth Domains section of the Access Policy put the same parent domain in the domain cookie field.

So we have auth.mycompany.com for one IdP, auth2.mycompany.com for another and each of those has it's own Access Policy and Virtual Server. Then they both have mycompany.com in the SSO/Auth Domains section of each of those Access Policies.

Oh and the session timer is stupid long because currently marketing is requiring that sessions remain active for 7 days. We'll see how long that lasts before it causes problems =/

when CLIENT_ACCEPTED {
ACCESS::restrict_irule_events disable
}

when HTTP_RESPONSE_RELEASE {
HTTP::cookie expires MRHSession 604800
HTTP::cookie expires LastMRH_Session 604800
}

Hi Micah

I have tested the above and I wanted to know what do you managed to achieve with the above? We have a service provider that has a short cookie and or saml session validity that constantly redirects users back to our idp. We want to work around this.

Does this provide a cookie authentication mechanism to the idp which does not require the user to re-enter credentials?

That's exactly what i have been trying to achieve. So under SSO auth settings which options do you use to set the cookie? Secure and persistent tick boxes? And then you just bind the irule to the virtual server?

Sorry for all the questions. Been trying to get this to work..

Thanks I'll test this today.

We use our Idps in a similar way, we have our a VS fpr each idp. i.e. dropbox.company.com and google.company.com. I have setup dropbox with a redirect irule "ACCESS::respond 302 Location https://dropbox.company.com/saml/idp/res?id=/SSO/dropbox"

So from my understanding the cookie should now be set for requests coming to dropbox.company.com - and subsequent service provider samlrequests should not challenge my idp for creds as I should pass the cookie header. Is your solution tested for IDP initiated SAML logon or is this something you don't use? Reason is, after implementing, when I close my browser and go back to my idp dropbox.company.com it presents me with the same logon form.

OK - In the access policy I assign a webtop which is why my cookie gets reset by the APM module even when I pass the persistent cookie when I refresh the browser.

I need the webtop to do IDP initiated SSO with an iRule. One for F5 support I think