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.
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.