Did your business make the full transition to Google Apps in the last couple of years? Have you embraced Chromebooks? Chances are you really like the GSuite experience for productivity, communication, and collaboration, but, you still have some legacy services that are just too hard to migrate to a SaaS alternative in time and budget… Or maybe there just is no suitable SaaS alternative.
And just to be sure: Awingu’s workspace easily allows you to combine your Google ecosystem with your “legacy”. Best of both worlds! In this blog post, we’ll explain how you can
- access legacy applications and desktops in a Chrome browser on any device (incl. Android & Chromebook devices)
- deploy your legacy apps and Awingu’s virtual appliance on the Google Compute Platform (GCP)
- leverage your Google Identity for Single Sign-On access to your legacy systems
- use Google Authenticator as 2nd Factor Authentication (2FA) tool
- use Google Apps together with Awingu
What is Awingu and how does it work?
Awingu is a ‘Unified Workspace’ platform. It makes Windows & Linux applications and desktops, intranets and file servers securely available in HTML5 on any browser. Technically, Awingu is a Linux based Virtual Appliance that is set up in a ‘gateway-alike’ architecture in front of a classic back-end with Active Directory, RDP enabled applications and desktops (“Terminal Server”), classic File servers (SMB drives) or internal web applications and intranets.
The strength of Awingu is its very simple architecture which talks standard protocols to this back-end: WebDAV, CIFS, RDP, etc. This means: simple to set up and maintain! Furthermore, Awingu is a ’turnkey’ technology with all features built into the same platform.
1. Awingu and Google: access legacy apps in Chrome
Awingu has built its own proprietary HTML5 gateway. It translates RDP into HTML5 and can thus make classic ‘legacy’ applications or desktops available in HTML5, in a browser. These legacy services include bespoke packages such as AS400, Microsoft Dynamics, Sage BOB50, Quickbooks, Windows 7 OS, … but can also include self-developed software (the list is non-exhaustive). Awingu supports all main browsers, but Google’s Chrome browser is largely seen as the best performing one today.
Example: Awingu workspace running an AS400 terminal in a Chrome Browser
After the users authenticates, he gets access to the Awingu workspace in which all published applications, desktops and file servers can be found.
Given Awingu fully runs inside the browser, it also means users can rely on Chromebook and Android devices to work in their legacy applications/desktops as well their “Google Apps”.
2. Awingu and Google: running on GCP (Google Cloud Platform)
Awingu is a virtual appliance available on all main hypervisors and public cloud platforms, incl. GCP. Awingu needs at least 1 virtual appliance (8vCPU and 8Gb RAM) to cover up to 500 concurrent application sessions. The architecture is stackable in case more users are needed.
As the high-level architecture above depicts, Awingu needs to be connected (using standard protocols) with a classic back-end setup. Ideally the Active Directory (AD) and RDP enabled applications or desktops are also deployed on GCP. GCP’s IaaS automation services can be used to further optimize your monthly costs.
In case you have local, on prem, infrastructure and you wish to keep using this, that is possible too. Awingu can be deployed on prem also. Or, it can be deployed in GCP and connect to your on prem datacenter (hybrid).
3. Leverage Google Identity
If you are already using Google as your IdP, you can connect it with Awingu also. Google’s IdP supports SAML and OpenID Connect. Awingu can leverage Google as external IdP in a ‘pre-authentication’ (a.o. Awingu 4.2) or a ‘full Single Sign-On’ (a.o. Awingu 4.3) context.
- Pre-authentication means the user needs to authenticate at Google first, and then complete the login process in Awingu. Google is central and has a full overview on all user activity. Additional services from Google Identity can also be leveraged for Awingu.
- Full SSO means the user only needs to authenticate to Google’s IdP. There is no further login process required. Also, in this scenario, IdP services can be leveraged.
This makes life for the end-user very easy. In case he wants to access a Legacy service, he just goes to a URL in the browser (e.g. https://demo.awingu.com). If he’s already authenticated in Google, no additional credentials will be needed.
You can also use Awingu as a workspace aggregator, incl for “GSuite”. Meaning, you can add the links and application icons into the Awingu workspace. When users click the Google App icon, they will get Single Sign-On access.
High-level architecture for the ‘full SSO’ scenario
Note: in either scenario, an Active Directory will still be required.
4. Use Google Authenticator as MFA
Multi-Factor Authentication should be a default in any authentication scenario. In case you are not using Google as IdP and its associated MFA services, you can still secure the authentication process with Awingu’s built-in MFA functionality.
Built-in, Awingu has both Counter-based Password (HOTP) and Time-Based Password (TOTP) capability built-in. This can easily be used with the Google Authenticator App on a phone (available on both Android and iOS).
Note: Time-Based password capabilities are available since Awingu 4.2. Read here about all MFA capabilities and other integration options.
5. Use Google Apps together with legacy apps in Awingu
High-level architecture: using Awingu on GCP in SSO with Google Identity & GSuite
Already in section 3, we describe that it is easy to add “Google Apps” into the Awingu workspace and give the end-user an SSO experience when launching these Google Apps. But even if Google is not used as the IdP, this outcome is possible.
Here, you will use Awingu as the external IdP, and leverage the built-in SAML connection with Google Apps. Users will log in to Awingu using their Active Directory credentials, and will have SSO access to Google Apps via this route.
English 
Italian 
German 
Spanish 
French