As a unified workplace solution, Awingu covers many angles. Authentication is one of them. In this blog post, we’ll zoom into Awingu as a platform that enables Single-Sign-On authentication to legacy systems instead of Awingu as a ‘workspace’ platform.
For a start, we need to make a difference between
A. Authenticating into the Awingu workplace
B. Authentication into back-end services (e.g. a Remote Desktop, a legacy windows application or a file server)
Two phases in the authentication process
A. Authenticating into Awingu
Awingu supports many techniques to authenticate. The most used today is still a classic ‘username/password’ login procedure (1). The credentials are based on Active Directory (or LDAP). Awingu will also support many ways to add Multi-Factor Authentication (MFA). Built-in, Awingu supports both Time-based password (TOTP) or Counter-based password (HOTP) as 2nd factor (meaning you can use native mobile applications such as Microsoft Authenticator and Google Authenticator to generate a secure token). Next to the built-in flavor, Awingu supports many other commercial platforms.
With the rise of SaaS services, also came the rise of external Identity Providers (IdP). Services such as Okta, Microsoft Azure AD and Ping Identity come to mind. Their initial proposition was focussed around aggregating the logins for SaaS services to make life easy for end-users and administrators. From there, they have further evolved and expanded into other domains. Awingu can leverage these external IDPs in either a ‘pre-authentication’ (as of Awingu 4.2) or a ‘full Single-Sign-On’ (as of Awingu 4.3) mode. Awingu supports the SAML and OpenID Connect (an evolution of OAuth) protocols to set up a trust with the chosen IdP. These standards are supported by the wide majority of providers.
(2) Pre-authentication means the user needs to authenticate at the IdP first, and then complete the login process in Awingu. The IdP is central and has a full overview of all user activity. Additional services from the IdP (e.g. MFA, geo-fencing, time-restricted access, …) can also be leveraged.
(3) Full SSO means the user only needs to authenticate to the IdP. There is no further login process required. Also in this scenario, IdP services can be leveraged.
In some cases, smartcard-based platforms are used. These are not uncommon, for example, in the healthcare and financial industry. Awingu can support some of these scenarios too. Some of the platform vendors will support SAML or OpenID Connect, others – such as Imprivata for example – also offer credential ‘vaulting’.
B. Authenticating into applications and file servers
Okay, so you’ve authenticated into the Awingu workspace. Now you’ll want access to those applications, desktops and file servers you are authorized to use.
For the services, Awingu supports the following:
- RDP based Windows applications and desktops. Here, Awingu will support
- classic username & password-based authentication
- a proprietary PKI certificate-based authentication model (as of Awingu 4.3). This is needed when using ‘full SSO’ to an external IdP. In this scenario, Awingu doesn’t have the actual username & password credentials to work with. Awingu will ‘trust’ the IdP when it authenticates a specific user to actually be the said user (note: there is no impersonation of the user).
- SaaS services: There are 2 ways to give end-users an SSO experience to SaaS services inside Awingu:
- Use Awingu as IdP. Awingu has a predefined set of connectors with popular SaaS services such as Office 365, Google Apps and Salesforce. When using these connectors, Awingu is used as an external IdP.
- Use an external IdP, in combination with Awingu authentication options (2) and (3). In this case, the SaaS services are connected to the chosen external IdP, and the links to the SaaS services are published in Awingu without more. Once the end-user logs into the Awingu workspace, he is authenticated to the IdP and thus for his SaaS services. This scenario allows adding lots more SaaS services compared to Awingu as IdP.
- Intranet or internal web applications: Awingu support ‘Basic Authentication’ here. Warning, it requires a username/password-based authentication, so will not work in conjunction with (3)
- File Servers: Awingu support CIFS and WebDAV (Basic Authentication) to connect to file servers (“SMB drives”). The latter is not supported in conjunction with (3)
Summary overview: primary authentication option with Awingu
In the above overview, we have made abstraction of network-based authentication. In some scenarios that might be an additional requirement. At this level, Awingu can also support Kerberos and NTLM based authentication.
Above overview shows that Awingu can support a vast array of authentication options. If your business has already chosen to adopt an external IdP such as Okta, Ping identity, Google Cloud Identity or Microsoft Azure AD for SaaS services, you can now easily enrich this experience with legacy applications and desktops too.
The end-users can use the Awingu workspace as aggregation point, but they can also use the IdP’s workspace and simply click the link of a published legacy apps or desktops (since Awingu 4.2 ‘direct links’ are supported). Awingu will spin-up the chosen applications/desktops in a browser, in full SSO. Hassle-free.
Illustration: use Okta’s workspace to access Awingu and/or published legacy applications
When you already leverage an external IdP, you might also be using their services for MFA, geofencing, time restricted access, etc. These services can also be applied to Awingu.
Good to know: Awingu is multi-tenant. Each tenant can be set up for authentication in a different way.