You can now integrate Pulseway RMM with third-party identity providers (IdPs) using the OpenID Connect (OIDC) protocol. This allows users to log in to Pulseway RMM using established credentials from providers like Google and Microsoft.
NOTE: Only one identity provider can be enrolled at a time.
Configuring the OIDC connection
Enabling the integration
From the left navigation menu, navigate to Configuration > Settings > OpenID Connect Login Settings.
In the OpenID Connect Login Settings section, turn on the Active toggle.
Turning on this toggle and configuring the other required settings enables the Log In with SSO button on the login page. This option allows users to securely log in to Pulseway using an external provider, such as Google or Microsoft. To be fully enabled, the connection must be set up by configuring both the IdP and the integration within Pulseway.
Configuring your IdP to connect to Pulseway RMM
In the Identity Provider Configuration Information section, you will find the Redirect URL and the Post-Logout Redirect URL. These fields are not editable and are provided for you to copy and paste in the corresponding settings of your IdP (Google, Microsoft, and so forth).
Redirect URL: This is the page where the authentication server sends the user once they have successfully authenticated through their identity provider.
Post-Logout Redirect URL: This is the page where you want a user to land after logging out of Pulseway RMM.
Configuring the IdP connection in Pulseway
In the OpenID Connect Configuration Information section, you will configure the connection between Pulseway RMM and your OIDC IdP of choice (Google, Microsoft, and so forth) using the following fields:
OpenID Configuration URL: Enter the URL provided by your identity provider to configure secure login. This URL allows the system to fetch the necessary details for authentication.
Client ID: Enter the public identifier of the OpenID Connect application.
Client Secret: Enter the private identifier of the OpenID Connect application. This field is hidden.
Username Claim: Pulseway will retrieve this value from the IdP to use as the username. Example: Entering the value email will establish the user’s email address as their username.
Email Claim: Pulseway will retrieve this value from the IdP to use as the email address. Typically, this field will be set to email.
User Identifier: Identifier in the form of a claim that will be used by Pulseway to match a local account for the authenticated user. Choose between Email or Username.
Scopes: Scopes are required by the OpenID Connect provider to retrieve information about the authenticated user. Refer to your OpenID Connect provider documentation for more information about which scopes to use.
Authentication Type: This value specifies how the endpoint wants the Client ID and Client Secret sent. Choose between In HTTP Header and In Request Parameters. Refer to Authentication Type best practices for more information.
Configuration Example – Microsoft 365
Below we’re going to go through the process of configuring Microsoft 365 OIDC to integrate with Pulseway.
Enabling the integration in Pulseway
1 - From the left navigation menu, navigate to Configuration > Settings > OpenID Connect Login Settings.
2 - In the OpenID Connect Login Settings section, turn on the Active toggle.
Add Pulseway to your Microsoft Entra Applications
Before you can generate the necessary tokens and URLS needed to log into Pulseway using Open ID Connect via Microsoft 365, you’ll need to add the application to the list of Microsoft Entra applications.
1 - Sign in to the Microsoft Entra admin center.
2 - Go to Applications > App registrations.
3 - Click New registration.
4 - Give the app registration a name such as “PulsewaySSO”, and make sure to fill in the Redirect URI with the Redirect URL from the OpenID Connect Login Settings page in your Pulseway account.
5 - Click Register to complete the app registration.
After you add or create a Microsoft Entra application, you can return to the Microsoft Entra applications tab and select the application name to review settings for the application, including the Tenant ID, Client ID, Reply URL, and App ID URI.
OpenID Configuration URL
To find the OIDC configuration URL in the Microsoft Entra admin center, sign in to the Microsoft Entra admin center and then:
1 - Browse to Identity > Applications > App registrations and select the application you created for Pulseway SSO.
2 - Under Manage > Overview, click Endpoints.
3 - Locate and copy the URI under OpenID Connect metadata document.
4 - Enter the copied OpenID Connect metadata document URL into the OpenID Configuration URL field in the OpenID Connect Login Settings.
Client ID
To find the Pulseway application ClientID in the Microsoft Entra admin center, sign in to the Microsoft Entra admin center and then:
1 - Browse to Identity > Applications > App registrations and select the application you created for Pulseway SSO.
2 - Under Manage > Overview, copy the Application (client) ID.
3 - Enter the copied Application ID into the Client ID field in the OpenID Connect Login Settings.
Client Secret
To find the Pulseway application Client Secret in the Microsoft Entra admin center, sign in to the Microsoft Entra admin center and then:
1 - Browse to Identity > Applications > App registrations and select the application you created for Pulseway SSO.
2 - Under Manage > Certificates & secrets, click New client secret, enter a description and expiration date, then click Add.
3 - Copy the Value from the newly generated client secret.
4 - Enter the copied client secret value into the Client Secret field in the OpenID Connect Login Settings.
This is a typical example of an OIDC setup between Microsoft Entra and Pulseway. Once all required fields have been properly configured, click Save to save your configuration.
Authentication Type best practices
In OpenID Connect (OIDC), the standard supports sending the Client ID and Client Secret primarily in the HTTP headers using basic authentication. This method is preferred and aligns with best practices for securing these credentials.
HTTP Header (preferred method)
Basic authentication: The Client ID and Client Secret are concatenated with a colon (:) and then base64-encoded. The resulting string is sent in the Authorization header of the HTTP request:
Authorization: Basic base64(ClientID:ClientSecret)
Request Parameters (deprecated method)
While OIDC also allows the Client ID and Client Secret to be sent as parameters in the request body (especially for POST requests), this method is less secure and is generally discouraged:
client_id=your_client_id&client_secret=your_client_secret
The use of HTTP headers is recommended because it prevents sensitive credentials from appearing in URL-encoded logs or being easily captured in network traces.
Best practice
It is recommended to use HTTP headers (basic authentication) to transmit the Client ID and Client Secret securely in OIDC requests. This is done in the integration by selecting the In HTTP Header authentication type.