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 example.com, 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 https://my-saml-provider.org/simplesaml/saml/idp/metadata.php, 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 https://mycompany.okta.com/app/test/app_id/slo/saml 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:
- When you are logged in, go to the IDP portal and select the resource you wish to use.
- Visit the service’s website directly, and then click the SAML LOGIN button that displays next to the username and password boxes.
- Use the direct URL to the service’s SAML authentication. For instance, if you have a Carbonio installation (the Service) at mail.example.com, you may access the mailbox by clicking the URL https://mail.example.com/zx/auth/startSamlWorkflow?redirectUrl=https://mail.example.com/carbonio/mails provided you are already connected to the IDP.
Configure SAML on Azure, for instance.
- Click the Create a temporary link button in the user’s General Information section’s Temporary link box.
- A URL link will appear in an overlay window, and by selecting the button next to it, you may copy it.
- The new user can then be emailed the URL.
- Before the link expires, the user has 12 hours to access the mailbox.
- 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.
- For user email@example.com 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
- 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.
- For firstname.lastname@example.org, create a password that can only be used for web access (both ClassicUI and Zextras Login Page).
- Make an IMAP and POP3-only password for email@example.com (no SMTP) for this account.
- For firstname.lastname@example.org/SMTP_Service, create a password.Using a credential, SMTP for an external client can be enabled.
- 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: