dohertj2/mxaccessgw
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Resolve IntegrationTests-001 and IntegrationTests-002 code-review findings

Browse Source 
IntegrationTests-001: documented the live Galaxy Repository test suite and
its MXGATEWAY_RUN_LIVE_GALAXY_TESTS / MXGATEWAY_LIVE_GALAXY_CONN gating in
docs/GatewayTesting.md.

IntegrationTests-002: documented the live LDAP test suite in
docs/GatewayTesting.md and added a concrete "Provisioning the GwAdmin group"
step to glauth.md so DashboardLdapLiveTests' GwAdmin-membership assumption
is reproducible.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Joseph Doherty
2026-05-18 20:46:09 -04:00
parent b381bfcaf1
commit bc55396334
3 changed files with 85 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files
glauth.md
+28 -8
View File
@@ -59,6 +59,14 @@ For mxaccessgw dev, `admin` covers every gw-side capability test;
`readonly` is the right "negative" case for proving Browse-OK /
Write-denied.
The gateway dashboard adds one role beyond this LmxOpcUa taxonomy:
`GwAdmin`. `LdapOptions.RequiredGroup` defaults to `GwAdmin`, so the
dashboard login and `DashboardLdapLiveTests` require `admin` to be a
member of a `GwAdmin` group. `GwAdmin` is **not** in the baseline
GLAuth config — it must be provisioned before dashboard authn or the
LDAP live tests work. See [Provisioning the GwAdmin
group](#provisioning-the-gwadmin-group) below.
## Two bind patterns
### 1. Direct bind (simplest)
@@ -127,14 +135,18 @@ ldap:
should strip the leading `ou=` (or `cn=` against AD) RDN value and
look that up in `groupToRole`.
## Adding a gw-specific group (when reuse isn't enough)
## Provisioning the GwAdmin group
If mxaccessgw needs a permission that doesn't fit the existing five
roles (e.g. `GwAdmin` for shutdown/recycle commands), add it to
GLAuth rather than running a separate LDAP server:
`GwAdmin` is the gateway-specific dashboard-admin role. It is the
default `LdapOptions.RequiredGroup`, so the dashboard cookie login and
`DashboardLdapLiveTests` (`MXGATEWAY_RUN_LIVE_LDAP_TESTS=1`) reject
`admin` until a `GwAdmin` group exists and `admin` is a member.
GLAuth's baseline config ships only the five LmxOpcUa role groups, so
`GwAdmin` must be added to GLAuth rather than run from a separate LDAP
server:
1. Edit `C:\publish\glauth\glauth.cfg`
2. Append:
2. Append the group:
```toml
[[groups]]
@@ -142,8 +154,9 @@ GLAuth rather than running a separate LDAP server:
gidnumber = 5510 # pick the next free GID
```
3. Add the group to whichever existing user(s) should have it via
`othergroups = [..., 5510]`. Or create a new user:
3. Add `5510` to `admin`'s `othergroups` list so `admin` resolves the
`GwAdmin` role. Add it to any other user that needs dashboard-admin
rights. Or create a dedicated user:
```toml
[[users]]
@@ -158,6 +171,12 @@ GLAuth rather than running a separate LDAP server:
4. `nssm restart GLAuth`
After the restart, `admin`'s `memberOf` includes
`ou=GwAdmin,ou=groups,dc=lmxopcua,dc=local`, which the authenticator
strips to `GwAdmin` and matches against `RequiredGroup`. The same
pattern applies to any future permission that doesn't fit the existing
five roles.
Generate `passsha256` from a plaintext password:
```powershell
@@ -196,7 +215,8 @@ ldapsearch -x -H ldap://localhost:3893 \
```
The response should list `admin`'s entry with `memberOf` populated for
all five role groups.
all five role groups — plus `GwAdmin` once the gateway-specific group
is provisioned.
## Service management