This is a multipart message in MIME format.
Hey David, The general name of this concept is SSO service. It can have single or multiple backends. The main question is how to implement the solution in the optimal way possible. (taking into account money, coding complexity and other humane parts) You will need to authenticate the client against the main AUTH service. There is a definitive way or statistical way to implement this solution. With AD or Kerberos it’s possible to implement the solution in such a way that windows will “transparently” authenticate to the proxy service. However you must understand that all of this requires an infrastructure that will provide every piece of the setup. If your setup doesn’t contains RDP like servers then it’s possible that you can authenticate a user with an IP compared to pinning every connection to a specific user. Also, the “cost” of non-transparent authentication is that the user will be required to enter (manually or automatically) the username and the password. An HotSpot like setup is called “Captive Portal” and it’s a very simple setup to implement with active directory. It’s also possible to implement a transparent authentication for such a setup based on session tokens. You actually don’t need to create a “fake” helper for such a setup but you can create one that is based on Linux. It’s an “Advanced” topic but if you do ask me it’s possible that you can take this in steps. The first step would be to use a session helper that will authenticate the user and will identify the user based on it’s IP address. If it’s a wireless setup you can use a radius based authentication ( can also be implemented on a wired setup). Once you will authenticate the client transparently or in another way you can limit the usage of the username to a specific client and with that comes a guaranteed situation that a username will not be used from two sources. I don’t know about your experience but the usage of a captive portal is very common In such situations. The other option is to create an agent in the client side that will identify the user against the proxy/auth service and it will create a situation which an authorization will be acquired based on some degree of authentication. In most SSO environments it’s possible that per request/domain/other there is a transparent validation. In all the above scenarios which requires authentication the right way to do it would be to use the proxy as a configured proxy compared to transparent. I believe that one thing to consider is that once you authenticate against a RADIUS service you would just minimize the user interaction. The main point from what I understand is to actually minimize the authentication steps of the client. My suggestion for you is to first try and asses the complexity of a session helper, raidus and captive portal. These are steps that you will need to do in order to asses the necessity of transparent SSO. Also take your time to compare how a captive portal is configured in the next general products: * Palo Alto * FortiGate * Untangle * Others
