June 11th, 2019, Ghent (Belgium). Awingu is excited to introduce version 4.2 of its Unified Workspace platform. Similarly to previous versions, Awingu 4.2 will bring enhancements 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 you an overview of the release. We’ll dive into more detail of some selected novelties below.
.
1. Improvements to the end-user UX
Direct Links
Awingu is mostly used as the sole 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 why Awingu 4.2 introduces “direct links”. When 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 in practice, what does this mean?
- 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 recipient’s 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 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 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
Awingu introduced its reverse Proxy already in version 4.0. In version 4.2, this one is extended with ‘group rewrites’. Noting that Awingu 4.1 also introduced SSO for “Basic authentication”.
Therefore, 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
Multi-Factor Authentication
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 Microsoft’s “Azure AD”. In version 4.2, admin’s can now set up a ‘pre-authentication’ requirement. Users that go to their Awingu login page would then 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. NOTE: Full SSO is available as of Awingu 4.3 – read more!
Do you want to see these new features in action? Watch our CMO Arnaud Marliere and COO Steven Dewinter demonstrate them in the 4.2 feature overview video!
Want to find out more and see Awingu in action? Reach out to us!
English 
Italian 
German 
Spanish 
French