+49 69 83008980 service@xqueue.com
Benötigen Sie Hilfe?

Im Maileon Help-Center finden Sie umfassende Dokumentationen zu unserem System.

Beliebte Suchanfragen: Importe | Rest-API | Integrationen | SMS

Single sign-on (SSO) implementation

Sie sind hier:

Single sign-on (SSO) implementation

Single sign-on (SSO) is a new implementation in Maileon by supporting the OpenID Connect (OIDC) protocol. SSO provides an alternative method for authenticating and logging into an account.
This function is currently available only on the newsletter account level. To activate SSO, please see the details below.
Please note: Authentication server with OIDC authentication protocol (other like SAML are currently not supported)

Product Activation

To enable SSO, it must first be activated in XACT.

Open the details page of the newsletter account:

Scroll down to the Account Configuration section,

and then further down to the Single sign-on (SSO) feature to enable it.

Once it is enabled, SSO-related settings pages will appear in the newsletter account’s settings when logged in as an account administrator.

Account Wide Settings

After enabling Single sign-on, please log in to the account.

The settings will contain a new subsection “Single sign-on” in the “User management” section. Please enable OpenID Connect by using the slider:

Activating the button will display the form containing the minimum required settings. The Client ID, Client secret, and Discovery URI must be configured to correspond with the Identity Provider (IDP) that will be used.

Client ID: This is configured in the Identity Provider (IDP) to identify the client application – in this case Maileon.

Client secret: typically configured in the IDP to reflect the client application. In this case, the client is the Maileon application, which requires the ability to retrieve user information (such as successful login status and email addresses) from the IDP.

The Client secret is essential for ensuring that the Identity Provider (IDP) recognizes the Client Application or Service Provider as a trusted entity. The client application uses Client secret to authenticate with the IDP during direct communication. This process allows the IDP to share user information exclusively with trusted parties and to generate ID-Tokens intended for those trusted entities.

Discovery URI: This is where the URI for publicly available well-known configuration of the Identity Provider (IDP) must be specified. According to the OpenID Connect (OIDC) specification, this URI should always be located at the IDP with a path ending in “/.well-known/openid-configuration”

These settings are the minimal configuration necessary for SSO using OIDC to work.

Please note: Selecting the “activated” checkbox will enable the settings, which is also required to facilitate Single sign-on (SSO) login for the account. This operates independently of the “OpenID Connect” toggle at the top of the page, which will create or delete the settings. In other words:

  • If the “OpenID Connect” Toggle is turned off, and the settings page is saved, existing settings will be deleted completely.
  • If the “activated” checkbox is unset, the settings such as Client-ID and Client secret can still be saved, but Single sign-on (SSO) will not be active.

Changing the Client secret

Once these settings are saved and the page is reloaded, Client secret is always hidden.
A configured Client secret will never be shown on the settings page, but it can be modified.

If you click on “>>Expert mode” the field for the Client secret (along with fields for some advanced settings, detailed below) will reappear. However, it will be displayed as empty, regardless of whether a Client secret was previously saved.

If you modify any other settings and save the form without entering a value in the Client secret field, the previously stored data will remain unchanged. Only entering a new Client secret in the form field will update the stored secret.

URIs

The settings page displays two URIs within the Maileon Application specific to the current newsletter account. Both are important for essential functionality. While these settings are not managed directly within Maileon, they required consideration on the customer application and Identity Provider (IDP) side.

Redirect URI: This URI must be configured within the Identity Provider (IDP) to serve as an acceptable Redirect URI in the OIDC Client configuration. It is an integral component of OAuth and OIDC, without which OIDC functionality will not operate correctly on the IDP side. A convenient button on the right allows for easy copying to the clipboard.

Auth Start URI: This URI initiates the OIDC login process. It is displayed on the settings page for the customer’s website to directly link to. Additionally, if OIDC login is enabled for the account, a link containing this URI is provided on the account’s login page.

Advanced Settings

Please refer to the upcoming image to highlight the advanced settings. These are not essential for basic functionality.

User Creation: By default, this setting is disabled. It requires users to already exist within the newsletter account to log in using ID-Tokens from the Identity Provider (IDP).

Enabling this setting triggers automatic user creation under the following conditions:

When a user accesses the initial OIDC URL that initiates the Login Flow, they are redirected to the to the configured IDP and successfully authenticate. Upon retrieving the ID-Token and UserInfo from the IDP (via the Authorization Code Flow), Maileon creates a user if one with that email does not already exist.
This setting should only be enabled if the IDP supports per user limitations using the specified IDP Client settings. If this capability is absent, enabling the setting could potentially allow any authenticated IDP user to access Maileon.

Standard Role: When User Creation is enabled, a default Standard Role can be assigned to users created through OIDC login. These users will be created with this role.
Alternatively, leaving this role empty means users will have no permissions upon creation at all.

ACR values: This value allows to define the acr_values to send to the Identity Provider (IDP). As part of the OIDC protocol, this enables the Relying Party/Service Provider to specify the authentication methods the user must use at the IDP.

The current implementation allows saving this value and will transmit the acr_values to the IDP. However, the implementation is not yet complete; it does not verify that the ACR claim in the provided tokens matches what was specified in the OIDC Authentication Request. Consequently, the usefulness of this feature depends on the behavior of the IDP.

Process logout on IDP: The default setting for this flag is disabled. If enabled, when the user actively logs out of Maileon (but not when logged out due to inactivity), the user will also be logged out of the IDP by being redirected to the IDP’s end_session_endpoint. This functionality is only available if the IDP has an end_session_endpoint and OIDC RP-Initiated Logout 1.0 is enabled.

Post-Logout Redirect-URI: This setting can be any https-URI. If configured, upon logging out of Maileon, the user will be redirected to this URI. Typically, this could be the customer’s parent application. For example, if the Maileon app is accessed from a customer’s website via a link (which would typically lead to the Auth Start URL for the account), it would be reasonable to redirect back to the customer’s website after logging out.

The technical behaviour of this setting depends on whether the “Process logout at the IDP” flag is enabled.

  • If the flag is NOT set, the logout will directly redirect to the Post-Logout Redirect-URI.
  • If the flag is set, the Logout MUST redirect to the IDPs end_session_endpoint. In that case, according to the OIDC Specification, the Post-Logout Redirect-URI is passed to the IDP with the Logout-Request as the parameter post_logout_redirect_uri, which is part of the OIDC standard.

The IDP will then redirect to the URI. However, for the redirect to be performed, the URI must generally be configured as a valid post_logout_redirect_uri in the Client configuration within the IDP server software. This requirement depends on the IDP server software.

Switching Users between SSO and local Login

The current implementation allows newsletter accounts to have a combination of users who login locally at Maileon using a password, and users that login via an Identity Provider (IDP).
However, a user can only login using SSO or OIDC. Each user must be configured as either a local user, or an OIDC user.

This distinction can be set using a new UI element on the “User Details” page at Settings > Users > Click on User OR Add new user accessible to administrators.

If the OIDC product is enabled in an account, the “User Details” page will appear as follows on the following image.

  • If the Single sign-on (SSO) checkbox is enabled, users are required to login through SSO via an OIDC IDP only.
  • If the Single sign-On (SSO) checkbox is disabled, users can only log in using the local login method.

Please note:

  • The Single sign-on login operates on a session-based basis. Once authenticated via a browser (e.g., Firefox), a session begins. Switching browsers will not carry over the session, requiring re-authentication.
  • There is a significant implication regarding the configuration options where a user can only be set to use either local login or Single sign-On (SSO), especially considering that users exist at the customer account level. If you exist within a customer account that encloses two or more newsletter accounts, and it is configured to use OIDC while some newsletter accounts do not have OIDC enabled, you will be unable to log into those accounts without OIDC login enabled.
Inhaltsverzeichnis