OSGi Configurations Manager
OSGi Configurations Manager Overview
The OSGi Configurations Manager is a Jahia module that lets administrators manage the OSGi configuration files of karaf/etc (.cfg, .yml) from the Jahia Administration.
Key Features
- File management: list, create (by hand, from a Metatype PID, or as a factory instance), delete, enable and disable (.disabled) configurations, and mark a file as the module default.
- Search: filter by name, or search the content of the files.
- Visual editor for .cfg files: Metatype-aware property picker, drag-and-drop or keyboard reordering, filter by property name or value.
- Raw editor: Monaco editor with syntax highlighting, validation and Metatype completion for .cfg and .yml files.
- Review before save: every save shows the diff of what will be written and asks for confirmation.
Security & Traceability
- Encrypted values: a property can be stored as ENC(...). Each value is bound to the configuration it was encrypted for, and decrypts in that configuration only.
- Transparent decryption for consumers: an OSGi ConfigurationPlugin hands a component its ENC(...) values decrypted, so a consumer module needs no crypto code. Declare its secrets with AttributeType.PASSWORD and read them in @Activate.
- Masked secrets: the value of a secret (a Password attribute, or a property named like password, token, secret, credential or apikey) is masked in the visual editor, the raw editor and the diff, even when it is stored in clear text, with a button to show it.
- Access control: the canManageOsgiConfigurations permission, a GraphQL API under a single namespace, and a root-only configuration for the manager itself (org.jahia.modules.osgiconfigmanager).
- File filtering: hide files with filteredFiles, or expose only allowedFiles; wildcards are supported.
- Audit logging: every sensitive action is logged with the acting username.
Developer Guide: consuming encrypted values
Do not decrypt ENC(...) values yourself: CryptoEngine.decryptString no longer reads the values written since 1.2.0. Let the manager's ConfigurationPlugin deliver them decrypted:
@Component(configurationPid = "org.example.myservice")
@Designate(ocd = MyService.Config.class)
public class MyService {
@ObjectClassDefinition(name = "My service")
public @interface Config {
@AttributeDefinition(name = "API secret", type = AttributeType.PASSWORD)
String apiSecret() default "";
}
@Activate
@Modified
void activate(Config config) {
String secret = config.apiSecret(); // plaintext, whatever is stored as ENC(...)
}
}
Declare Jahia-Depends: osgi-configurations-manager, so Jahia installs and refreshes the consumer with the manager, and receive the configuration through Declarative Services (or a ManagedService): a direct ConfigurationAdmin.getConfiguration(pid).getProperties() returns the stored values and bypasses the plugin. The README on GitHub covers the details: what happens at startup, undecryptable values, and portability between instances.
Captures d'écran
Comment installer
Installation & Configuration Guide
⚠️ Prerequisite: this module requires jContent 3.5.0 or higher.
⚠️ Upgrading from 1.1.x or earlier: back up karaf/etc first. At its first start, the manager encrypts again the existing ENC(...) values of every configuration file, for the configuration they belong to.
1. Module Deployment
- Navigate to Administration > Modules > Modules management.
- Click Upload a module and select osgi-configurations-manager-<version>.jar.
- Verify that the module status is Started.
2. Configuring Permissions
To grant access to non-root users:
- Go to Administration > Users and Roles > Roles.
- Select a server role (e.g. server-administrator).
- In the Permissions tab, locate and check canManageOsgiConfigurations.
- Click Save.
The user also needs the admin permission on /sites/systemsite, which server administrators have.
3. Root User Access
The root user has full access immediately after installation. The manager's own configuration, org.jahia.modules.osgiconfigmanager, is visible to root only.
4. Encryption Secret
Encrypted values (ENC(...)) are encrypted with a per-instance secret. By default, the manager generates one on first use and keeps it in karaf/etc/.osgi-config-manager.secret. You can set your own passphrase instead, with cryptoSecret in org.jahia.modules.osgiconfigmanager.cfg.
- On a cluster, set cryptoSecret before encrypting anything. The generated secret file stays on the node that created it, so each node would use a different key, and a value encrypted on one node could not be read on the others. The .cfg file is replicated to every node like any other configuration.
- cryptoSecret stays in clear text. It is the passphrase every other value is encrypted with, so it cannot be encrypted itself: the manager refuses to save it as ENC(...). The editors mask it on screen. Protect the file like any Karaf configuration holding credentials.
- Changing or removing it takes effect at the next restart, and values encrypted with the former passphrase can no longer be decrypted: enter them again.
- A .cfg file copied from another instance keeps its values in ENC(...) form until they are entered again, unless both instances share the same cryptoSecret.
MIT License Copyright (c) 2026 Dominique Gigon Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Dépendances
Modules dépendants
Aucun module n'en dépend.