Carbonio Email Service provider

Have a Question?

From the Login Page onwards, the process of accessing a Carbonio instance—including the access modality—is influenced by Carbonio Auth. The access mask varies depending on the specified authentication backends, allowing users to submit their credentials using any backend. The Carbonio Auth for users also reflects this.

All of the Carbonio-supported authentication methods (user/pwd, SAML, 2FA, MobilePwd, and QrCode) and service authorizations may be managed with Carbonio Auth.

This section is arranged as follows and is separated into three main sections. The description of each supported authentication method can be found directly below; the next two sections are devoted to administration tasks, which need privileged access and are typically completed from the CLI, and daily tasks, which can be completed by both administrators and users from the Web GUI.

Approved Authentication Techniques

These backends are supported by Carbonio Auth:

  • Permanent Auth link
  • Management of self-service credentials
  • Management of mobile passwords
  • password for the software
  • Integration of SAML
  • Using an OTP token for 2FA authentication
  • Management of Credentials via CLI
Admins can use Carbonio Auth.

The tasks administrators may perform to administer and keep up Carbonio Auth are covered in this section. The prerequisites for the various authentication methods are listed below, followed by installation procedures and then credential management.


Following conditions must be met in order to activate the authentication mechanisms offered by Carbonio.

Establishing SAML Configuration

The SAML IDP (IDentity Provider) must be configured using the SAML SP data in order to integrate a SAML application into Carbonio. In our hypothetical example, we would like to add SAML authentication to the website, which is reachable at SP_URL.

An IDP provider handles the SAML configuration, which is subsequently imported into Carbonio by means of a specific command.

The following setup choices are the most crucial. They need to be set up on the SAML IDP side.





nameid-format:emailAddress sp.nameidformat urn:oasis:names:tc:SAML:1.1

Make sure that the Name of the property that is used as NameID is set to mailPrimaryAddress in order to validate against Carbonio.

There are now two ways to integrate a SAML application in Carbonio: automatically or manually. Details on each technique are provided in the sections that follow.

Automatically import SAML configuration

If the URL provided by the SAML IDP is, you may import the settings by issuing the command:

You’re finished now! The LOGIN SAML button is shown on the login page.

You will be sent to the SAML IDP login page if you click it.

Manually import the SAML configuration

Follow this 4-step process if you need to manually update the SAML setup. Briefly said, you must edit the default SAML settings, export them, save them, and then import them back.

Set up SAML Logout Some SAML IDP providers need that the logout process also be signed. If you already have SAML setup, you might follow the steps outlined in the previous section by exporting the configuration, making the necessary changes, and then reimporting it.

By altering the configuration file saml.json provided in the previous section, we demonstrate how to add signed logout to the settings used there.

The SAML IDP logout service URL must first be set up (line 7, sp.single_logout_service.url). The URL will be similar to as Okta is used as an example SAML IDP provider.

The service provider’s certificate, sp.x509cert (line 8), which should already be present, is then configured.

You should be finished at this stage and ready to import the changed configuration file.

Please do these extra procedures, however, if the SAMP IDP stipulates that the requests must also be signed or if you need to sign the requests for security reasons.

  • New X509 certificates should be generated and registered with the SAML IDP. To build one with openss1, run a command similar to the one below.
  • Lines 8 and 9 of the configuration file to be included for the certificate (sp.x509cert) and the private key (sp.privatekey).
  • Set security by enabling signature creation.line 30, “logoutrequest_signed to true”
  • By adjusting security, you may also choose to activate the signature for the login request.line 32: authnrequest_signed to true
SAML Access to a Service

You can access a Carbonio resource in a variety of ways once SAML authentication has been set up correctly on the SP and IDP sides:

  1. When you are logged in, go to the IDP portal and select the resource you wish to use.
  2. Visit the service’s website directly, and then click the SAML LOGIN button that displays next to the username and password boxes.
  3. Use the direct URL to the service’s SAML authentication. For instance, if you have a Carbonio installation (the Service) at, you may access the mailbox by clicking the URL provided you are already connected to the IDP.
Configure SAML on Azure, for instance.
In this part, we set up SAML to provide SSO access to a Carbonio installation (the Service Provider, SP) on an Azure portal (the Identity Provider, IDP). For this process to work, the Azure portal must first be configured using a few settings from the Carbonio installation, after which Carbonio must be configured to utilise the Azure portal as a SAML provider.
Allowing a new coworker or employee their initial access to the company’s infrastructure is a normal user-management operation that an administrator must complete.

A temporary link (auth link) that enables the user to access and setup 2FA is provided when 2FA is enabled on the mailstore in order to allow new users to login instantly.
From the Administration GUI, administrators may quickly create an authentication link:
  1. Click the Create a temporary link button in the user’s General Information section’s Temporary link box.
  2. A URL link will appear in an overlay window, and by selecting the button next to it, you may copy it.
  3. The new user can then be emailed the URL.
  4. Before the link expires, the user has 12 hours to access the mailbox.
Corner Cases of 2FA 2FA is a common approach that relies on a temporary token (often in the form of a QR code) in addition to the standard user/password combination to give users a secure login to an infrastructure.

However, 2FA cannot be utilised in the following situations: If an application wants or needs to utilise the SMTP service but the domain or mailstore has 2FA enabled, the application will not function since SMTP does not allow 2FA.
On Carbonio, an Administrator can establish the proper credentials that can be used by the application to function properly. This can be done to prevent situations like this from occurring, which may include any service or protocol not supporting 2FA (such, for example, the above-mentioned SMTP or SOAP).

Credential administration
A credential within Carbonio is anything that grants usage of one of its services or modules.

The Credential Management system of Carbonio Auth enables the creation of unique passwords for a variety of services, including IMAP/SMTP, EAS devices, and mobile applications (such as Carbonio Files and Carbonio Chats).
Without having to disclose the password, it is also feasible to grant access to a service to other coworkers, team members, or even unaffiliated individuals by simply developing a new authentication method (such as a QR code for mobile access). When access for these individuals is no longer required, it is sufficient to remove the authentication method to revoke access.

Additionally, this suggests that users may control who has access to the same services they do, offering a high degree of granularity also at the user level.

The duties that an administrator can perform are demonstrated in the remaining portions of this section, along with a few examples.
Services Provided
For the following services, Zextras Auth enables the creation or updating of bespoke passwords:
Administrators may set up a variety of simple to complicated situations by combining various services, such as:
  • disable all but WebAccess
  • disable SMTP and enable IMAP
  • only for managed clients (pre-setup without the user) should IMAP/SMTP be enabled.
  • Create SMTP passwords for automation or external services that are not enabled for Web, Soap, or IMAP access.
In this part, we give a few illustrations.
  1. For user who can use service EAS (mobile password), setup a password and a label.
  • created: 0 indicates that the credential was indeed randomly generated, while 1 indicates that it wasn’t.
  • created – the timestamp of creation
  • label – The label is helpful for recalling the credentials’ intended usage or owner.
  • ID is required to add or update the credentials since it is unique. To avoid confusion, it is referred to in the instructions as password_id.
  • the services to which access is permitted
  • the hashed credential itself, or hash
  • enabled – Whether or not the credential may be used in reality.
  • algorithm: the used hashing algorithm
  1. password – the secret phrase chosen or produced at random. As previously stated, this is the only time the administrator has access to a user’s password.
  2. For, create a password that can only be used for web access (both ClassicUI and Zextras Login Page).
  3. Make an IMAP and POP3-only password for (no SMTP) for this account.
  4. For, create a password.Using a credential, SMTP for an external client can be enabled.
  5. If QR code support has been enabled, the qrcode argument is crucial for creating new QR codes that can be utilised by mobile devices. When used with the –json option, it will also display the payload of the QR code. Among them is: