When using Tempered’s Zero Trust Architecture, Software-Defined Perimeter solution
all policy is controlled from a central location in the Airwall Conductor. As a result,
securing access and using appropriate role-based access control is important when
setting up a production environment. Authentication platforms provide significant
value for managing user identities, delivering capabilities like single sign-on and multifactor authentication (MFA). When companies already have an authentication platform
provider or are looking to add MFA support to Tempered’s networking security solution
integrating these two solutions can often be the best architecture.
There are two primary use cases for integrating the Conductor with an authentication
platform: accessing the Conductor itself and/or providing user authentication for
remote users leveraging the Airwall Agent.
The purpose of this document is to provide the necessary steps to integrate
Tempered’s Conductor with Azure AD’s authentication platform using OpenID
Connect.
OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which
allows computing clients like the Airwall Conductor to verify the identity of an end-user
based on the authentication performed by an authorization server – in this case Azure
AD, as well as to obtain basic profile information about the end-user in an interoperable
and REST-like manner. In technical terms, OpenID Connect specifies
a RESTful HTTP API, using JSON as a data format.
Overview
When a user goes to login to the Airwall Conductor, they can either authenticate using
the Conductor’s configured users (People) or choose from a pull-down that allows
them to authenticate using a third-party authentication platform like Azure AD.
When the user chooses the Azure AD option, they will be redirected to the Azure AD
authentication page where they will need to enter their Azure AD credentials and
connect using MFA if configured. Once the user is authenticated, they will be
redirected back to the Conductor.
For remote access users running Airwall Agents, if user authentication is enabled and
linked to an authentication platform, the user will be prompted for credentials by the
Agent that is communicating with the Conductor. They will then be redirected to Azure
AD and once again they will need to enter their username and password and perform
the MFA steps if configured. Once authenticated, the Airwall Agent will be able to
connect to the devices configured in their overlay networks.
For either type of integration, the user configured in Azure AD will be part of a group
and that information is sent back to the Conductor so that the user can be assigned to
the proper role or People Group in the Conductor.
Preparing to Configure OIDC Integration
Gather the following information in preparation for configuring the OpenID connection
settings in the Conductor
Integrate Third-party Authentication with OpenID
Connect
You can integrate a third-party authentication provider with person authentication in the
Conductor using OpenID Connect (OIDC). If your users are already configured for single sign-on
(SSO) with a third party, or if you have a large number of users, this integration streamlines your
user management.
Note: You can only configure one OpenID Connect provider on the Conductor at a time. If you
need to support many OIDC authentication providers simultaneously, you can choose providers
that support federated login so you can connect to one provider and have that provider connect to
other providers to authenticate users.
Important: To use OpenID Connect on macOS or iOS Airwall Agents, you must have a
public certificate on your Conductor.
User Roles
In the Airwall Conductor, you configure person roles in OIDC by including them in groups. The
OIDC group names are pre-configured in the Conductor, so when you make a person a member of
one of the OIDC groups in the OIDC provider, they are automatically given that role in the
Conductor. For instance, you can declare that all members of the OIDC provider’s
cond_system_admins group are system administrators in the Conductor, and that members of the
OIDC cond_remote_users group are remote-access users.
This is configured in the Conductor when you set up the Authentication Provider. Each group is
configured to be in one of four groups that directly link them to the equivalent Role in the
Conductor.