Can Awingu use an external Identity Provider such as Azure AD or Okta?

As a unified workplace solution, Awingu covers many angles. Authentication is one of them. Let’s 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 2^nd 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 and Microsoft Azure AD 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.