What it does here
OpenLDAP is the directory — the single store of who exists and what groups they belong to. Everything else in the lab is arranged around it: midPoint is the only component that writes to it, and Keycloak reads it to decide who may log in.
The tree is deliberately small so you can hold it in your head:
| Branch | Contains |
|---|---|
dc=golonex,dc=local | the base of the Golonex directory |
ou=people | one entry per employee (inetOrgPerson) |
ou=groups | one entry per entitlement (groupOfNames) |
ou=service | reserved for non-human accounts |
How it is deployed
Container openldap, from the image above. The structure and the seeded workforce are loaded once at first start from LDIF bootstrap files — see Installation §4.2. Two accounts matter:
| Bind DN | Used by | Rights |
|---|---|---|
cn=admin,dc=golonex,dc=local | midPoint | read + write — provisioning |
cn=readonly,dc=golonex,dc=local | Keycloak | read only — federation |
Where you actually see the directory
Through midPoint
Open a user and look at the Projections tab. That is the live LDAP entry midPoint provisioned — the account, its attributes and its status, read straight from the directory.
Group membership is not shown here. midPoint does not cache entitlement associations on the account, so the Projections tab lists the account but not the groups it belongs to. To answer “what groups does this person have?” look at the Assignments tab — the roles that grant the groups — or read the directory through Keycloak below. This distinction is worth understanding: assignments are what should be, the directory is what is, and reconciliation exists precisely because the two can drift apart.
Through Keycloak
Users lists the accounts Keycloak has federated from ou=people, and Groups mirrors ou=groups. If an identity is missing here, it is missing in the directory.
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
- Create a joiner, then open their Projections tab in midPoint — you are looking at an LDAP entry that did not exist a minute ago.
- Terminate them and watch
employeeTypeflip todisabled; that single attribute is what removes their ability to log in everywhere at once.