What Java 25 does to Niagara's module permission model

Niagara 4 has a real, documented privilege model for module code, and most people who write modules have never had to look at it, because the framework asks for the permissions on their behalf. Tridium's developer documentation describes it plainly: Niagara 4 introduced the use of Java's Security Manager to restrict who may run certain sections of code, and from 4.2 onward the policy is determined by the contents of a module's own manifest, in which a module requests the permissions it needs.

Read off the bytecode, the machinery is a custom java.security.Policy subclass installed by the runtime environment, plus a hierarchy of permission-group classes in the core framework jar. There are 26 named permission groups a module may request, and the list is a reasonable index of what a module can do that matters: authentication, backups and restore, key store access, loading libraries, reflection, network communication, modifying IO streams, modifying session IDs, managing execution, shutdown hooks, setting system time, system properties, signing, reading environment variables, getting the authenticated user, database connections, MBean access, diagnostics, logging, runtime execution.

Two of those groups already require the module to be signed before the request is honoured at all. That detail matters later.

The Security Manager was deprecated for removal, then permanently disabled. On a current JVM the relevant calls behave like this — measured by running them, not read off a release note:

So the permission model has no JDK left to stand on. Not "needs porting" — the two entry points it is built on both throw.

This is the part worth being precise about, because it is the opposite of what a removal usually does. The framework-wide idiom at a check site is: fetch the security manager, and if it is not null, ask it to check a permission. On Java 8 the manager is there and the check runs. On Java 25 the manager is null, the if is false, and execution continues straight past into the guarded work.

Scanning the 4.15 module set on disk, 31 stock modules carry that pattern, and the list reads like an index of the security surface: the core framework jar, the platform layer, platform crypto, the signing service, client certificate authentication, SAML, the web and servlet layers, fox, tunnelling, backup, the cloud connectors, email, the OPC UA server, the system database, the HTTP client, and Workbench itself. Four representative examples, decompiled, guard platform initialisation, the station's signing password, the signing service, and the station's password-encryption key.

To be clear about what this is and is not: this is not a live hole in anything shipping today. Niagara 4 runs on Java 8, where the layer works exactly as documented. It is a statement about what has to be rebuilt before the framework runs on a modern JVM — and rebuilding it is the framework vendor's work, not a module author's.

A silently-skipped check at least keeps running. Two calls in the framework's own core do not: they throw where they used to return.

Both are the same call — reading the authenticated subject off the access control context. One is in the runtime environment's security utility class. The other is the core framework's session manager, in the method that answers "who is the current user". Its blast radius is the whole web and UI session stack: the web and servlet layers, bajaux, the legacy HX views, the HTTP client, backup views.

And it is documented public API for module developers. The developer documentation's own guidance on CSRF protection tells you to fetch the current session and read its CSRF token off it. Any third-party module that followed that advice throws on a Java 25 JVM — not because the module is badly written, but because it did what the documentation said.

The fix is mechanical: Subject.current() replaces Subject.getSubject(...) and works under both the old and the new scoping calls. But it is a one-line fix inside the framework's own jars, so no amount of work on a third-party module makes that call site safe. Everybody waits on the same edit.

Four practical consequences, in the order they are likely to bite.

The documented way to request privilege has no announced replacement. The published breaking-change material for the next major version says, on this subject, that the Security Manager is removed. It does not say what a module uses instead to request a permission, or what happens to a manifest that asks for one. That is the single biggest open question for anyone maintaining a module catalogue, and it is not answerable from public material.

Do not build new work on it. If a design depends on being granted a permission group, or on doPrivileged actually elevating, it depends on a mechanism with no forward path. A module that needs no permission group at all has one fewer unknown in it, and in practice a module that sticks to the old, stable part of the component and driver API needs none.

Two specific calls to stop writing now. Reading the subject off the access control context, and the session manager call above. Both have replacements that already work on Java 8, so moving off them costs nothing and removes a guaranteed failure later. Likewise, the old subject-scoping call still works but is deprecated for removal; the newer one is a drop-in.

A guess, labelled as one. Two permission groups already require a signed module, and the next major version makes a valid signature mandatory for every module. The most likely shape of the replacement is therefore signature-at-load-time rather than permission-at-call-time. That is inference, not information. The measured part is only that the current mechanism cannot work.

No licence and no pre-release access is involved, which is the point. A Niagara licence gates running Workbench and a station. It does not gate reading a jar that is already on your disk, and it does not gate running a JDK.

Three steps.

If you hold a developer membership, these are the questions whose answers are not in public material, and they are worth asking in writing:

Measured. What a Java 25 JVM does to each API, by running it. Which modules in the 4.15 set on disk touch those APIs, by reading their bytecode. That the permission model's two installation points both throw.

Not measured, and not claimable. Anything about how the next major version actually behaves. No Niagara 5 build exists to test against — pre-release access runs through the vendor's own programme and there is no public download — so every statement here is static analysis against a Java 25 JDK, not a test on a Niagara 5 build. It says nothing about API changes, manifest schema changes, or repackaging done for other reasons. A module that passes a scan like this can still fail to compile against a new SDK.

That is a narrower claim than "N5-ready", and it is the one that can be backed up.