What this is about
CIAS sits between a CodamAI application (for example CDMS) and the identity provider. An identity provider, IdP for short, is the system people log in to. For CodamAI that is Keycloak today.
CIAS acts as a bridge. On one side are the applications with their roles and attributes. On the other side is the IdP with accounts, passwords and tokens. CIAS connects the two sides and gives the login a business meaning: who the person is, which tenant they belong to, and which permissions they carry.
Why a bridge and not Keycloak directly? Because the IdP should stay replaceable. Today it is Keycloak, tomorrow it may be another product. No application and no business module of CIAS knows Keycloak. Only one building block talks to Keycloak: the adapter.
Who does what?
- shows the login page
- checks password and MFA
- keeps the session
- issues and signs tokens
- stores accounts and their profile attributes
- keeps users, tenants, roles, groups, attributes as its own records
- registration, invitation, suspend, close
- writes roles, groups and attributes into Keycloak
- checks token and tenant on every request
- decides who may grant a permission
- reads the roles from the token
- decides what a role allows on the data
- filters rows by attributes
- registers its roles and attributes with CIAS
MFA means multi-factor authentication: a second proof besides the password, such as a code from an app. A token is a signed pass that Keycloak issues after login. The application sends it with every request.
CIAS does, CIAS does not
| CIAS does | CIAS does not |
|---|---|
| create, suspend, close, invite and register users | show a login page or check a password |
| have the email address confirmed and send emails | store passwords, MFA secrets or sessions |
| create tenants and keep track of their state | issue tokens |
| catalog, grant, time-limit and revoke roles | decide whether the role hr-employee-read may read the model employee |
| keep groups as role bundles | filter rows or deliver data |
| register attributes and write their values | let anyone grant permissions past CIAS straight into Keycloak |
| check the token and admit the tenant on every request | invent roles that no module registered |
The right column is not a gap, it is on purpose. One line answers whether a feature belongs in CIAS: business meaning lives in CIAS, technical login in the IdP, enforcement on the data in the application.
The write direction
Permissions always flow in one direction:
flowchart LR
A["Application<br/>(CDMS, CRMS, …)"] -- "registers roles<br/>and attributes" --> C["CIAS<br/>catalog, grants,<br/>groups, values"]
C -- "writes through<br/>the adapter" --> K["Keycloak<br/>roles, groups,<br/>profile, mappers"]
K -- "issues token" --> T(["Token"])
T -- "on every request" --> A
- The application registers which roles and attributes it knows. It writes nothing into Keycloak itself.
- CIAS takes the registration into its catalog, keeps all grants and writes them to Keycloak through the adapter.
- Keycloak puts the roles and attributes into the token at login.
- The application reads the token and enforces the permissions.
The read direction for accounts
For the accounts themselves it is the other way round. Keycloak knows best whether an account exists and whether it is active. People log in there, and an operator can also create an account in the console. CIAS aligns itself with that and can import existing accounts, see Import existing accounts.
The opposite path exists exactly once: a registration creates a new account. CIAS then creates it in Keycloak itself.
| Question | Leading system |
|---|---|
| Is the password correct? Is the session valid? | Keycloak |
| Does the account exist, is it enabled? | Keycloak. CIAS aligns with it |
| Which tenants exist, are they active? | CIAS |
| Which roles exist, who may grant them, who got them? | CIAS. Keycloak keeps a copy |
| Which groups exist, who is a member? | CIAS. Keycloak keeps a copy |
| May this role read this model? | the application, e.g. CDMS |
How the bridge is built
Inside, CIAS consists of business modules (registration, users, roles and groups, tenants, notifications, audit). None of them talks to Keycloak directly. Each one uses a port: an interface that only says what is needed, such as “create an account” or “grant this role”. The how lives in the adapter.
flowchart LR
subgraph CIAS
F["Business modules<br/>registration, users,<br/>roles, tenants …"] --> P["Ports<br/>what is needed"]
end
P --> KA["Keycloak adapter"]
P --> MA["In-memory adapter<br/>for tests"]
KA --> K["Keycloak"]
Whoever replaces the IdP writes a new adapter. The business modules stay as they are. Details under Ports and adapters.
Embedded or standalone
CIAS runs in two operating modes. In business terms it behaves the same in both.
- CIAS is a building block in the same program as CDMS
- no separate service needed
- calls between CDMS and CIAS are method calls
- CIAS runs as its own service with its own database
- CDMS asks CIAS over HTTP
More under Embedded and Standalone.
Next
- The objects and who owns them: what CIAS stores and what Keycloak keeps of it as a copy
- The two permission matrices: why “what a role may do” is not in CIAS
- What happens to the token on every request