ASG Web Security

Scoob, what advantage would AD-SSO offer in those scenarios over Transparent with Authentication set to something like 40000 seconds?

Cheers - Bob

Scoob, what advantage would AD-SSO offer in those scenarios over Transparent with Authentication set to something like 40000 seconds?

Cheers - Bob

Bob,

My thought was that AD-SSO would offer the ability for Astaro to track the "change of hands" as the IOS device went from one student/faculity member to another (similar to PCs in a lab when someone logs out and a new user logs in).  The current timer method cannot account for the change of user on the device.

The more I think about it though, I am not sure it is even possible to do from the security appliance side given the operational model of these personal mobile devices.  Looking at iPads in particular, there is no local user authentication, apps (like the web browser) don't get "closed" by default when you jump out of them (they stay running in the background unless you specifically kill them) , and they do not "turn off" unless you specifically manually force it to power off.  Even if AD-SSO gets implemented,  if a persistent IP and browser connection is maintained how would the Astaro ever know that a user change had occurred?  That is they key right there - they are designed to be PERSONAL mobile devices.  They simply were not designed to be used as multi-user.

This is the problem we face trying to integrate and manage these personal mobile devices.  The only solution I have come up with so far is to segregate them onto a separate internal subnet with its own wireless SSID, then create a new proxy profile specifically for that network with transparent proxy and trying to fit  a universal filter rule set that is restrictive enough for students yet open enough for faculty.

Scoob, what advantage would AD-SSO offer in those scenarios over Transparent with Authentication set to something like 40000 seconds?

Cheers - Bob

Bob,

My thought was that AD-SSO would offer the ability for Astaro to track the "change of hands" as the IOS device went from one student/faculity member to another (similar to PCs in a lab when someone logs out and a new user logs in).  The current timer method cannot account for the change of user on the device.

The more I think about it though, I am not sure it is even possible to do from the security appliance side given the operational model of these personal mobile devices.  Looking at iPads in particular, there is no local user authentication, apps (like the web browser) don't get "closed" by default when you jump out of them (they stay running in the background unless you specifically kill them) , and they do not "turn off" unless you specifically manually force it to power off.  Even if AD-SSO gets implemented,  if a persistent IP and browser connection is maintained how would the Astaro ever know that a user change had occurred?  That is they key right there - they are designed to be PERSONAL mobile devices.  They simply were not designed to be used as multi-user.

This is the problem we face trying to integrate and manage these personal mobile devices.  The only solution I have come up with so far is to segregate them onto a separate internal subnet with its own wireless SSID, then create a new proxy profile specifically for that network with transparent proxy and trying to fit  a universal filter rule set that is restrictive enough for students yet open enough for faculty.