In this blog post, we are going to explain how we can achieve the optimal user experience and security posture in shared desktop environments. We are seeing that our customers, mostly from educational institutions, are asking this question often, since students are using shared devices (e.g., computer lab or classroom) for accessing a Frame session.

Most of our customers integrate Frame with their preferred SAML2 Identity Provider (IdP). Leveraging IdPs such as Okta, Azure Active Directory, or Google Identity allows our customers to authenticate securely to Frame with the benefit of additional security features (multi-factor authentication, standardized password policies, password reset, etc.). Once a user authenticates with the IdP and is redirected to the Frame Console, two tokens (one for Frame and the second one for IdP) are automatically saved in the browser/Frame App (depending on how users are accessing the platform). If you are the only person accessing that particular device, you don't have to enter credentials every time you want to access Frame which is great! Unfortunately, in the shared environment, this can lead to a security issue!

So what's the security issue we want to address?

• Student A logs in to Frame, starts the session on the dedicated desktop/application, finishes their work and leaves.
• Student B sits down in front of the same machine, wants to access their desktop or applications in Frame, but the browser or Frame App is still automatically logged in with Student A's credentials since tokens are still active.

This is what we want to solve!

Let's start by explaining the standard workflow of authentication and authorization to the Frame Platform.

With the standard authentication and authorization workflow illustrated above, the student:

1. Goes to a defined URL (e.g., Launchpad, Launch Link)
2. Enters their credentials to authenticate
3. Chooses to start the desktop or application(s) based on the type of Launchpad they were authorized to use
4. Works in desktop/application
5. At that point, the bell rings and student will do one of the following things:
   • Close the session and log out from Frame - Best practice
   • Close the browser - Good practice, but still not the best one
   • Leave the browser open and walk away - Bad practice

What can we do to save this student's data from being accessed by the next student?

We need to understand and tackle this from a few different angles:

1. We need to define Frame Authentication Token expiration time.
2. We need to define the logout URL for SAML2 IdP
3. We need to define session settings in Frame
4. We need to define a mechanism for cleaning saved passwords and cache from the user's browser or Frame App
5. The users need to be educated on how to logout of Frame when they are done with their session

Authentication Token Expiration Time​

Setting up the Frame Authentication Token expiration time will help you manage the token's lifetime within the Frame platform. There is also a token from the Identity Provider in a separate format saved within the browser and you need to take care of that token lifetime as well.

When configuring SAML2 provider integration, there is a simple option that you can use - Authentication token expiration:

With the Authentication token expiration option, you can set the desired expiration time for the authentication token. This can range from 5 minutes to 7 days. In the shared device's environment, the shorter the authentication token expiration value is, the better from a security perspective.

Please note that while you (or your users) are within the session (either logged into Launchpad or working inside the assigned desktop/application) the token will refresh by default. After a user closes their session or even closes the tab/browser time for token validity will start ticking - so if you set it up to 5 minutes, the user can reach the Launchpad within 5 minutes of login to your identity provider or within 5 minutes after the user closes their Frame session. Otherwise, the user will have to authenticate to your identity provider once again.

More details on integrating Identity Providers with Frame can be found here.

Identity provider logout URL​

Besides the Frame authentication token, as mentioned in the previous section, your IdP's token is also stored in the end-user browser. To fully log out a user (to force the end user to enter their credentials each time they sit down in front of a shared device) you need to set up the logout URL within the IdP configuration.

For this option to have the effect, end-users have to log out from Frame!

Frame supports optional SAML2 attribute that the IdP can include in the SAML2 Authentication Response:

frame_logout_url

The user is directed to this URL when the user logs out of the Launchpad because they decide to leave Frame or when Frame logs the user out due to inactivity.

If, for any reason, you have difficulties setting up the Frame logout URL claim on your IdP, please reach out to the Frame Support team and we will gladly assist you with this configuration.

Frame Session Time Limits​

In Frame Dashboard > Settings > Session, you can configure custom Time Limits that will help you limit your users' access in a more detailed way.

• User Inactivity Timeout. This value specifies how long Frame will keep a session actively connected from the last detected user input (e.g. keyboard input or mouse movement). While the default value is 10 minutes, from an user experience perspective, it's important to set this value that accommodates reasonable periods of inactivity. Most customers set this value anywhere between 10 and 30 minutes. From a security perspective, the shorter the timeout the better to account for situations where a user may step away from the shared desktop, leaving potentially sensitive data exposed and accessible. It should be noted that if the user's IdP token has not expired, any user can reconnect to a disconnected session by simply clicking on the Resume button within Launchpad (if the previous user did not explicitly log out of Frame).
• Idle Timeout. This value specifies how long after a Frame session is put in a disconnected state (either manually by the user or automatically as a result of the User Inactivity Timeout being reached) until Frame automatically closes the session. When the session is closed, the VM state and any unsaved work would be lost. From an user experience perspective, it may be valuable to allow for enough time for the user to quickly step away (e.g. for a bathroom break) and return to the shared computer without having to restart their session. For other organizations, setting Idle Timeout to 0 minutes (coupled with a short User Inactivity Timeout) is desirable to help ensure that anytime the user steps away from the shared desktop their session is quickly closed.
• Max Session Duration. This value specifies the maximum time a Frame session can last before it is automatically closed. Again, when the session is closed, the VM state and any unsaved work would be lost. Max Session Duration is typically configured based on the requirements of the use case to ensure an optimal user experience. From a security perspective, Max Session Duration is typically not as important as either User Inactivity Timeout or Idle Timeout for shared desktop environments. Most customers will set the value to equal the maximum time an user can potentially access the shared desktop during any given session (e.g. if a computer lab is open from 8AM - 10PM, a Max Session Duration of 14 hours would be configured). It should be noted that users can simply start a new session if they do reach the Max Session Duration limit.

If you would like to learn more about our session Time Limits and Frame's other configurable session settings, please see our documentation here.

Clearing Cache from the Shared Device's Browser or Frame App​

Depending on IdP settings and time limits, the IdP and/or Frame tokens will be stored in the browser after a user has finished his session. To prevent other users from accessing or resuming a session using someone else's user accounts, the easiest way is to clear the local cache from the browser or Frame App so that the next person that uses the device will have a clean start and be required to authenticate themselves to your identity provider. Every browser has options to automatically clean the cache after the browser window has been closed without direct action by the user/admin.

Chrome​

Chrome offers a option to automatically clear cookies and site data when all browser windows are closed

1. Launch Chrome and click on the 3-dots to open Settings
2. Select Privacy and security settings
3. Click on Cookies and other site data
4. Enable Clear cookies and site data when you close all windows
5. Restart Chrome browser.

Edge​

For Microsoft Edge, navigate to the settings using the three menu dots, select Privacy, search and services, and enable Cookies and other site data. The data will be cleared after the browser has been closed.

Firefox​

The same options are also available in Firefox. Navigate to Settings > Privacy & Security > Cookies and Site Data. From there, enable Delete cookies and site data when Firefox is closed. You can also set some exceptions for pages where you do not want to have the cookies and site data be cleaned up.

Those options can be either set on the browser config level, applied via GPO, or set by using registry keys. Especially for bigger environments, the recommendation would be to use GPO or registry keys to set those configurations as they can easily be updated and pushed to all machines if needed.

All information on how to setup/configure those rules for each browser can be found below:

• Chrome
• Edge
• Firefox

All of the above mentioned browsers also offer a way to manually delete the local cache, please see the links below to get more information for each browser.

• Chrome
• Edge
• Firefox

Frame App​

Frame App functions similarly to web browsers. Frame App contains a local cache that saves cookies, session tokens, and specific user preferences (e.g., automatically use all local displays). For Frame App for Windows, administrators can update Frame App user preferences either in HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER. If user preference registry keys are set in HKEY_LOCAL_MACHINE, those user preferences will take precedence as they will apply to all users. The relative path to the registry keys is \SOFTWARE\Nutanix\Frame\Preferences.

CHECK_FOR_UPDATES_ON_STARTUP

Frame App will clear the local cache on startup when this argument is set to ON.

More details regarding the preference options can be found here.

The cache can also be deleted manually when required.

Follow the steps below based on the operating system on which Frame App is installed. Replace $USER with the name of your user.

C:\Users\$USER\AppData\Nutanix\Frame\cache

If users access their desktop and applications via the Frame App instead of the browser, there is the option to clear the cache when the Frame App gets started. Settings can be accessed by selecting Frame > Preferences.

Educate Users to Log Out of Frame

You should also think about scenarios where end users will simply run out from a shared device, leaving the session in the running state. That's definitely something they shouldn't do! Therefore, educate users on how to log out securely so their data is not accessible by other users.

You can pick on any of the tactics you want (organizing training, sending emails etc.). We are seeing that simply putting stickers on the monitors with a short and clear message can significantly reduce the number of these cases:

"Once you are done working, please log out!""

Conclusion​

Being secure and caring about your users' data is everyone's responsibility! With implementing the best practices in a shared environment, we can assure that our user's data is safe even if the device is being used by multiple users and that the best end user experience is achieved.

Unlock the full potential of remote work with a risk-free trial of our Frame DaaS solution - click below to experience seamless virtual desktop and application access now!