Control Panel
v3.5
ONLYOFFICE Control Panel changelog
Version 3.5.2
Release date: 02/29/2024
- Added the ability to restrict access rights to the application files for the Others group.
- Fixed issue with redirect to the portal main page when opening Control Panel after a day on Ubuntu 22.10.
- Fixed retrieving data error when opening the backup page.
- Fixed issue when backup with Mail is not performed after disabling and enabling encryption (added text about stopping services and the instruction to the Help Center).
- Fixed issue when features are not saved to the new tariff when setting a quota for the portal.
- Edited sources build.
Version 3.5
Release date: 03/14/2023
- Changed API methods for migration, implemented progressQueue.
- Changed settings for connecting third-party storages. Added tooltips for fields. Added the 'Server Side Encryption Method' block for Amazon AWS S3.
- Added logos for dark theme in the Branding section. Logos for the About page are now separate fields in the Advanced tab.
- Added the ability to set the portal memory quota.
Version 3.1.1
Release date: 08/08/2022
- Fixed issue with file indexing.
- Fixed elasticsearch container errors when updating ONLYOFFICE Groups.
- Fixed issue with brand logos after updating in the Docker installation.
- Fixed texts and layout for the Migration feature.
Version 3.1
Release date: 05/25/2022
- Added the Data Import page that allows to import data from Nextcloud, ownCloud and GoogleWorkspace to ONLYOFFICE Workspace.
- Moved Elasticsearch to a separate container.
- Fixed bugs.
Version 3.0
Release date: 06/07/2021
- License agreement dialog when installing docker components added.
- The inactive button with an action for uninstalled components (downloading and installing the available version) fixed.
- Indexing progress display added.
- New checks when restoring data from a local or a 3rd party storage.
- SSOAuth was removed from Control Panel. It's now available as a portal setting in Community Server.
- Bugs 47721, 49101, 49187, 49273, 49272, 49324, 46386, 49585 from the internal bugtracker fixed.
- 3rd party licenses and copyright updated.
Version 2.9.1
Release date: 12/10/2020
- Bug Fixes & Performance Improvements.
Version 2.9
Release date: 10/14/2020
- Control Panel is available in the free Community version with all settings excepting the editors logo replacement;
- Added the vsyscall check to the installation scripts when installing Mail Server on Debian with kernel 4.18.0 and later;
- Redesign of the navigation menu: added Common and Portal settings sections, added icons to menu items;
- Added the advanced rebranding page in the Common Settings;
- Added the possibility to reindex the full-text search;
- Updated
node.js, updated packages (transition to samlify for SSO);
- Added the Encryption at rest block in the Storage section;
- Added the Private Room section for the server version only;
- Added the
upgrade page with a proposal to upgrade to Enterprise Edition;
- Added the
activate page with a possibility to upload a license file;
- Added the HideAuthPage option to the SSO settings to hide the authorization page. When the HideAuthPage option is enabled, an automatic redirect from the authorization page to the SSO service will occur.
- Added the Sign in to domain option on the authorization page.
- Transition to the new
samlify library;
- Added the HideAuthPage option to the SSO settings to hide the authorization page. When the HideAuthPage option is enabled, an automatic redirect from the authorization page to the SSO service will occur.
Version 2.7
Release date: 04/25/2019
- Added more fields mapped for the users loaded via LDAP: user photo, birthday, contacts, primary phone number;
- Added the setting to autosync LDAP on schedule;
- Added the possibility to give administrator rights to the user group at the portal via LDAP;
- Updated the rules for LDAP users.
Version 2.5.1
Release date: 04/07/2018
- Fixed the
Server internal error error when using the groups enclosed inside each other in the AD (bug #37414).
- Fixed the issue when the user data between the Service Provider and the portal was transferred via HTTP only, even when HTTPS was enabled.
Version 2.4.0
Release date: 01/13/2018
- Fixed the
Invalid ssoConfig error which occurred when the link to the IdP contained the question mark '?', e.g.: IdP Single Sign-On Endpoint URL: https://accounts.google.com/o/saml2/idp?idpid=777777;
- Fixed the
Invalid authentication token error which prevented from adding a user to the portal using the AD FS, in case the + or - characters were present when sending the encrypted data.
Version 2.3.0
Release date: 12/15/2017
- Added the changelog for Control Panel and link to it;
- Fixed the bug when JWT parameters were not sent when updating Document Server(bug #36270);
- Fixed the bug when
Audit Trail heading was present at the login history page (bug #36026);
- The current machine is now checked for being linked with the domain name for multiple portals.
- Fixed the bug with the
LDAP Domain not found error which occurred if the DN record had no DC records (the users with Sun/Oracle DS were affected); now if the LDAP domain could not be specified, the LDAP domain will acquire the unknown value or the ldap.domain value from the web.appsettings.config configuration file;
- Fixed the bug with the
Sizelimit Exceeded error when trying to get more than 1000 users from the Active Directory;
- Increased the login speed with the Group Membership setting enabled;
- Added additional logging;
- Fixed the bug with LDAP operation hanging when using Mono v5.2.0 and older;
- Fixed the bug with the error when trying to login using the email address entered in the fields different from the
Mail Attribute;
- Fixed the bug occurring in the enclosed groups, when the users were displayed not in all groups.
Version 2.2.0
Release date: 10/31/2017
- Added the
documentserver-prepare4shutdown.sh script launch when updating the document-server for the correct edited document saving.
- Dramatically changed LDAP integration, migrated to the single library for the work with LDAP (Novell.Directory.Ldap.NETStandard, Nuget, MIT);
- Login and email are now split into two separate fields;
- Added the support for big data;
- Increased the work speed via the LDAP protocol (the connection to the server and receiving the data is now made once per session, added the limits when only a certain number of results is necessary, fixed the slow login for bit data, removed the sorting out used to find the SID parameter);
- Fixed the user re-creation issue;
- Fixed the duplicate username issue;
- Fixed the already existing email issue;
- Replaced the LDAP user deletion with account deactivation (for further data migration and data safety);
- Instead of re-creating a user with an unknown SID but an existing email the data is updated;
- Added the attempt to save the correct UserName/Login in case a similar one is already taken on the portal.
- Added the AD FS support;
- Replaced the Single Sign-on link at the authorization page with the customizable button, added the button customization to the SSO setting of the Control Panel.
Version 2.1.0
Release date: 07/03/2017
- Added the support of letsencrypt service for the domain certificate generation.
- Added the new
sso.auth service;
- Added the new SSO settings page;
- Added the support for Shibboleth.
Version 2.0.0
Release date: 05/25/2017
- The Control Panel migrated from
MVC to Node.js.
Version 1.6.0
Release date: 12/05/2016
- Added LDAP synchronization for users and groups when saving the settings, after login and using the Sync button;
- Changed email formation for LDAP users;
- Fixed the problem of creation of users with invalid emails;
- Fixed the problem of duplicate users;
- Added icons and hints to the users in the list for the admin;
- Blocked for editing the user profile fields imported using LDAP;
- Added the real LDAP password saving to the database during login in case LDAP Auth is disabled, now the LDAP users will become common portal users when LDAP Auth is disabled;
- Added new API Settings method - Sync LDAP;
- Added new translations;
- Bug fixes.
- Made changes at the Update page for the Control Panel for Windows;
- Updates are performed using the downloaded installation packages for each module.
- The current installed component version numbers are obtained via API request to the Community Server.
- The new versions available for download are obtained via the request to the https://download.onlyoffice.com/install/windows/updates.txt file, where all the latest component version numbers and links for their download are stored in the JSON format.
Introduction
The Single Sign-on feature provided by the Control PanelIf your SaaS service plan stipulates it, the Single Sign-on section allows you to enable third-party authentication using the installed SSO services (Shibboleth, OneLogin, or Active Directory Federation Services).SAML, thereby providing a more quick, easy and secure way to access the portal for users.
Generally, the Single Sign-on technology allows users to sign in only once and then get access to multiple applications/services without re-authentication. E.g. if a web portal includes several large independent sections (forum, chat, blogs etc.), a user can undergo the authentication procedure within one of the services and automatically get access to all other services without entering credentials several times.
SSO is always ensured by the joint operation of two applications: an Identity Provider and a Service Provider (hereinafter referred to as "IdP" and "SP").
ONLYOFFICE SSO implements the SP only. A lot of different providers can act as an IdP, but ONLYOFFICE has been tested with the following services only: Shibboleth, OneLogin and AD FS.
Using SSO authentication you get the following main benefits:
- Increased convenience. Users obtain a more quick and easy way to access the portal without the necessity to memorize multiple passwords and logins.
- Enhanced security. ONLYOFFICE does not store user passwords in any form, instead of that it uses the results of the authentication on the Identity Provider side.
- Easy administration. All the necessary user information is transmitted through an authentication token. If the user information changes on the Identity Provider side, it will be automatically updated on the portal during the next SSO authentication. If a user profile does not exist on the portal, it will be created automatically when the user signs in to the portal using the SSO credentials for the first time.
In ONLYOFFICE, SSO authentication is implemented on the base of the secure and commonly used SAML standard. SAML (Security Assertion Markup Language) is an XML standard that allows to transmit user authentication/authorization data between an Identity Provider and a Service Provider through security tokens which contain assertions.
This article describes the process of enabling SSO in general. If you search for specific settings/examples for certain IdPs, please refer to our articles on how to configure ONLYOFFICE SP and Shibboleth, OneLogin, or AD FS IdPs.
Enabling SSO
To enable and configure SSO authentication for your portal, you need to perform the following two main steps:
- Register your Identity Provider at the ONLYOFFICE Control Panel -> SSO page. The information you should specify can be found in your Identity Provider account.
If you want to use SSO when connecting ONLYOFFICE Desktop Editors to your ONLYOFFICE Workspace, disable Private Rooms in the Control Panel.
- Register ONLYOFFICE as a trusted Service Provider in your Identity Provider account. This procedure differs depending on the selected Identity Provider.
Each portal can only be integrated with one Identity Provider at the same time.
Registering your Identity Provider in the ONLYOFFICE Service Provider
To register your IdP in ONLYOFFICE SP, use the ONLYOFFICE SP Settings section of the SSO page.
An Identity Provider (IdP) is a service that creates, maintains and manages user identity information and provides user authentication to other Service Providers within a federation. Such services as OneLogin, ADFS etc. act as Identity Providers. A Service Provider (SP) is an entity that provides web services and relies on a trusted Identity Provider for user authentication. In our case, the Service Provider is the ONLYOFFICE.
You can enable SSO on the base of SAML for the authentication/authorization data exchange between an Identity Provider and a Service Provider:
- SAML (Security Assertion Markup Language) - an XML standard that allows to transmit user authentication/authorization data between an identity provider and a service provider through security tokens which contain assertions.
Enhanced security is enabled by means of the fact that the online office does not store user passwords, instead of that it uses the results of the authentication on the Identity Provider side. All the necessary user information is transmitted through an authentication token. If the user information changes on the Identity Provider side, it will be automatically updated on the portal during the next SSO authentication (note that the data can only be synchronized in one direction: from the Identity Provider to the online office).
After the Identity Provider and the online office are mutually configured to ensure SSO, the user SSO authentication process will be performed on the Identity Provider side. The online office will receive an authentication token (SAML) from the Identity Provider. After the token is validated (by using digital signatures and the token lifetime), the online office allows the user to access the portal.
Enabling SSO
To enable and configure SSO authentication for your portal, proceed as follows:
Check the Identity Provider configuration before adjusting the Service Provider.
- On your ONLYOFFICE portal, go to the Control Panel and open the SSO page in the PORTAL SETTINGS section on the left sidebar.
Go to the portal Settings page. To do that, click the
icon in the right upper corner.
- In the Integration section in the left sidebar, click the Single Sign-on link.
- Click the Enable Single Sign-on Authentication switcher.
Turn on the Enable Single Sign-on Authentication switcher under the Single Sign-on caption.
- Fill in the required fields in the ONLYOFFICE SP Settings section. The necessary information can be specified in several different ways:
- Enter the URL address to the metadata file. If your IdP metadata is accessible from outside by the link, insert the link into the URL to IdP Metadata XML field and click the Load dataarrow button to load data. When the data is loaded, all the required parameters will be automatically displayed in the extended form.
- Upload the metadata file. If your IdP provides a metadata file, use the Select file button to browse for the file stored on your local machine. When the file is uploaded, all the required parameters will be automatically displayed in the extended form.
- Specify the required parameters manually. If the metadata file is not available, enter the necessary parameters manually. To obtain the necessary values, please contact your IdP administrator.
The following parameters are available:
- IdP Entity Id (obligatory field) - the Identity Provider identifier or URL address which will be used by the Service Provider to unequivocally identify the IdP.
https://example.com/idp/shibboleth
where example.com is your SSO service domain name
- IdP Single Sign-On Endpoint URL (obligatory field) - the URL used for the single sign-on on the Identity Provider side. It is the endpoint address in your IdP to which SP sends authentication requests.
Set the necessary Binding type selecting one of the corresponding radio buttons. Bindings specify the way in which authentication requests and responses are transmitted between the IdP and SP over the underlying transport protocol: using the HTTP POST or HTTP Redirect binding.
- IdP Single Logout Endpoint URL - the URL used for the single logout on the Service provider side. It is the endpoint address in your IdP to which SP sends logout requests/responses.
Set the necessary Binding type selecting one of the corresponding radio buttons. Bindings specify the way in which logout requests and responses are transmitted between the IdP and SP over the underlying transport protocol: using the HTTP POST or HTTP Redirect binding.
- NameId Format - the NameID parameter allows SP to identify a user. Select one of the available formats from the list.
It's possible to customize the button used to login to the portal with the Single Sign-on service at the ONLYOFFICE authentication page. You can do it using the Custom login button caption field in the ONLYOFFICE SP Settings section.
You can also add the IdP and SP certificates.
IdP Public Certificates
IdP Public Certificates - this section allows you to add the Identity Provider public certificates used by the SP to verify the requests and responses from the IdP.
If you have loaded the IdP metadata, these certificates will be added to the Control Panelyour portal automatically. Otherwise, the certificates can be found in your IdP account. To add a certificate manually, click the Add certificate button. The New Certificate window opens. Enter the certificate in the Public Certificate field and click the OK button.
Set additional parameters for certificates checking the corresponding boxes.
Specify which signatures of requests/responses sent from IdP to SP should be verified:
- Verify Authentication Response SignatureVerify Auth Responses Sign - to verify signatures of the SAML authentication responses sent to SP.
- Verify Logout Request SignatureVerify Logout Requests Sign - to verify signatures of the SAML logout requests sent to SP.
- Verify Logout Response SignatureVerify Logout Responses Sign - to verify signatures of the SAML logout responses sent to SP.
Select the necessary algorithm from the Default Signature Verification AlgorithmDefault Sign Verifying Algorithm list: rsa-sha1, rsa-sha256 or rsa-sha512.
Default settings are used only in cases if the IdP metadata does not specify which algorithm should be used.
You can edit or delete the added certificates using the corresponding link.
SP Certificates
SP Certificates - this section allows you to add the Service Provider certificates used to sign and encrypt the requests and responses from the SP.
If your IdP requires that input data is signed and/or encrypted, create or add corresponding certificates in this section.
Click the Add certificate button. The New Certificate window opens. You can generate a self-signed certificate or add an existing certificate in the Public Certificate field and the corresponding private key in the Private Key field. In the Use for list, select one of the available options: signing, encrypt, signing and encrypt. When ready, click the OK button.
Depending on the certificate purpose selected in the Use for list when uploading/generating the certificate, the certificate additional parameters are specified. The following parameters define which requests/responses sent from SP to IdP should be signed:
- Sign Authentication RequestsSign Auth Requests - to have SP sign the SAML authentication requests sent to IdP.
- Sign Logout Requests - to have SP sign the SAML logout requests sent to IdP.
- Sign Logout Responses - to have SP sign the SAML logout responses sent to IdP.
If you have selected the encrypt or signing and encrypt option in the Use for list, the Decrypt Assertions parameter is also checked. The decryption is performed using the corresponding Private Key.
Select the necessary algorithms from the lists:
- Signing Algorithm:
rsa-sha1, rsa-sha256 or rsa-sha512.
- Default Decryption AlgorithmDefault Decrypt Algorithm:
aes128-cbc, aes256-cbc or tripledes-cbc.
You can edit or delete the added certificates using the corresponding link.
Attribute Mapping
Attribute Mapping - this section allows you to set the correspondence of the fields in the ONLYOFFICE People module to the user attributes which will be returned from the IdP. When a user signs in to the ONLYOFFICE SP using the SSO credentials, ONLYOFFICE SP receives the required attributes and populates the full name and email address fields in the user account with the values received from the IdP. If the user does not exist in the People module, it will be created automatically. If the user information has been changed on the IdP side, it will be updated in SP as well.
The available attributes are:
- First Name (obligatory field) - an attribute in a user record that corresponds to the user's first name.
- Last Name (obligatory field) - an attribute in a user record that corresponds to the user's second name.
- Email (obligatory field) - an attribute in a user record that corresponds to the user's email address.
- Location - an attribute in a user record that corresponds to the user's location.
- Title - an attribute in a user record that corresponds to the user's title.
- Phone - an attribute in a user record that corresponds to the user's phone number.
Advanced Settings
The Hide auth page option allows you to hide the default authentication page and automatically redirect to the SSO service.
ImportantIf you need to restore the default authentication page (to be able to access the portal if you your IDP server fails), you can add the /Auth.aspx?skipssoredirect=true key after the domain name of your portal in the browser address bar.
When all the settings are specified in the Control Panelyour portal, click the Save button. The ONLYOFFICE SP Metadata section will open.
Registering ONLYOFFICE as a trusted Service Provider in your Identity Provider
Now you need to add ONLYOFFICE as a trusted Service Provider in your IdP account specifying the ONLYOFFICE SP metadata in the IdP.
To receive necessary data, refer to the ONLYOFFICE SP Metadata section of the SSO page. Verify that the SP data is publicly accessible. To do that, click the Download SP Metadata XML button. The XML file contents will be displayed in a new browser tab. Save the data as an XML file to be able to upload it to the IdP.
Alternatively, you can manually copy separate parameters clicking the Copy to clipboard button in the corresponding fields.
The following parameters are available:
- SP Entity ID (link to metadata XML) - the Service Provider XML URL address which can be downloaded and used by the Identity Provider to unequivocally identify the SP. By default, the file is located at the following address: http://example.com/sso/metadata where example.com is your ONLYOFFICE portal domain name or public IP.
- SP Assertion Consumer URL (support POST and Redirect binding) - the Service Provider URL address where it receives and processes assertions from the Identity Provider. By default, the following address is used: http://example.com/sso/acs where example.com is your ONLYOFFICE portal domain name or public IP.
- SP Single Logout URL (support POST and Redirect binding) - the URL used for the single logout on the Identity Provider side. It is the endpoint address in your SP where it receives and processes logout requests/responses from the Identity Provider. By default, the following address is used: http://example.com/sso/slo/callback where example.com is your ONLYOFFICE portal domain name or public IP.
These parameters and XML contents differ depending on you portal configuration, e.g. if you switch your portal to HTTPS or specify a domain name, the parameters will also be changed and you will need to reconfigure your IdP.
Logging in to the ONLYOFFICE SP
After the SSO is enabled and configured, the logging in process is performed in the following way:
- A user requests access to ONLYOFFICE by clicking the Single Sign-on button (the caption may differ if you have specified your own text when configuring ONLYOFFICE SP) at the ONLYOFFICE portal Authentication page (SP-initiated SSO).
- If all the IdP and SP settings are set correctly, ONLYOFFICE sends the authentication request to the IdP and redirects the user to the IdP page where he/she is asked for credentials.
- If the user is not already logged in to the IdP, he/she provides credentials in the IdP.
- IdP creates the authentication response that contains user data and sends it to ONLYOFFICE.
- ONLYOFFICE receives the authentication response from the Identity Provider and validates it.
- If the response is validated, ONLYOFFICE allows the user to log in (the user will be created automatically if missing, or the data will be updated if changed in the IdP).
It's also possible to use the sign-in page on the Identity Provider side (IdP-initiated SSO), enter credentials and then access the ONLYOFFICE portal without re-authentication.
Logging out from the ONLYOFFICE SP
Logout can be made using 2 available ways:
- From the ONLYOFFICE portal using the Sign Out menu (in this case the request will be sent from IdP to logout). The user should also be automatically logged out from the IdP in case he/she is logged out from all other applications previously accessed via SSO authentication.
- From the IdP logout page.
Editing user profiles created using SSO
The users created using the SSO authentication are marked with the SSO icon in the user list for the portal administrator.
The possibility to edit such user profiles in the People module is restricted. The user profile fields that have been created using the SSO authentication are disabled for editing from the People module. The user data can be changed on the IdP side only.