We have several users that access government websites that require them to login with common access cards via a card reader. When we point those users to our web gateway and they attempt to access the sites they are prompted for logon information. This does not happen when the users are not being directed through the web gateway as the authentication is done with the CAC.
After some testing it was determined that disabling the rule "Handle Connect Call" rectifies the issue and the users are no longer prompted and can access the sites with their CAC.
However we do no wish to disable this rule as we have our on CA that is required per our security policy.
Further testing revealed if the users logged in with the rule disabled (meaning they authenticate with ther CAC) and we re-enabled the rule they could utilize the sites with no problem. So the problem is only with the initial authentication.
I'm looking for some information in helping to resolve this issue. Any advice and guidance is appreciated.
as the CAC is nothing else, but a client certificate stored on a card, this error sounds logical! Webgateway is intercepting the SSL Traffic with SSL Scanner. Therefore there is not direct connection between Client and Web Server. In case someone is logging in with their CAC this information is only available on the client side of MWG, whereas it is not on the server side, thus it fails! The only solution is to identify these hosts/applications and whitelist them from SSL Scanning.
We actually whitelisted the destination IP addresses...that took some tracking down but it appears to work. I would however rather whitelist the application application itself but I'm not sure which property string to use. Any ideas?
Hmm...that woudl require some debuging... By application I suspect you mean the application on the client?
Yes the work station hosts the application that the card reader uses. We'd like to be able to allow the application to bypass or blow through the Web Gateway without any filtering or inspection of that application.
OK, we might have chance to check if the application has a specific User-Agent!
Looking into SSL traffic, the user agent is in clear usually:
CONNECT www.facebook.com:443 HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Can you find if the application has a useragent? It might be recorded in the logfiles, or you can do a TCPdump on MWG to see the SSL traffic and then read it with wireshark.
A rule then could look like:
Header.Get(User-Agent) matches *My-Own-Application* STOP CYCLE.
Put that as high as you can in the rule tree.