Shibboleth vs. IP Group mapping: Conflicting group mappings from different authentication methods

[Matthias Letsch]

Hello,

1. We have Shibboleth enabled and all epersons logging in via Shibboleth are mapped to the group "Submitters" which gives access to our submission form.

authentication-shibboleth.default-roles = Submitters

2. We also have some items which should only be accessible in our campus network. Therefore IP authentication is activated with a mapping to the "Internal Bitstream Read" group:

authentication-ip.Internal\ Bitstream\ Read = ...

Now, if both authentication methods are activated and a person newly registered via shibboleth which also happens to be in the campus network, the eperson no longer receives the Submitters group, but only the Internal Bitstream Read group. 

If I deactivate authentication-ip, the eperson receives the Submitters group again. The aim should be that the eperson is assigned to both groups when both methods are activated. How is this possible?

Thank you and kind regards,

Matthias

[Hill,Ed]

Hi Matthias,

Unfortunately I don't have any (good) help, but we noticed this too and filed an issue at https://github.com/DSpace/DSpace/issues/9226. If you have any extra information to share to what we mentioned you can add it there as well.

Our temporary workaround was to remove the if condition surrounding the code on lines 187 and 188 of https://github.com/DSpace/DSpace/blob/main/dspace-api/src/main/java/org/dspace/authenticate/AuthenticationServiceImpl.java before building our backend. This removes the benefits of a recent bugfix regarding authentication methods (https://github.com/DSpace/DSpace/pull/9130), but in our context it was worth it because we needed Shibboleth and IP-based special groups to work in tandem and a more robust fix was not in the cards for us at the time.

I'm happy to talk more off-list about what we specifically did to make this work with our 7.6.1 instance.

Cheers,

Ed Hill 

Pronouns: He/Him  (pronoun statement) 

Developer and Applications Administrator 

(970) 491-3197 

Colorado State University Libraries 

 

---

From: dspac...@googlegroups.com <dspac...@googlegroups.com> on behalf of Matthias Letsch <lets...@gmail.com>
Sent: Tuesday, March 12, 2024 10:02 AM
To: DSpace Technical Support <dspac...@googlegroups.com>
Subject: [dspace-tech] Shibboleth vs. IP Group mapping: Conflicting group mappings from different authentication methods

 

** Caution: EXTERNAL Sender **

--
All messages to this mailing list should adhere to the Code of Conduct: https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/b42a5033-532e-4b7d-a2d4-2760a8ae37dfn%40googlegroups.com.

[Matthias Letsch]

Hi Ed,

thank you for your reply!

I'll look at the workaround in detail when I get a chance, but for now I've made it easy for myself and simply added a second line to the authentication-ip:

authentication-ip.Internal\ Bitstream\ Read = ...

authentication-ip.Submitters = ...

This means that "in principle" you also get a group membership for submitters in the campus network, even if you are not logged in, BUT you can only open the mask when you are logged in anyway (If you try to open the URL to the submission form without logging in, you are automatically redirected to the login page). 

So, since we have one central administration and no epersons that are explicitly NOT supposed to access the submission form, this works quite well for us.

Kind regards,

Matthias