Enterprise-Only Authentication Options
Introduction
ownCloud provides several authentication options for mounting storages. Depending on the edition, these options can vary.
Authentication Options
The following table shows which authentication option is available for which edition of ownCloud.
Authentication Method | Free Edition | Enterprise Edition |
---|---|---|
Username and password |
x |
x |
Log-in credentials, save in session |
x |
x |
Log-in credentials, save in database |
x |
|
User entered, store in database |
x |
|
Global credentials |
x |
|
Credentials hardcoded in config file * |
x |
|
Kerberos |
x |
|
RSA public key ** |
x |
x |
(*) Note that Credentials hardcoded in config file
will appear only if the Windows Network Drive (WND) app is installed and enabled. As long you have WND enabled, you can also use this authentication method for other mount types. If you use this authentication method with other mount types but disable WND, you will lose the connection to all the mounts where this authentication method was used.
(**) Note that RSA public key
is only available when selecting mount type SFTP
.
Use the dropdown selector to choose the authentication backend when you create a new external mount.
Storage Implementations
The following table shows which storage implementation can use the above authentication options. Note that this table does not cover other storage implementations like Google Drive or One Drive etc., as those use other authentication backends.
Storage implementation | Free Edition | Enterprise Edition |
---|---|---|
FTP |
x |
x |
SFTP |
x |
x |
ownCloud |
x |
x |
SMB/CIFS |
x |
x |
WebDAV |
x |
x |
Windows Network Drive |
x |
Authentication Option Details
- Log-in credentials, save in session
-
Credentials are only stored in the session and not captured in the database. Files cannot be shared, as credentials are not stored.
- Log-in credentials, save in database
-
Credentials are stored in the database, and files can be shared.
- User entered, store in database
-
Users provide their own login credentials, rather than using admin-supplied credentials. User credentials are stored in the database, and files can be shared.
- Credentials hardcoded in config file
-
Used when all the users will share the same password and the password is not known to the users like for a shared space. The user ID is always taken from the session. This authentication option can also be chosen when using OAuth or OpenIDConnect, etc. For more details see Notes for Credentials Hardcoded in Config File. Files can be shared.
- Global credentials
-
With re-usable credentials entered by the admin, files can be shared based on credentials only the admin has knowledge about. Credentials are entered in a separate form via
(global) or (personal). - Kerberos
-
With Kerberos authentication, users get authenticated via Kerberos tickets. ownCloud needs a Kerberos service account enabled for delegation. ownCloud credentials are not required.
- Username and password
-
This is the default; a login entered by the admin when the external mount is created. The login is stored in the database, which allows sharing and background jobs, such as file scanning, to operate.
- RSA public key
-
This authentication method is limited to SFTP only. Manually enter the public key or press Generate in the mount form to generate one. Files can be shared.
Authentication Options Allowing Sharing
If available for sharing, the following will be shown additionally when defining the mount point:
This table shows which authentication option allows sharing:
Authentication Option | Sharing Allowed |
---|---|
Username and password |
x |
Log-in credentials, save in session |
|
Log-in credentials, save in database |
x |
User entered, store in database |
x |
Credentials hardcoded in config file |
x |
Global credentials |
x |
Kerberos |
|
RSA public key |
x |
Notes for Credentials Hardcoded in Config File
In general, when using this authentication method, the user and the password used are separated.
-
The username is the same as the
user id
of the ownCloud session.
For example, ownCloud user "Alice" with password "mysecret" (or even without password) will use "Alice" as username and the password from the config.php file to access the storage. Note that for LDAP, theuser id
is usually like 1223-cbdf-cacc-1234…, unless the configuration in the user_ldap app is changed. -
The password will be fetched from a key inside the config.php file.
For details see the section below. Even if the account doesn’t have a password like OAuth or OpenIDConnect, etc., the connection with the storage will use the password from config.php.The password will be the same for any user accessing the particular mount!
Defining key/value pairs in config.php
Key/value pairs in config.php must have the following structure:
'customApp.config' => 'the_password',
'customApp.config' => [
'server1' => 'the_first_password',
'server2' => 'the_second_password',
....
]
- customApp.config
-
The naming of this key must be a string that is valid as an array key in a PHP array like the above
customApp.config
or as another examplemy.config.key
, but not any reserved ownCloud key. - Arrays
-
You can use an array as described in the example above. When using an array, you can use as many sub-keys according your needs where the naming of the sub-key must be a string that is valid as an array key in a PHP array.
The array syntax is beneficial when having more than one server (host) with a password, but keeping them together in one master key. To access a particular sub-key in the mount definition, use the following scheme:
<key>#<sub-key-level-1>#<sub-key-level-2>...
From the example above,
customApp.config
corresponds tokey
and
server1
corresponds tosub-key-level-1
.
Value to be entered in the mount point config key
field
- Single array
-
Taking the single array example above to use the password for the mount, the value to be entered would be like:
customApp.config
- Nested arrays
-
Taking the nested array example above to use the password for the mount for the host with sub-key
server1
, the value to be entered would be like:customApp.config#server1