Content-Switching is great, and with the addition a few years ago of having AAAVS behind a CS, a very small amount of IP’s are actually required to publish external applications. However, there is a few drawbacks that makes it abit complicated.
My setup is as following
portal.domain.com points to 10.10.10.10 (this FQDN handles both traffic and authentication)
ContentSwitch vServer – ip 10.10.10.10
Policies;
HTTP.REQ.URL.STARTSWITH("/app1") -> goto LBVS_app1
HTTP.REQ.URL.STARTSWITH("/app2") -> goto LBVS_app2
HTTP.REQ.URL.EQ("/").not && (is_vpn_url||HTTP.REQ.URL.STARTSWITH("/nf/auth/")) -> goto AAAVS_portal.domain.com
LB vServer – LBVS_app1- 0.0.0.0 – /app1
LB vServer – LBVS_app2 – 0.0.0.0 /app2
AAA vServer – AAAVS_portal.domain.com – 0.0.0.0
Policies (in my test i used LOCAL users and groups):
HTTP.REQ.COOKIE.VALUE("NSC_TASS").CONTAINS("https://portal.domain.com/app1") -> use ActionA (could be LOCAL)
HTTP.REQ.COOKIE.VALUE("NSC_TASS").CONTAINS("https://portal.domain.com/app2") -> Use ActionB (could be LDAP)
With the above setup; i am able to login to https://portal.domain.com/app1 – but unfortunately i also have access to https://portal.domain.com/app2
During the login process, the cookies; NSC_TASS and NSC_TMAP are reset, so i cannot use those 2 differentiate which application they have got access to.
I tried different options:
Authentication Profiles have something called “step-up” but that assume that a site is more protected then another, and they are both equal protected.
Authorization policies can only “allow/deny” access, not “logout”. it does work however, but it just leaves the user with “denied” a custom action would be nice.
Traffic policies can do “initiate logout” but does not redirect the first request back to the login page of AAAVS, so it does in fact log the user out, but the user wont know until the second request
What worked – no access and redirected back to the login page.:
Responder polices;
AAA.USER.NAME.LENGTH.GT(2) && AAA.USER.INTERNAL_GROUPS.CONTAINS("app1").NOT -> Goto RSA_reset_TMAS
AAA.USER.NAME.LENGTH.GT(2) && AAA.USER.INTERNAL_GROUPS.CONTAINS("app2").NOT -> goto RSA_reset_TMAS
RSA_reset_TMAS :
“HTTP/1.1 302 Object Moved\r\nLocation: "+HTTP.REQ.URL+"\r\nSet-Cookie:
NSC_TMAS=reset;Path=/;expires=Wednesday, 09-Nov-1999 23:12:40
GMT;Secure\r\nContent-Length: 100\r\nCache-Control: no-cache,
no-store\r\nPragma: no-cache\r\nContent-Type:
text/html\r\nstrict-transport-security: max-age=31536000 ;
preload\r\n\r\n"
The responder policies are bound to LBVS_app1 and LBVS_app2
The drawbacks of this:
A logout is not initiated (however, this could be build in fairly easy), leaving sessions on the ADC
Stuck with one theme on AAAVS, so it better be good.
In this case i was limited by only having one domain i could use, in a future case where i could have multiple domains, portal.domain.com (for regular data) and authentication.app1.domain.com and authentication.app2.domain.com and so on, i would like to try to have a CS that where all authentication domains point to(so i still only use 1 external ip), and then have separate AAAVS running with internal ip’s and LB/CS them like a normal application. This would properly require to have the first CS in a separate traffic domain or partition. This would then enable me to have a portal theme pr. application, but requires 1 additional ip and additional domains.
In the beginning you could have more then one AAAVS behind a CS, but that got removed due to errors, so right now, we stuck here – unless, someone else out there have a spiffy solution??