Given how notoriously awful users are at making sound security decisions, what's the business case for allowing a user a username/login away from say, malware or pornography?
Assuming there's a good answer to that above, here's how this would work I think.
MWG has a notion of "remotely managed lists" and notions of a customer managed list and mcafee managed lists. I think that's the feature that'll enable you to do what you want somehow.
Are you doing Try-auth or any sort of authentication on the web gateway today?
If so, a remotely managed list of approved override usernames that could be updated via some approval process or custom web app might be able to meet this need. Then, the MWG block page for whatever site in question could certainly be customized to do a redirect or give a link to that custom web app y'all write , and the web app could update that remotely managed list. The MWG can point to that list via the policy> lists tab and you can create a new list (such as a string list), check the remotely managed checkbox, check the customer managed radio button, and in setup for the list, point to the ftp/http/https location where the list will be retrieved by the MWG every x minutes. It's all configurable. If your custom web app craps out a list of usernames that are authorized, or a list of IPs that are authorized, you could shim in a ruleset element to allow that username or IP to get to that specific site. Such as a global white list rule near the top or ... something.
Say for example we block Domain Dropbox globally but we have anExecutive who requires access - ( for whatever reason) and instead ofwhitelisting the domain or his IP address , we figure it would be easier if there was a bypass allow prompt link on the "Block page" . This would allow my IT staff to allow access provided you know thepasscode ( similar to captcha or mcafee DLP "Request DLP EndpointBypass" )
There is, actually, a way to do this. I have seen an example of this internally as an experimental demonstration (way before 7.0 was even in beta)
The general work flow is this:
User hits a page that they really need to get to.
The page contains a Site Review-like link that contains information about the URL and user, and a justification.
This data gets emailed to the help desk to authorize the site. But the email has a link to another Authorization block page on-box.
Instead of the Help Desk logging on to the GUI and adding a site to a list, the Authorization block page would:
Authenticate, so only specific users could whitelist someone else.
Display the details and have a Submit button that adds the URL to PDStorage for that user.
The PDStorage has an auto-expiration time of x hours to delete the entry the next day.
The Whitelist rules in general would be in the normal policy to lookup the PDStorage sites as well as the normal static sites.
The original demonstration was actually to show how an admin could whitelist a site for a user from their iPhone while they were at the bar, but you can use a computer at your desk instead
If anyone is feeling really creative and wants to work out those rules, have at it.
We have ie INTERNET_STREAMING_G group and INTERNET_IM_G groups. Specific AD users can be member of one or more such AD groups.
Then there is block rule which blocks access if"Authetication.UserGroups does not contain "INTERNET_xxxx"
You can see result of Authetication.UserGroups function via webadmin - Accounts - Test with current settings form.
We do the same thing with AD groups. We have 10-12 different groups that provide access to things such as Social_Media, File_sharing, web_ads, etc. that the "normal" user doesn't need for day to day activities.
We also set up a few special groups for the higher level executives that only blocks viruses, malware, and other really bad things.
Of course, even though the block message tells the user why they can't get to facebook.com, and provides a link to the request application, we still get calls and complaints about the Internet police stopping them from doing their jobs.