Showing results for 
Search instead for 
Did you mean: 

Webgateway 7, Authentication Server and TTL


we use a Ruleset with the Authentication Server but i have some Questions to the TTL.

What i wanna know:

The Authentication Server stores a ?Session Cookie? somewhere for a specific time -> the TTL.

This Session is authenticated for the whole Client? -> ip based? or what is stored in this Session? and where?

So the Problem is: When i authenticate me in IE for example then i can use this Authentication with Firefox too.

Also e.g. Windows Update can use this active authenticated Session to get Updates with the Proxy.

-> I want a new Session for every Programm.

Can I change this?

Best regards,


3 Replies

Re: Webgateway 7, Authentication Server and TTL

Hi Daniel,

we have two sorts of authentication server implementations, both are part of the rule set library in the product.

In our terms we have "Cookie Authentication" and "Session Based Authentication".

You enable one or the other by making the correct changes in the authentication server settings, but there are some dependencies so you can't easily switch from one method to the other (as additional rules are required) and you cannot have both at the same time.

For "Cookie Authentication" when a client successfully authenticated MWG sends a Cookie to this client. E.g. you go to, MWG performs authentication, redirects you to[...], your browser accesses[...], MWG replies with a 302 to (the URL you wanted to go to) and adds a Set-Cookiet: MWG-Auth[...] header, which sets a cookie called "MWG-Auth" in the browser. If you configure a cookie and a session length in the Authentication Server setting I think (means not 100%ly sure) there is a timestamp put into the cookie, which makes it invalid after the session length is expired, so authentication will be enforced again.

This will work for different applications on the client, e.g. if you have three browsers installed every browser will have its own session and will have to authenticate. There is no relation to the IP address, e.g. this is the more "correct" way of authenticating.

For "Session Based Authentication" a little trick is used. After you authenticated MWG will remember the session like this: - asabban - 20140808085000

Now MWG assumes every request from "" belongs to user "asabban", since he authenticated from this IP address before. As a last value we store a timestamp which is the length of the session, e.g. if you specify 5 minutes the timestamp will be 5 minutes in the future. After that point of time it expires, so the session is no longer valid, MWG will ask you to authenticate again.

This is helpful for situations where the clients do not understand cookies. For example this is also used for IM where your IM Client shows you a link that you follow, authenticate and then you can use the IM client during the active session.

The benefit is that it is a very simple implementation of authentication and works fine as long as every user has its own IP address. It is not 100%ly accurate (as it won't notice when another user logs on to a workstation) and does not have the capability of logging out when closing the browser (this only works with cookies).

Hope this helps to find the right approach for you.




Re: Webgateway 7, Authentication Server and TTL

Hi Andre,

thank you for your help.

We now set up the cookie authentication and it works .... mostly.

When we connect to the cookie is set and the map is shown but i cant zoom or move the map around.

There are some Problems with dynamic contents also on other sites, e.g.

On google maps web gateway all the time goes to the "Redirect Clients That Do Not Have a Valid Cookie to the Authentication Server" rule.

Bildschirmfoto vom 2014-08-13 16:09:00.png

We use cookie auth server with ldap authentication while normal ldap auth traffic is just base 64 encoded.

Where is the Problem here? Auth Server or google?



Re: Webgateway 7, Authentication Server and TTL

Hi Daniel,

the rule is triggered when a request comes in that does not send a cookie. It is hard to tell what is causing the problem but it might be possible that the URL is called not by the browser itself but by a Java/Ajax component and the cookie is not added to the request. Or the cookie is present but wrong for some reason 🙂

What you can do is add a rule somewhere in the policy that says "Header.Request.Get("Cookie") matches * Then Continue.

This rule will not do anything but in the rule engine trace you can find the request that does not go through and check that rule, the rule engine trace will show you the content of the "Cookie" Header, so you know whether that request carries the correct cookie or not. If it has an MWG_Auth Cookie it should go through, if it does not send any cookie at all it might need a second look.

For such a specific case it might be beneficial to involve support. Basically I don't see a problem with that setup and usually the cookie authentication works quite well.



More McAfee Tools to Help You
  • Subscription Service Notification (SNS)
  • How-to: Endpoint Removal Tool
  • Support: Endpoint Security
  • eSupport: Policy Orchestrator
  • Community Help Hub

      New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

    • Find Forum FAQs
    • Learn How to Earn Badges
    • Ask for Help
    Go to Community Help

    Join the Community

      Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

    • Get helpful solutions from McAfee experts.
    • Stay connected to product conversations that matter to you.
    • Participate in product groups led by McAfee employees.
    Join the Community
    Join the Community