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 www.google.com/index.html, MWG performs authentication, redirects you to www.google.com/mwg-internal/[...], your browser accesses www.google.com/mwg-internal/[...], MWG replies with a 302 to www.google.com/index.html (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:
192.168.0.1 - asabban - 20140808085000
Now MWG assumes every request from "192.168.0.1" 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.
thank you for your help.
We now set up the cookie authentication and it works .... mostly.
When we connect to https://www.google.de/maps 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. http://mobile.de.
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.
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?
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.