Publish Web proxy on public interface

Do not do this. Opening Web Proxy on both Platforms is highly dangerous. Therefore it was disabled per default on SFOS. 

If you want to do Webfiltering, you can do it on a Endpoint Software (like Intercept X) or you do it via VPN. Intercept X is equipped to do this on HTTPS etc. 

Do not do this. Opening Web Proxy on both Platforms is highly dangerous. Therefore it was disabled per default on SFOS. 

If you want to do Webfiltering, you can do it on a Endpoint Software (like Intercept X) or you do it via VPN. Intercept X is equipped to do this on HTTPS etc. 

I always thought it was relatively safe to use the domain credentials before accessing the proxy. The user portal is also available via public where one could download  vpn or stas client if an domain account gets compromised. So that should also be considered as unsafe then. A little bit confusing. 

Ok, then we will have to switch back to VPN again. Thanks :)

AD SSO is more likely designed  to be used internally. To many ways to attack this protocol. https://en.wikipedia.org/wiki/Kerberos_(protocol)

So if you are sitting in a Hotel/cafe, you are sending those tickets etc. directly over the line, which makes it potentially insecure in plenty of ways. 

Kerberos works with http as well, which is dangerous. 

But then the userportal shouldn't use AD SSO as well or am I wrong? This is also a service called via https.

User Portal is a Service, which is hosted on the Website. It is different in the approach.

AD SSO is a service intended to use internally to authenticate the Client against a facility. The way both products implemented it was never to offer a service on WAN. 

Thanks again for your help :)