BlueSpice at Enterprise Scale
Technical briefing for the Lead Architect and the DevOps/Operations team evaluating the operational implications of running BlueSpice Farm at a scale of approximately 10,000 sub-wikis.
Wiki farm is an architecture for BlueSpice wikis that can be used to centrally manage multiple wikis. Wikis can be created, cloned, deleted, and suspended. An administrative interface is provided for this purpose. The architecture also facilitates the maintenance of the wikis, since all wikis in the farm can be updated simultaneously. This functionality is provided by the extension BlueSpiceWikiFarm.
Farm administration
Terminology
- Wiki farm: A group of wikis with the same code base that is managed from the root wiki of the farm.
- Root wiki: The wiki that is used as administration interface for all wiki instances.
- Wiki instance: A single wiki in the farm.
- Source wiki: A wiki that provides the content for pre-filling a new wiki. Any wiki instance in the farm can be used to clone it as the source wiki for a new wiki instance.
Access
The individual wiki instances are managed on the page Special:FarmManagement in the root wiki.
This page can be accessed from the menu Global actions v5.1.2+.
In the list of all special pages (Special:SpecialPages) you can find the farm management in the section Other special pages.
The farm management displays a complete list of all existing wiki instances with information about:
- Site name (links to the wiki)
- Globally searchable: Makes the wiki available to interwiki search between all wiki instances.
- Date of creation
- Keywords (meta information)
- Description (meta information)
The list is filterable and sortable.
Features
In the administrative interface you can:
- Create a wiki
- Clone a wiki
- Remove a wiki
- Suspend a wiki (archive)
- Exclude a wiki from interwiki search
- Add meta information for each wiki
Create a wiki
Using the button Create Wiki, you create a new wiki instance:
- Enter a site name
- Click OK.
Creating a wiki instance
The individual wiki instances need a unique URL to make it accessible in the browser. This is automatically generated from the entered site name.
An example:
The WikiFarm is accessible at the URL https://wiki.bluespice.com.
While creating the wiki instance, the site name "hallo welt" has been chosen. Due to this, the following path - and therefore also the URL - of the new wiki instance will be generated:
https://wiki.bluespice.com/hallo-welt
Clone a wiki
To clone a wiki, you select an already created wiki as a source. Clicking on the list entry marks the selected wiki and activates the Clone Wiki button. In the dialog window, you can enter a site name and change the path (optional).
In contrast to creating a new wiki, content and data will already be transferred during the cloning process. All articles, users, settings, namespaces, etc. are copied to the new wiki. This is, therefore, a one-to-one copy of the source wiki. This makes it possible to create master wikis, pre-fill and easily duplicate them as needed.
Remove a wiki
Deleting a Wiki is easy: just select a wiki in the list, click on the button "Remove Wiki" and the corresponding dialogue will open. Only the path to the wiki needs to be entered here. This corresponds to the name of the wiki instance as it is listed in the farm manager. Enter this in the correct notation (delimiter, uppercase and lowercase) in the field and confirm with OK. The wiki will be deleted completely.
Suspend a wiki (archive)
If you do not want to delete a wiki directly, but want to keep the contents for a while, you can also suspend and therefore archive it. The shutdown causes that the wiki becomes unavailable. When trying to access it via the URL, you will be redirected to the farm management.
Suspended wiki instances remain in the list of the farm management, but they are crossed out and the site name no longer links to the instance.
Adding meta information
The individual wikis can be described with additional metadata using the button Edit wiki meta. The following meta information can be provided:
- Description
- Group
- Keywords
If there is any information from other wikis in group and keywords, this information can be selected in a drop-down menu.
Thedescription and the keywords will be displayed as additional information in the list of the farm manager. This makes them filterable and sortable. The group is different to these information, because it is just a grouping of the wikis in the list. The groups can be expanded and collapsed.
Creating new groups and keywords
Groups and keywords are created directly in the dialog window for entering meta information of a wiki instance.
- Group: If you need a new group for a wiki instance, enter the name in the text field and click Done.
- Keyword: If you want to create a new keyword, enter the keyword in the text field and finish it with a comma. Then click done.
Valid site names and paths
When creating and cloning a wiki, you can also use spaces or umlauts when entering the site name. Spaces are automatically converted to hyphens and umlauts according the right notation, e.g. "Ü" to "ue". Also upper and lower case is possible and is taken into account.
When removing a wiki instance, the system is not as tolerant. The input must match one-to-one with the path specification so that the wiki can be deleted.
Logs
All actions are stored in a logfile so that they can be tracked.
Authentication
In addition to standard authentication directly within the wiki, a "Comfort Sign-on" (single sign-on) option is available. There are differences in this regard between on-premise installations and cloud deployments. SAML (Security Assertion Markup Language) or OIDC (OpenID Connect ) can be used as the IdP (Identity Provider).
Graphical comparison: SAML vs. OIDC
SAML
With SAML, there is a single central trust relationship between the farm as a whole and the IdP—rather than one per individual wiki:
- The farm itself acts as a single Service Provider, accessible via a shared endpoint (
/sp/). This SP exchanges metadata (certificates, endpoint URLs) with the IdP to establish the trust relationship. - The individual wikis (
/wiki1/,/wiki2/,/wiki3/) hook into this single Service Provider; they do not have their own SAML configuration or their own trust relationship with the IdP. - In practical terms, this means that one SAML configuration in
simplesamlphp(or in the central farm configuration) suffices for all wikis in the farm. While it is technically possible to connect a second IdP (labeled "IdP2, not in Cloud" in the diagram), this is considered a special case and can only be implemented in on-premise environments. Fundamentally, SAML is designed to support one IdP per farm.
OIDC
The situation differs with OIDC: here, each wiki registers individually as a separate OAuth/OIDC client with the IdP:
- Wiki 1, Wiki 2, and Wiki 3 each have their own trust relationship and typically their own client configuration (Client ID/Secret, Redirect URI) with the IdP—marked in the diagram as "individual config."
- Multiple IdPs can also be connected in parallel (in the diagram: IdP1 for Wikis 1–3, IdP2 additionally for Wiki 3).
- Consequence: There are two login buttons if a wiki is connected to two IdPs, and there is no automatic single sign-on across the entire farm. Users must actively choose a login button for each wiki (or IdP), unless a session already exists.
- A "shared" configuration is only possible with OIDC if the IdP supports wildcarding for the redirect URL (i.e., it accepts a pattern URL like
https://*.wiki.example.com/callbackinstead of requiring an exact redirect URI to be stored for each wiki individually). If the IdP does not support this, each wiki requires its own redirect URI, manually configured within the IdP.
| Criterion | SAML | OIDC |
|---|---|---|
| Trust model | Centralized: one SP for the entire farm, one trust relationship with the IdP | Decentralized: individual client registration per wiki instance |
| Multiple simultaneous IdPs | Uncommon / additional effort (secondary IdP support is limited); Not possible in the cloud | Well supported; different IdPs per wiki are also possible |
| Shared config across all wikis | Easily achievable due to central server-side configuration | Only possible if the IdP supports redirect URL wildcarding |
| Effort for a new wiki instance | No additional effort on the IdP side – the new wiki utilizes the existing farm SP/trust | IdP must explicitly accept the new instance (issuer/client configuration on the IdP side) – unless redirect URL wildcarding is used |
| Login experience | Unified login across the entire farm (a single trust suffices) | Potentially multiple login buttons; no automatic farm-wide single sign-on |
| Administrative effort for many wikis | Low (centralized) | Increases with the number of wikis/IdPs (individual configuration) |
| Typical use case | Single corporate IdP, classic enterprise SSO | Cloud IdPs (e.g., Azure AD, Okta), heterogeneous IdP landscape |
Comparison of Comfort Sign-On options: On-premise vs. Cloud
| Login method | On-premise | Cloud |
|---|---|---|
| SAML | Multiple identity providers possible | Only 1 identity provider for all instances |
| OpenID Connect | Different identity providers usable
(centrally configurable) |
Different identity providers usable
(must be configured separately in each instance) |
| User session | Shared user session possible | No shared user session; separate login required for each instance |
Related info
