Last Modified: Jan 29, 2019
See more info
Known Affected Versions:
12.1.0, 12.1.0 HF1, 12.1.0 HF2, 12.1.1, 12.1.1 HF1, 12.1.1 HF2, 12.1.2, 12.1.2 HF1, 12.1.2 HF2, 12.1.3, 184.108.40.206, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 12.1.4, 13.0.0, 13.0.0 HF1, 13.0.0 HF2, 13.0.0 HF3, 13.0.1, 13.1.0, 220.127.116.11, 18.104.22.168, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206, 220.127.116.11, 18.104.22.168, 13.1.1, 22.214.171.124, 126.96.36.199, 188.8.131.52, 184.108.40.206
Opened: Apr 10, 2015
If SWG-Transparent acts as SAML SP, then any request in background can prevent authentication process from completing. Use-case: 1. APM end user opens a site through SWG-Transparent. 2. SWG returns redirect to captive portal. 3. Captive portal acts as SP, so it produces SAML Request to IdP State after this point: - APM end user is on IdP Logon page. - APM end user's session on SP is waiting for SAML response from IdP. 4. Browser or OS do any HTTP/HTTPS request through SWG Transparent. - SAML Auth agent on SP interprets this request as SAML Response from an IdP and tries to find assertion information. It can't find assertion info and closes user's session on SP.
APM session on SP is closed unexpectedly for user
1. Configure SWG-Transparent (with Captive portal). 2. Configure a virtual server as IdP. 3. Setup SWG Captive portal as SP. 4. Go to IdP VS thru SWG. You will see IdP Logon page. Do nothing on this page. 5. Open a new browser tab/window and go to any HTTP/HTTPS site. Current session on SP will be closed.