ZCU-DATA/config(shibboleth): map ZCU affiliation to DSpace groups for collection rights (#952)

[Kasinhou]

Problem

dataquest-dev/dspace-customers#952 asks whether the "collection rights for Shibboleth users" change (original issue #132, delivered on the publications instance customer/zcu-pub) is implemented on the data instance customer/zcu-data. It was not fully: the role→group mapping was missing.

Root cause / what was missing

#132 had three parts:

1. Code — special groups must survive token refresh / short-lived download tokens (DSpace PR [Port to dtq-dev] Issue 1373: obtain special groups from user context when new token is generated (on token refresh)  #1347). Already present on customer/zcu-data (backport PR ZCU-DATA/fix: shibboleth special groups lost in short-lived and refreshed tokens - 403 on download (backport #1347) #1375, commit 669ffec). Nothing to do.
2. Config — the ZCU Shibboleth affiliation → DSpace group mapping in authentication-shibboleth.cfg. This was missing on zcu-data — the delta this PR fixes.
3. Runtime data/admin — the groups + collection READ policies. No repo artifact (see below).

Change set

dspace/config/modules/authentication-shibboleth.cfg (+4 lines) — now byte-identical to customer/zcu-pub:

authentication-shibboleth.default-roles = nogroup
authentication-shibboleth.role.nogroup = NOGROUP
authentication-shibboleth.role.member\@zcu.cz = MEMBER_ZCU

With the already-present authentication-shibboleth.role-header = affiliation and role-header.ignore-scope = false, after a Shibboleth login:

• affiliation = member@zcu.cz → user placed in group MEMBER_ZCU;
• no matching affiliation → default role nogroup → group NOGROUP.

ShibGroup looks groups up by name and safely skips missing ones, so this config is inert (no startup error) until the groups exist.

Out of repo — required runtime admin steps (this is the +3h in the estimate)

These live on the running zcu-data instance, not in git:

1. Create EPerson groups NOGROUP and MEMBER_ZCU (exact names).
2. On the collection(s)/items to open up to authenticated ZCU members, add a READ resource policy (and bitstream/bundle READ for downloads) granting MEMBER_ZCU.
3. Confirm the ZCU IdP actually emits affiliation = member@zcu.cz; if the real attribute value differs, adjust the mapping key.

Testing

Automated (already green on this branch): the mechanism is covered by existing ITs in dspace-server-webapp/.../security/:

• ClarinShibbolethAuthAssing2GroupsIT — proves affiliation/entitlement header → role.* config → group assignment.
• ClarinShibbolethSpecialGroupsIT — proves a restricted bitstream is downloadable after Shibboleth login with the login token, a short-lived token, and a refreshed token (the internal/OAI-stability #132 download-403 regression guard).

A config .cfg file is not exercised by ITs (they inject properties dynamically), so no new IT is added; the ZCU values are validated manually per below.

Manual — simulate Shibboleth locally without an IdP. DSpace reads Shibboleth attributes as plain HTTP headers (mod_shib sets them), so you can fake a federated login:

1. Bring up the zcu-data stack locally (Postgres + Solr + backend + frontend).
2. Create the MEMBER_ZCU group and give a test collection a READ policy for it; leave a restricted bitstream in it.
3. Verify the restricted collection/bitstream is not visible anonymously.
4. Simulate the login by calling the Shibboleth endpoint with the affiliation header:

   curl -i "http://localhost:8080/server/api/authn/shibboleth" \
        -H "Shib-Identity-Provider: https://idp.zcu.cz/idp/shibboleth" \
        -H "SHIB-NETID: testuser" \
        -H "SHIB-MAIL: testuser@zcu.cz" \
        -H "affiliation: member@zcu.cz"
   

   Take the Authorization bearer token from the response, then confirm membership/access:

   curl "http://localhost:8080/server/api/authn/status" -H "Authorization: Bearer <token>"
   

   The user should now be in MEMBER_ZCU and able to read the restricted collection/bitstream.

Risk / rollback

• Very low. Additive config only; identical to the long-running zcu-pub setup. No code, no schema, no API change. Inert until the admin creates the groups.
• Rollback: revert this commit.

Refs dataquest-dev/dspace-customers#952 (original #132)

[Copilot]

🟡 Changes recommended

The added default-roles setting only applies when the role header is missing (not when it’s present but unmapped), which conflicts with the PR description’s stated fallback behavior and may break intended access policies relying on NOGROUP.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

Adds the missing Shibboleth affiliation → DSpace group role mapping for the ZCU-DATA deployment, aligning its Shibboleth group assignment configuration with the already-working ZCU-PUB setup so collection access policies can rely on DSpace group membership.

Changes:

• Introduces a default Shibboleth role (nogroup) and maps it to the NOGROUP DSpace group.
• Adds an explicit mapping from member@zcu.cz affiliation to the MEMBER_ZCU DSpace group.

File summaries

File	Description
dspace/config/modules/authentication-shibboleth.cfg	Adds ZCU-specific Shibboleth affiliation-to-group role mappings to support group-based collection access.

Review details

• Files reviewed: 1/1 changed files
• Comments generated: 1
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.