What it does here
midPoint is the governance engine — the brain of the lab. It reads the authoritative HR feed, decides what each person should have, and makes the directory match. Joiner, mover, leaver, access requests, approvals, segregation of duties and reconciliation all happen here.
How it is deployed
Container midpoint with its own PostgreSQL repository. Behind Caddy it runs with -Dserver.forward-headers-strategy=NATIVE so it knows TLS is terminated upstream. Its objects — resources, roles, the user template and the tasks — were imported over the REST API; see Installation §4.4.
Settings in the web console
Sign in at midpoint.iamlab.genbay.co as administrator. The left menu is your map of the whole identity lifecycle.
Resources — the systems midPoint talks to
Resources › All resources holds exactly two, and the pair tells the whole story:
| Resource | Role | Direction |
|---|---|---|
| Golonex HRIS (CSV feed) | authoritative source of identities | midPoint reads it |
| Golonex Directory (OpenLDAP) | the provisioning target | midPoint writes it |
Open either and use Test connection — the first thing to check if the lab misbehaves. Under Schema handling you can see the mappings: which HR column becomes which identity attribute, and which identity attribute becomes which LDAP attribute.
Users — the governed identities
Users › All users. Open one and the tabs matter:
- Basic — name, e-mail, department, and the activation status that drives everything.
- Projections — the actual accounts this identity owns on connected systems (the LDAP entry).
- Assignments — the roles the person holds. This is what should be; projections are what is.
Roles — what access looks like
Roles › All roles contains the Golonex role model:
| Role | Behaviour |
|---|---|
| Employee | birthright — auto-assigned to every HR-sourced identity, grants the directory account and app-users |
| Finance AP Clerk / Approver | requestable, department-scoped, and mutually exclusive |
| HR Staff / IT Admin | requestable, department-scoped, require line-manager approval |
| Access Approver | its members are the approvers in the request workflow |
Open Finance AP Clerk and look at its Inducements (what it grants) and its Policy rules — the exclusion rule against AP Approver is the segregation-of-duties control, written once and enforced on every request.
Server tasks — the automation
Server tasks › All tasks. Two tasks drive the lab, and you run them by hand so you can watch cause and effect:
| Task | What it does | When you run it |
|---|---|---|
| HR feed import | reads the CSV and applies joiners, movers and leavers | after every HRIS change |
| Directory reconciliation | compares the directory against governed identities | to surface orphan accounts |
Use Run now, then open the task and read its Operation result — that is where you see what actually happened, and any error.
Cases — approvals in flight
Cases (also surfaced as work items) is where a requested role waits for a decision. Each case shows what was requested, for whom, and who may approve it. Approving here is what releases the entitlement to be provisioned.
Three ways to reach OPA
The same engine, three doors. Which one you use says a lot about what you are doing — demonstrating, operating, or debugging.
| Route | Who uses it | Good for |
|---|---|---|
| PDP console in the Portal | instructor, IT Ops | showing the policy and its decisions to a room |
| OPA's REST API from a container | engineers | asking the engine directly, with no app involved |
| Files and scripts on the host | whoever runs the lab | editing policy, watching decisions, running tests |
1 · From the app — the PDP console
IT Admin › Policy decision point
Sign in to the Portal as a user holding it-admins and open IT Admin › Open PDP console. Two tabs:
- Live decisions — recent authorization decisions with user, action, amount, ALLOW / DENY and the reason OPA gave. Click around the Portal in another tab, then refresh this one.
- Policy — the Rego OPA is actually running, read live from the engine rather than from disk, so the page cannot show you something that is not in force. Read-only by default.
An Edit policy button turns that tab into an editor. Saving needs the policy.edit entitlement, applies to OPA immediately, and is written to disk so it survives a restart.
It is fail-safe. OPA compiles the policy before accepting it. A Rego error is rejected with a message and the running policy is untouched — a bad edit cannot take the lab down.
Worth saying out loud to candidates: editing authorization from a web form is a teaching device, not a production pattern. Real policy lives in version control, is reviewed, tested in CI and shipped as a bundle. This console exists so you can feel a policy change take effect — which is precisely why change control matters.
2 · From a container — OPA's own API
OPA listens on opa:8181 on the internal network. It is not published to the host and not exposed through Caddy: the API has no authentication, so it must never leave the private network. Ask it from any container on ciam-net.
Ask for a decision — no app, no login, no session:
docker exec -i portal python -c "import requests;print(requests.post('http://opa:8181/v1/data/golonex/portal/decision',json={'input':{'user':'x','groups':['app-users','finance-ap-approver'],'action':'payment.approve','amount':50001}}).json())"See what policies are loaded:
docker exec portal python -c "import requests;print([p['id'] for p in requests.get('http://opa:8181/v1/policies').json()['result']])"The endpoints that matter: GET /v1/policies (what is loaded), POST /v1/data/golonex/portal/decision (ask), PUT /v1/policies/<id> (replace — this is what the console uses), and GET /health.
3 · From the host — files, scripts and logs
The policy is a plain file on the server, bind-mounted into the container at /policies:
| Path | What it is |
|---|---|
/opt/ciam-lab/opa/policies/portal.rego | the live policy |
/opt/ciam-lab/opa/policies/portal.rego.orig | pristine copy — the restore point for the live-edit demo |
/opt/ciam-lab/opa/policies/portal_test.rego | the policy's own unit tests |
/opt/ciam-lab/opa-ask.sh | ask OPA a question from the command line |
/opt/ciam-lab/opa-watch.sh | live feed of every decision — put it on a projector |
Ask a question:
/opt/ciam-lab/opa-ask.sh payment.approve app-users,finance-ap-approver 50001Watch decisions live (Ctrl-C to stop):
/opt/ciam-lab/opa-watch.shRun the policy's unit tests:
docker exec opa /opa test /policies -vRaw decision log — every decision, with full input and result:
docker logs --tail 20 opa--watch, so a change to portal.rego on disk takes effect only after
docker restart opa — about four seconds, during which the Portal fails closed and denies
everything. The PDP console sidesteps this: it pushes policy through the API, which applies instantly with no
restart.Every decision is audited
The Portal writes one JSON line per decision, and Wazuh turns the interesting ones into alerts:
| Rule | Level | Fires on |
|---|---|---|
100201 | 4 | any denied action, naming the user and the reason |
100202 | 5 | a payment approved, with the amount |
100203 | 4 | an HR record changed — workforce data feeding IGA |
100204 | 4 | an invoice created |
100205 | 10 | the authorization policy itself was changed |
100210 | 10 | a segregation-of-duties violation blocked at the PDP |
Rule 100205 is deliberately the loudest thing in the lab. Ask a candidate why that is right: changing the policy changes every future decision, so it outranks any single denied action.
Try this
- Request Finance AP Approver for someone who already holds AP Clerk — midPoint refuses it and names the policy. That refusal is the single most exam-relevant moment in the lab.
- Run reconciliation and look for
mallory.mills: an account with no owning identity.