Multiple SAML SP access profile MRH cookie issue
Dear all, I am trying to configure the F5 Big IP as both SP and IDP using seperate access profiles configured on scope level profile (isolated). The IDP will then assure the SSO across all the SP applications, this is already working in version 15.1.3 but in version 16.0/16.1 the MRH cookie behavior seems to have changed. All SP share the same parent domain, the difference between 15.1 and 16 is the following: In version 15.1 for each domain name a specific cookie is created and F5 does not include the domain option in the response, on the clientside we see specific cookie entries for the complete domain with the respective MRH cookie. when connection to /my.policy the F5 responds with the MRH session cookie witout domain so the browser saves it as the specific host name / domain. In version 16 APM is responding with a wildcard domain *.example.com this results in issues when connection to the same domain for example idp.example.com the client sends the old MRH cookie and APM session are restarted/deleted. Is there a fix so that the per specific domain can be maintained when using SAML auth in access profiles? Perhaps an Irule that will remove the domain in response?
Multi Domain SSO APM configuration, evaluate policy before HTTP_REQUEST
Hello everyone, Have a bit of a head scratcher... Heres the scenario. I have 2 VSs. One serves up content to the user, the other is an authentication token provider which has iRuleLX/node.js code powering the auth token logic. The iRulesLX VS doesn't have an associated pool because it only uses the node.js logic. Both VS servers use the SAME APM policy. The APM policy has a multi domain SSO configuration setup with each of its urls. I have done Multi Domain SSO configurations before, so I know how to configure them. The workflow goes as follows... User hits VS_1 (content server), authenticates to APM, if successful, gets load balanced back to a node member and is 302 redirected to VS_2. VS_2 again has the SAME APM policy attached to it. VS_2 also has the same SSL client profile (were doing client cert auth). After being redirected to VS_2, the APM policy (should) see that the client has an established MRHSession via its MRHSession cookie and allows the connection to be associated with the session. Once associated with the session, the session variables can be used to create the token via the iRulesLX/node.js code. Bottom line, we need those session variables. Heres the problem... The iRule which is attached to VS_2, fires off the iRuleLX/node.js code to carry out the token assignment (I do not want to get into the intricacies of what the node.js code is doing, just know it works). The node.js code sits within an HTTP_REQUEST event. Because of this (I think) the user is not being associated with their APM session due to how iRule workflows work. See the following... https://devcentral.f5.com/articles/http-event-order-access-policy-manager Again this is my theory... Within the HTTP_REQUEST event on VS_2, we have it check to see if a session exists via the MRHSession cookie, and if not, stop execution and display message via HTTP 200 Response notifying the user to reauthenticate at VS_1. Now, when I do a single SSO domain configuration and just use the parent domain, everything works FINE. Unfortunately, this is NOT an option because it inhibits all my other VSs that are within that domain space using APM policies. So I know the configuration and code works. This is an APM/iRules workflow issue. Another thing, if I call the node.js code within a ACCESS_ACL_ALLOWED event, the session is associated fine in a multi domain SSO configuration because the session is assessed by APM. Unfortunately I can not use this configuration because I need to execute a HTTP::response command which isn't allowed within this event. I'm posting this hoping someone has ran into something similar and find out how they dealt with it. Maybe I'm over thinking this (I hope) but I've been pounding on this issue for the last week. I'll see if I can post snippets of the code. Its on a customers site so I don't know how much I can share. Thanks for any and all help!
