Multi Tenancy Configuration
A single Opencast instance can handle multiple tenants, each of which have their own recordings in the system. Opencast refers to tenants as organizations, and an HTTP request to the Opencast installation is mapped to an organization using the server name. Therefore, a Opencast instance will usually be set up with multiple DNS names pointing to the same IP, for example:
should all resolve to the same IP.
A tenant configuration thus consists mainly of the DNS name that is mapped to that tenant.
Out of the box, Opencast has one tenant configured, called
mh_default_org that is mapped to the server name
localhost:8080. As long as there is one tenant configuration only, Opencast will map every request to that tenant
regardless of the server name. As soon as a second tenant configuration is available, requests will be mapped to
organizations using the server name, and an HTTP status code 404 will be returned for requests that hit the Opencast
installation that cannot be mapped to any organization.
Multi tenancy in Opencast is working, however it is not fully finished. Certain objects are still shared amongst organizations, most notably RSS/Atom feeds and encoding profiles.
Adding A Tenant
To add a tenant to the installation, two things need to be put in place: a tenant configuration and a set of security
rules. For this example we have a three node install of
presentation.example.org. Assume that the new tenant is called
tenant1 and should be mapped to
Step 1: Tenant Configuration
Create a file called org.opencastproject.organization-tenant1.cfg in the
etc/ directory of your Opencast
installation, on each of the nodes. As an example, this is what the admin node looks like:
# Hostname URL mapping
# Admin and Presentation Server Urls
# Default properties for the user interface
There are more options available than in this example. The easiest way of creating that file is probably to create a
copy of the already existing
Note, the default organization file
org.opencastproject.organization-mh_default_org.org must refer to the actual
This file sets the default organization that is selected. This is currently required because some Opencast components do not support multitenancy.
Hosts can have different schemas (http / https) and port numbers, e.g. when you run behind proxy server. Note, that the combination of hostname and port number is uniquely mapped to an organization.
It is not supported for Opencast tenants to be hosted in a subpath. Opencast tenants needs to be served from the root path element. The RFC 3986 URI path component needs to be empty.
Step 2: Security Configuration
Create a file called tenant1.xml in /etc/security. This file specifies access rules for individual URLs that specify which roles are needed in order to access a given URL. In addition, it allows to define the directory services that are used to authenticate users. The file follows the standard ways on configuring Spring Security and you are free to add anything that can go into a Spring Security configuration.
The easiest way of creating that file is probably to create a copy of the already existing
Step 3: Other Configuration
Two additional files should be copied:
should be copied to
org.opencastproject.ui.metadata.CatalogUIAdapterFactory-series-common.cfg should be copied to
In each of the new configuration files, change
organization key to match the tenant id, and change the
common-metadata key to false. Create a copy of the files for each tenant. Note: The original
must have their
common-metadata keys set to true, otherwise metadata will only be available in one tenant and you
will experience a number of odd errors.