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!
Multi-Domain SSO Profile and Citrix iApp
We are working on getting SSO into Citrix (Storefront 3.0, XenApp 7.6) working using a multi-domain access profile (already created and performing SSO into other apps using NTLM, Kerberos, and SAML). When we have tried to add Citrix to the multi-domain AP, we end up hitting a wall. It seems that in the default Access Profile that the iApp creates, it sets the session.sso.token.last.username to "domain\[mcget {session.logon.last.username}]". That variable is then used by the form sso configuration object for authentication. But if I set this variable as described above in the multi-domain access profile, authentication breaks for other apps. Is there a way to set a different or custom variable and then leverage that variable for the form instead of the session.sso.token.last.username variable? If so, how would I set that variable? Any help is greatly appreciated. Thank you.
Multiple Domains SSO with APM and SAML
Hoping to get some ideas on this issue. I have an "overlay" vip working well with multiple host names point to it and it routing to an APM enabled "internal" VIP that does SAML client side and Kerberos server side as talked about in this thread. So far all my host names have been in the same domain (domain1.com) but now there is a new host name that is in another root domain (domain2.com) I have been using a domain cookie for all the domain1.com hosts and it works well (I am fine that APM is not fired client side once I have a session and go to other hosts under domain1.com). I now need to get domain2.com going and I need SSO between domain1 and domain2. So on the APM policy associated to my domain2.com VIP, I have a couple questions on this. 1) For the primary authentication URI should I point to a host name under domain1.com? 2) If yes, then when I use a host name that resolves to my overlay vip on domain1.com I get redirected to /my.logout.php3?errorcode=22 with an error "Access policy configuration has changed on gateway. Please login again to comply with new access policy configuration" in the browser an in the apm log file I get "No matching domain found for request host: host.domain2.com. So that makes me wonder what I should use for the Primary Authentication URI. I want/need it to be a SAML enabled authentication VIP, so why cannot I use a host name on my overlay vip? 3) Should my primary authentication uri be a specific authentication end point / VIP in domain1.com that is NOT my overlay VIP that is used just to establish a session in domain1.com and get my domain scoped cookied for domain1.com? Basically I need to get SSO going between domain1.com and domain2.com where both have overlay VIPS for multiple host names under each domain and route to internal vips that have an APM policy applied with SAML client side auth setup to an external IdP. Thanks in advance for any input or perspective on this one.
How do I tell if fix for ID453531 made it into 11.5.1.3.0.131?
Whilst I wait for support paper work to be sorted. I can't see a reference in the Release notes to 453531, so it seems likely it isn't fixed. If so I'll need an engineering hotfix for each release until it is incorporated (if ever), presumably that also requires support.