Release 1.11.0: end-user catalog, access requests, nested groups
Closes the end-user half of the directory and adds nested LDAP groups.
The directory could describe the lab but could not tell anyone what they had
or how to reach it, and several of the paths meant to do so were silently
returning nothing:
- GET /api/discovery/me resolved groups from req.user.groups, which does not
exist (req.user carries memberOf), so it returned only isPublic resources
for every human caller -- "My Services" was blank for everyone. The same
read made isDirectoryAdmin() false for real admins.
- The portal's "Discover More Services" called the admin-gated endpoint and
swallowed the 403, so it never rendered for non-admins at all.
- Services reported no address, because /me had reimplemented getMyAccess
without its parent-walking resolution.
Adds the catalog at /, self-service access requests, and admin access
visibility (per-resource counts, and the reverse "what can this user reach").
Nested groups come in two halves. groupOfNames.member already accepts a group
DN, so nesting needs no schema -- what it needs is resolution, which no
released OpenLDAP performs. The all-in-one image therefore builds slapd from a
pinned master commit for the nestgroup overlay, and the app computes the
closure itself when pointed at a server without it. Both paths are covered.
member-values is deliberately left out of nestgroup-flags: it expands `member`
when reading a group, which destroys the distinction between "listed here" and
"reachable through a nested group" and is not recoverable afterwards.
Full suite green in both resolution modes: 215 passed, 2 skipped.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -34,6 +34,11 @@ nav:
|
||||
- title: Directory
|
||||
page: /directory.html
|
||||
icon: fa-server
|
||||
# API.md lives at the repo root, not under docs/, so Jekyll never renders an
|
||||
# api.html for it — link the source directly, same as the Changelog.
|
||||
- title: API
|
||||
url: https://github.com/theta42/sso-manager-node/blob/master/API.md
|
||||
icon: fa-code
|
||||
- title: Changelog
|
||||
url: https://github.com/theta42/sso-manager-node/blob/master/CHANGELOG.md
|
||||
icon: fa-list
|
||||
|
||||
@@ -53,6 +53,29 @@ photo server. Once a group exists, add or remove members from the
|
||||
**Groups** page, and point the other app's "who's allowed in" setting at
|
||||
that group's name.
|
||||
|
||||
### Groups inside groups
|
||||
|
||||
A group can contain another group, not just people — the *Nested* tab on any
|
||||
group card. Everyone in the inner group counts as a member of the outer one,
|
||||
however many levels deep it goes.
|
||||
|
||||
This is mostly a way to stop repeating yourself. Make one `developers` group,
|
||||
nest it into the handful of things developers should reach, and adding a new
|
||||
developer to that one group grants all of them at once — instead of adding them
|
||||
to each individually and slowly drifting out of sync. The app already does this
|
||||
for itself: super admins are nested into every resource's admin group, and each
|
||||
admin group into its access group, so "can administer it" always implies "can
|
||||
use it".
|
||||
|
||||
Two things it won't let you do: put a group inside itself (directly or round a
|
||||
longer loop), and empty a group completely — every group must keep at least one
|
||||
member.
|
||||
|
||||
A note if you also manage the directory by hand: a group's member list shows
|
||||
what is *directly* listed on it. Someone who gets in through a nested group is
|
||||
a real member but won't appear there — the **Nested** tab shows what is nested,
|
||||
and the API's `effective` view lists everyone who actually gets in.
|
||||
|
||||
## Every account's personal group
|
||||
|
||||
Separately from the groups above, every single account — person or
|
||||
|
||||
@@ -8,7 +8,7 @@ description: A plain-language guide to personal access tokens in SSO Manager.
|
||||
|
||||
This page explains what an API token is and when you'd want one. For the
|
||||
full list of API endpoints a token can call, see the
|
||||
[API reference](api.html).
|
||||
[API reference](https://github.com/theta42/sso-manager-node/blob/master/API.md).
|
||||
|
||||
## What's an API token, in plain terms?
|
||||
|
||||
@@ -54,6 +54,6 @@ it stops working right away.
|
||||
## Want more detail?
|
||||
|
||||
This page doesn't attempt to list every API endpoint or show request/
|
||||
response examples — for that, see the full [API reference](api.html).
|
||||
response examples — for that, see the full [API reference](https://github.com/theta42/sso-manager-node/blob/master/API.md).
|
||||
|
||||
[← Back to Home](index.html)
|
||||
|
||||
@@ -54,6 +54,28 @@ Resources carry a flexible `metadata` JSON object that can store essential conte
|
||||
- **Install Path**: The filesystem path where the service is installed (e.g. `/opt/app`).
|
||||
- **Systemd Service**: The systemd unit name for the service (e.g. `app.service`).
|
||||
|
||||
### Who sees which metadata
|
||||
|
||||
Metadata keys are declared in `@simpleworkjs/directory-schema` with an `admin` flag, and every API response is passed through its projection. There are three tiers:
|
||||
|
||||
- **Public** — returned to any authenticated caller, including machine (`ServiceToken`) callers: `ip`, `address`, `sshPort`, `fqdn`, `dnsNames`, `port`, `externalPort`, `portMappings`, `isExternalReachable`, `os`, `gitRepo`, `subType`, `icon`, `tagline`, `isPublic`, `isProduction`, `requestable`, `isCurrentSite`.
|
||||
- **Admin-only** — only for members of `app_sso_directory_admin` / `app_sso_admin`: `vmid`, `macAddress`, `installPath`, `systemdService`, and the OAuth config keys (`redirect_uris`, `scopes`, `allowed_groups`, `token_lifetime`).
|
||||
- **Never returned** — `client_secret_hash`, plus any key matching `/secret|password|privatekey/i`. Stripped on every path, admins included.
|
||||
|
||||
Note that machine tokens are deliberately *not* admins, so anything a machine consumer needs (the firewall generator reads `port` / `externalPort` / `isExternalReachable`) has to be in the public tier. A metadata key that isn't declared at all is treated as admin-only and will silently vanish for normal users — if you add a field to the admin form, declare it in the schema package too.
|
||||
|
||||
## Catalog & access requests
|
||||
|
||||
The site root (`/`) is the end-user catalog — the only ungated page in the nav. It shows:
|
||||
|
||||
- **My Access** — everything the signed-in user can reach (`GET /api/discovery/me`), each card carrying a **how to reach it** block: the URL for a service, or the SSH invocation for a host. When `directory.jumpHost` is set in the config, host cards render the jump-host form `ssh <uid>_-_<slug>@<jumpHost>`; otherwise they fall back to a direct `ssh <uid>@<ip>`.
|
||||
- **Discover More** — everything else in the directory, with a **Request access** button.
|
||||
- **My Requests** / **Awaiting My Approval** — pending requests, and the approve/deny queue for anyone who owns a requested resource.
|
||||
|
||||
A request is a proposal to join an LDAP group. It targets the resource's `member`-level group (the `_access` one, never `_admin`), and approving it performs the LDAP group add — so LDAP stays the single access-control truth and the table is just the audit trail. Approvals are idempotent: approving for someone already in the group succeeds rather than erroring.
|
||||
|
||||
Requests are decided by the resource's `owner`, or by any directory admin. Mark a resource `metadata.requestable = false` to keep it out of self-service.
|
||||
|
||||
## Navigating the UI
|
||||
|
||||
The Directory Management interface provides a **Tree View** toggle that visually nests your resources, making it easy to comprehend your network topography at a glance. You can also filter, search, and sort your entire infrastructure inventory. From the tree view, you can click the green `+` icon next to any resource to instantly add a child resource beneath it.
|
||||
@@ -104,4 +126,14 @@ All of the above uses the same admin API the UI does (group `app_sso_directory_a
|
||||
- `GET/POST /api/directory-admin/resources`, `PUT/DELETE /api/directory-admin/resources/:id`
|
||||
- `GET/POST/DELETE /api/directory-admin/edges` — parent/child links (`hosts`, `oauth` relations)
|
||||
- `GET/POST/DELETE /api/directory-admin/groups` — resource ↔ LDAP group links
|
||||
- `GET /api/directory-admin/access-summary` — per-resource group + member counts (the Access column)
|
||||
- `GET /api/directory-admin/user-access/:uid` — the reverse lookup: every resource a given user can reach, and via which group
|
||||
- Read-only graph views (any authenticated user): `GET /api/discovery/resources`, `/api/discovery/resources/:slug`, `/api/discovery/graph`, `/api/discovery/me`
|
||||
|
||||
Access requests are open to any authenticated user; deciding is gated per-resource inside the router (resource owner or directory admin):
|
||||
|
||||
- `POST /api/access-requests` — `{slug | resourceId, groupCn?, note?}`
|
||||
- `GET /api/access-requests/mine` — the caller's own history
|
||||
- `GET /api/access-requests` — pending requests the caller may decide
|
||||
- `POST /api/access-requests/:id/approve` · `POST /api/access-requests/:id/deny`
|
||||
- `DELETE /api/access-requests/:id` — the requester withdraws their own pending request
|
||||
|
||||
+65
-6
@@ -59,8 +59,41 @@ way or use `slappasswd -h '{SSHA512}'`.
|
||||
Groups are `cn=<name>,ou=groups,<base>` (`groupOfNames`) with a `member`
|
||||
attribute listing member DNs. The `memberOf` overlay populates reverse
|
||||
membership (`memberOf` on the user); `refint` keeps it consistent on
|
||||
add/remove. **Admin permission checks read the group's `member` list**, not
|
||||
`memberOf` on the user.
|
||||
add/remove.
|
||||
|
||||
Note that `groupOfNames` requires **at least one member**, which has two
|
||||
consequences worth knowing: whoever creates a group is automatically seeded
|
||||
into it, and removing the last member (user *or* nested group) is refused with
|
||||
a 409 rather than leaving an invalid entry behind.
|
||||
|
||||
### Nested groups
|
||||
|
||||
A `member` DN may be another group's, not just a user's — that is how nesting
|
||||
is stored, with no extra schema. Everyone in the nested group is a member of
|
||||
the outer one, at any depth. Manage it on the **Groups** page under each
|
||||
group's *Nested* tab, or via the API:
|
||||
|
||||
```
|
||||
PUT /api/group/:group/nested/:child nest :child inside :group
|
||||
DELETE /api/group/:group/nested/:child un-nest
|
||||
GET /api/group/:group/effective direct users, nested groups, and the
|
||||
full transitive set of users
|
||||
```
|
||||
|
||||
Cycles are refused (409) rather than truncated — a loop makes "who is in this
|
||||
group" unanswerable. Two standing relationships are wired automatically: the
|
||||
cross-app `app_super_admin` is nested into every resource's `<slug>_admin`
|
||||
group, and each `<slug>_admin` into its `<slug>_access` group, so administering
|
||||
something implies being able to use it.
|
||||
|
||||
**Resolving nesting is a client-side job on stock OpenLDAP.** No 2.6.x release
|
||||
can evaluate nested groups; `memberOf` and a `(member=X)` filter both return
|
||||
direct membership only. The bundled slapd is therefore built from source with
|
||||
the `nestgroup` overlay (see *Modules + overlays* below), and the app is told so
|
||||
via `ldap.nestedGroupsServerSide`. Against any other server the app computes the
|
||||
closure itself — same answers, more queries. Either way, **never read `memberOf`
|
||||
directly to make an access decision**; use `utils/user_groups.js`'s `groupCns()`,
|
||||
which is correct in both modes.
|
||||
|
||||
### Personal groups
|
||||
|
||||
@@ -75,15 +108,15 @@ instead from the owning user's own profile page ("Members of `<uid>`'s
|
||||
group", admin-only) — add other accounts as supplementary members, e.g. to
|
||||
share write access to files owned by this group.
|
||||
|
||||
The SSO requires three groups (seeded automatically by the entrypoint /
|
||||
`install.sh`):
|
||||
The SSO seeds these groups automatically (entrypoint / `install.sh`):
|
||||
|
||||
| Group | Grants |
|
||||
|-------|--------|
|
||||
| `app_super_admin` | cross-app super admin. Nested into the three below, so its members hold those rights transitively rather than by a special case in app code — and the privilege is visible to LDAP-native consumers (SSSD, sudo) too. |
|
||||
| `app_sso_admin` | full admin (users, groups, settings) |
|
||||
| `app_sso_oauth_admin` | OAuth client management |
|
||||
| `app_sso_invite` | invitation management |
|
||||
| `app_sso_service_account` | not a permission — marks a `posixAccount` as a non-person service account (see *Service accounts* below) |
|
||||
| `app_sso_service_account` | not a permission — marks a `posixAccount` as a non-person service account (see *Service accounts* below). Deliberately **not** nested into, since it changes how an account is displayed rather than what it may do. |
|
||||
|
||||
## TLS (LDAPS / StartTLS)
|
||||
|
||||
@@ -308,11 +341,37 @@ needs:
|
||||
|
||||
- **Modules:** `pw-sha2` (the app stores user passwords as `{SSHA512}`),
|
||||
`ppolicy`, `memberof`, `refint`.
|
||||
- **Optional — `nestgroup`:** server-side nested-group evaluation. Not in any
|
||||
released OpenLDAP (added to master as ITS#10161 in March 2024; 2.7 is still
|
||||
unreleased), so the bundled image builds slapd from a pinned upstream commit.
|
||||
Without it the app resolves nesting itself and everything still works — leave
|
||||
`ldap.nestedGroupsServerSide` at `false`. With it, set that to `true` and
|
||||
configure:
|
||||
|
||||
```
|
||||
overlay nestgroup
|
||||
nestgroup-base ou=groups,<base>
|
||||
nestgroup-flags member-filter memberof-filter memberof-values
|
||||
```
|
||||
|
||||
Flags are **space-separated**; the comma form the man page's `{a, b, c}`
|
||||
notation suggests is rejected. `member-values` is deliberately omitted — it
|
||||
expands the `member` attribute when reading a group, which destroys the
|
||||
distinction between "listed here" and "reachable through a nested group", and
|
||||
the raw values are then unrecoverable. Transitive answers come from the filter
|
||||
flags and from `GET /api/group/:group/effective`.
|
||||
|
||||
One more consequence of building from master: it ships **LMDB 1.0.0**, whose
|
||||
on-disk format is mutually unreadable with the 0.9.x in 2.6.x
|
||||
(`MDB_INVALID: File is not an LMDB file`). Moving a directory between the two
|
||||
is a `slapcat` → `slapadd` reload, not a restart.
|
||||
- **Custom schema:** the `theta42Person` auxiliary objectClass with
|
||||
`dateOfBirth` — see `ops/ldap-setup.sh` for the LDIF.
|
||||
- **Directory tree:** `ou=people`, `ou=groups`, `ou=policies` under the base DN,
|
||||
a default `pwdPolicy` at `cn=ppolicy,ou=policies,<base>`.
|
||||
- **Required groups:** `app_sso_admin`, `app_sso_invite`, `app_sso_oauth_admin`.
|
||||
- **Required groups:** `app_sso_admin`, `app_sso_invite`, `app_sso_oauth_admin`,
|
||||
and `app_super_admin` (the cross-app super-admin group; the bundled entrypoint
|
||||
also nests it into the first three).
|
||||
|
||||
`ops/ldap-setup.sh -p <admin-password>` configures all of the above
|
||||
idempotently against a running slapd (auto-detects the database holding your
|
||||
|
||||
Reference in New Issue
Block a user