June 11th, 2019, Ghent (Belgium). Awingu is excited to introduce version 4.2 of its Unified Workspace platform. Similar to previous versions, Awingu 4.2 will bring enhancement in four pillars.
- Improvements to the end-user UX
- Extension of aggregation capabilities
- Enhancements in the security & compliance space
- Improvements to the platform foundations
The following gives a summary overview of the release. We’ll dive into more detail for some selected novelties below.
1. Improvements to the end-user UX
Awingu is mostly used as the sole and only workspace for its users. However, in some scenarios, users will have a mix of ‘workspaces’ and ways to interact with their applications and data. Maybe there is only 1 application deployed behind Awingu, or maybe past investments already translated into a ‘workspace’ via SharePoint or other.
This the context why Awingu 4.2 introduces “direct links”. What an app (file/folder) is selected, in the detail view (i) a “direct link” is displayed which gives direct access to this app (file/folder). These links can then be added into a different workspace of choice (e.g. SharePoint, Windows 10, Office 365).
Direct link for a published application
Awingu Direct link integrated into Office 365 launch menu
RDP Session Merge
One of the challenges with RDP and VDI has always been loading user profile data. This can significantly impact the load times and create end-user annoyance. This is not an Awingu specific challenge, and there are some solutions on the market like FSLogix (now Microsoft) that can help here.
In version 4.2, Awingu introduces RemoteApp factor login, or in other words the ability to merge application session in the same RDP stream. There will not be any impact on the first application session open time. But as of the 2nd application, the Awingu platform will try to open this from within the same RDP stream. As a result, no new profile data needs to be loaded as it’s already open form the first application. In the back-end, this approach does require running multiple application in the same VM (otherwise, Awingu will not be able to merge the apps in the same RDP session). RDP session merge can be activated per application by the company admin.
The following picture gives a high-level view of the flows:
For the end-user, opening an additional application will look similar to his native Windows experience with screens on top of each other
File & session sharing
File and session sharing has been part of Awingu for a long time already. In this version, the experience is further simplified and unified. So what’s new functionally:
- File sharing – user selection: you can now select Awingu users (AD based) to share a file or folder. This file or folder will then become available in the recipients Awingu Files environment, and more specifically in the ‘shared with me’ section. Next to selecting named Awingu users from within his own Domain, Awingu 4.2 will still support sharing to ‘any’ user in the domain, or to external users as a sort of “Wetransfer” use-case.
- File sharing – password: users can now add a password to the download link. This was previously already the case for session sharing.
- Session Sharing: you can now define the access rights to ‘any user inside the domain’ or ‘public’ (ie. External users). Note that the host always keeps control of the session, and, that all sharing activity is audited.
As was the case in previous versions of Awingu 4.x, administrators can define on a very granular basis who (user/group) can share files and/or sessions.
Example: file sharing in Awingu 4.2
Admin triggered session share
Admins can now initiate an application session share from the Awingu Dashboard.
Here, they select a user and a specific application session and then just request to “join the session”. The end-user impacted will need to ‘grant access’. This can be very useful in providing swift and efficient support. Furthermore, everything is fully audited.
2. Extension of aggregation capabilities
Already in version 4.0, Awingu introduced its reverse Proxy. In version 4.2 this one is extended with ‘group rewrites’. Noting that Awingu 4.1 also introduced SSO for “Basic authentication”.
As such, intranet based apps, or in some cases public web/SaaS services can also be aggregated behind Awingu without the need to RDS licensing.
3. Enhancements in the security space
Awingu 4.2 will offer ‘Time-based password’ as a built-in feature. This means users can use apps on their phone such as Microsoft Authenticator. In the past, Awingu already had built-in support for ‘One-Time Password’ based MFA (linked to tools such as Google Authenticator).
The 2nd Factor Authentication can be disabled for white-listed users, and/or, for selected IP subnet ranges (e.g. no MFA login needed inside the office). While user white-listing is possible, Awingu does recommend all users to use MFA for security reasons.
The following table gives an overview of all MFA solutions supported via Awingu.
Pre-Authentication with external IDP
Some Awingu customers also use an external IDP (Identity Provider) such as for example Microsoft’s “Azure AD”. In version 4.2, admin’s can now set up a ‘pre-authentication’ requirement. As such, users that go to their Awingu login page on the browser will be redirected to the IDP for authentication, to be redirected back into the Awingu workspace.
The benefit is that all authentications (for Awingu, and for non-Awingu based services) now run through the same source. Additionally, the IDP might also have extra security capabilities – such as MFA – which can obviously also be used.
Do you want to try out the new Awingu 4.2 capabilities for yourself? Start your free trial today!