Authentication through OpenID Connect
Configuring the identity provider
If you use an external identity provider that supports OpenID Connect, you can configure Cyberwatch to allow users to authenticate through that provider. This eliminates the need for administrators to manually create local Cyberwatch accounts through the administration console.
Cyberwatch’s OpenID Connect configuration is located in Administration > Identity Provider > OpenID Connect.
The first step is to create an OpenID Connect (or OAuth) application for Cyberwatch on the identity provider. You will usually have to specify the redirect URL, which is displayed on Cyberwatch’s configuration page. Cyberwatch exclusively uses the authorization code grant flow.
Since the access control management is delegated to the identity provider, we recommend that you give access to the application to as few users as possible.
Once the application has been added on the identity provider, you will have to input the provider’s authority URL into Cyberwatch. For instance, for Microsoft Entra ID, the URL is https://login.microsoftonline.com/{tenant}/v2.0
. You must then input the ID of the application you created for Cyberwatch. The secret can be left blank. Finally, save the configuration.
On success, a client certificate will be generated. You must attach that certificate to the application you created on the identity provider. This is required for authenticating Cyberwatch against the provider.
To test the configuration, you can log out of Cyberwatch or open a private browsing session. You should see a new button on the sign in form. Clicking on it will redirect you to your identity provider and then redirect you back to Cyberwatch. A new Cyberwatch account will be automatically created.
If the authentication attempt fails with a Cyberwatch error, please check the logs.
Synchronizing the attributes
The OpenID Connect identity tokens contain a set of claims defined by the identity provider that you can configure. Cyberwatch is able to use this data to automatically fill the account details on every connection.
You should usually synchronize the name and email attributes. The name of the attributes in the identity token may vary from one provider to another, but name
and email
are common attribute names.
The role of the accounts may also be defined from a token claim, which may let you automatically assign a role based on the authenticated user’s groups on the identity provider. Otherwise, the roles need to be defined by administrators after the account logged in for the first time.