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["cias-authentication<br/>filter chain, tenant gate<br/><i>no switch: present or absent</i>"]
        L{"codamai.cias.tenancy.lookup"}
        A --> L
        L -->|local| T["cias-tenancy<br/>codamai.cias.tenancy.enabled"]
        L -->|remote| C["cias-tenancy-client<br/>+ client.base-url, client.credentials"]
        A -.-> U["cias-user<br/>codamai.cias.user.enabled"]
        A -.-> Z["cias-authorization<br/>codamai.cias.authorization.enabled"]
        A -.-> R["cias-registration<br/>codamai.cias.registration.enabled"]
        A -.-> N["cias-notification<br/>codamai.cias.notification.enabled"]
        A -.-> AU["cias-audit<br/>codamai.cias.audit.enabled"]
    end
    IP{"codamai.cias.iam-provider"}
    Z --> IP
    U --> IP
    IP -->|keycloak| K[(Keycloak)]

The complete list:

cias-authentication has no switch of its own. The filter chain checks every token, and it works as soon as the 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. In the hub, a system carries a field cias with three possible values. From it the generator decides which jars go into the application and which configuration classes it writes.

Two things here are easy to miss:

• REMOTE is the value that applies when nobody says anything. As soon as an application authenticates through CIAS it needs an answer to the tenant gate’s question, or it does not start. So the generator never leaves that question open. REMOTE is the more restrained choice: one jar and two settings. EMBEDDED pulls tenants, users and the role catalog into the application, and that is a decision about the installation, not a default.
• With EMBEDDED the identity half comes along dormant. The jars for users, the role catalog and Keycloak access sit on the classpath, but CIAS_IAM_PROVIDER, CIAS_USER and CIAS_AUTHORIZATION start out empty or false. Only setting them gives you those modules. That is exactly the point of this page: configuration decides what runs, not the classpath.

A system that does not authenticate through CIAS at all always gets NONE — even if the field says otherwise. Without a filter chain there is no gate that would need an answer.

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?