Configuration decides what runs

What this is about

CIAS is not an application you start. It is a set of jars. A jar is a library that sits on an application’s classpath. Whether a CIAS module actually works inside that application is decided by the configuration alone. The jar being there is not enough.

Why no module switches itself on

Spring normally finds classes through a component scan: it searches packages for classes carrying markers such as @Service or @Component and wires them up. CDMS scans everything under com.codamai — and CIAS lives under com.codamai.

If a CIAS class carried such a marker, every CDMS application would pick it up as soon as the jar landed on the classpath somehow, for example as a dependency of a dependency. It would then be wired against objects that do not exist there.

So instead:

The switches

The picture shows where the switches sit. On the left, what is always there once the filter chain runs; on the right, the modules that are switched on one by one.

flowchart LR
    subgraph P["One process"]
        direction TB
        A["Filter chain, tenant gate<br/><i>no switch: present or absent</i>"]
        L{"codamai.cias.tenancy.lookup"}
        A --> L
        L -->|local| T["Tenant management<br/>codamai.cias.tenancy.enabled"]
        L -->|remote| C["Tenant client<br/>+ client.base-url, client.credentials"]
        A -.-> U["User management<br/>codamai.cias.user.enabled"]
        A -.-> Z["Role management<br/>codamai.cias.authorization.enabled"]
        A -.-> R["Registration<br/>codamai.cias.registration.enabled"]
        A -.-> N["Notifications<br/>codamai.cias.notification.enabled"]
        A -.-> AU["Audit<br/>codamai.cias.audit.enabled"]
    end
    IP{"codamai.cias.iam-provider"}
    Z --> IP
    U --> IP
    IP -->|keycloak| K[(Keycloak)]

The complete list:

The filter chain has no switch of its own. It checks every token, and it works as soon as its jar is there. What it needs is not a switch but an answer: codamai.cias.tenancy.lookup tells it whom to ask about the tenant.

The three variants

Which case applies is not a matter of taste. It depends on what a wrong default would do:

The whole rule behind this is under Reject when in doubt, together with the list of all mandatory values.

What the application itself has to supply

Some values are not a line in a file but beans. A bean is an object Spring wires up at start.

If one of them is missing where it is needed, the start fails with the name of the type in the message.

What is decided at build time

Part of the decision is made earlier, when the project scaffold is produced. There is no field for it. The generator derives the integration from two things in the hub: whether the system authenticates through CIAS (authentication), and which runtime the project’s CIAS module runs in.

A refused build answers with 400, and the message names what to model: give the project a CIAS module, place it in a runtime, or set authentication to NONE.

Two things here are easy to miss:

• Two CDMS modules of the same project can be integrated differently. If the CIAS module runs in the runtime of one, it is embedded there, and the other, in its own runtime, is its client. The second one does not need a CIAS service of its own for that.
• With EMBEDDED the CIAS module decides what is switched on. The scaffold’s application.yaml leaves users, roles and Keycloak access off. The generated cias-configuration.yaml sets them to what the CIAS module in the hub says. An environment variable such as CIAS_USER overrides both. Here too, configuration decides what runs, not the classpath.

Watch out

Next

• Embedded and standalone compared
• CIAS embedded (a single unit)
• CIAS as a separate service
• SINGLE and MULTI across both modules
• Reject when in doubt
• Who decides what?