Hi Michael, A silly question, but is the "org.dspace.authenticate.ShibAuthentication" class listed *first* amongst your "AuthenticationMethod" settings in authentication.cfg? Or are there other authentication plugins appearing above it?
https://github.com/DSpace/DSpace/blob/master/dspace/config/modules/authentication.cfg#L37 It seems really odd to me that you are not seeing DEBUG logs from the ShibAuthentication.getSpecialGroups() method, as they should be written on *login* (and shouldn't actually be affected by that other bug I mentioned, DS-2527). So, it made me wonder if somehow the Special Groups are not being initialized properly (though I cannot think of why that'd be). You could try listing ShibAuthentication *first* (or removing any other Authentication plugins temporarily) to see if that makes any difference. Beyond that, honestly your configs look fine to me. I don't see anything obviously wrong here, and I've done something similar myself in the past (and it's always worked). - Tim On 6/15/2015 6:20 AM, Michael White wrote: > Thanks Tim, > >> You might be hitting this bug: >> >> https://jira.duraspace.org/browse/DS-2527 > > Yes, it does look like what I'm experiencing, but I've tried the fix and it > didn't seem to do the job for me - I uncommented the following in dspace.cfg: > > org.dspace.content.Collection.findAuthorizedPerformanceOptimize = false > > - and restarted Tomcat, but no joy. > > In authentication-shibboleth.cfg, I have: > > ------------------------------------------------------------------------------------------ > # The shibboleth header to do role-based mappings > role-header = affiliation > > # Whether to ignore the attribute's scope or value. > role-header.ignore-scope = true > #role-header.ignore-value = false > > # Default mappings of roles values to a comma separated list of DSpace group > # names (Case Sensitive). > #role.faculty = Faculty, Member > role.staff = STIR_USERS > ------------------------------------------------------------------------------------------ > > But, when I log on as a user with the appropriate role defined, they are not > allocated to the named group (which should give them deposit permissions as > the "special group" has deposit permissions in my one and only test group). > With logging at DEBUG, I can see the role header (affiliation) being passed > over (amongst others): > > eppn='m...@stir.ac.uk' > affiliation='st...@stir.ac.uk;mem...@stir.ac.uk' > unscoped-affiliation='' > entitlement='' > targeted-id='' > persistent-id='' > sn='White' > givenname='Michael' > mail='michael.wh...@stir.ac.uk' > netid='mw6' > o='Information Services' > ou='eLearning Liaison and Development' > > However, I'm not seeing any of the log lines from the "getSpecialGroups" > function in ShibAuthentication.java - so it still looks like this function > isn't being called? > > So, just wanted to report that the "simple" fix didn't seem to resolve the > problem for me. > > However, It isn't life or death for me to solve this now as allocation to a > single "special" group wasn't quite what I wanted to do anyway - I ideally > wanted to allocate Researchers to deposit groups for the Collections for > their department (pulled from "ou" header), so instead I extended the > ShibAuthentication code to use a mapping of departments to deposit groups > (abstracted to authentication-shibboleth.cfg) to add users to their > department's deposit group during logon (which I now have working a treat). > > Not sure why the stipulated fix for the original problem didn't work for me > though :-( > > Cheers, > > Mike > > Michael White > eLearning Developer > Information Services > > T: (01786) 466877 > E: michael.wh...@stir.ac.uk > A: S8, Library, University of Stirling, Stirling, FK9 4LA > >> -----Original Message----- >> From: Tim Donohue [mailto:tdono...@duraspace.org] >> Sent: 12 June 2015 15:25 >> To: Michael White; dspace-tech@lists.sourceforge.net >> Subject: Re: [Dspace-tech] Shibboleth and role based groups? >> >> Mike, >> >> You might be hitting this bug: >> >> https://jira.duraspace.org/browse/DS-2527 >> >> If so, there's a quick fix listed in the bug report. >> >> Good luck, >> >> - Tim >> >> On 6/9/2015 5:21 AM, Michael White wrote: >>> Hi, >>> >>>> I can't seem to get the auto population of this group working. >>> >>> Just to add to what I've already said - I upped the log level to DEBUG and >>> ran >> some more tests, but that didn't seem to shine any additional light. >>> >>> So I've been looking through the Shibboleth authentication code (in >> ShibAuthentication.java) - In the code I can see the function: >>> >>> public int[] getSpecialGroups(Context context, HttpServletRequest >>> request) >>> >>> - which appears to be the code that adds the user to the special group(s). >> This code contains lots of INFO and DEBUG logging lines, but I'm not seeing >> any >> of these lines appearing in my logs - suggesting that this code to populate >> the >> special groups isn't actually being called . . . . . ? It certainly isn't >> called from >> within ShibAuthentication.java as far as I can tell . . . . >>> >>> Am I missing some config somewhere to turn this feature on? It all looks >>> like >> it should work, so I feel like I'm missing something obvious (assuming this >> feature is working for others)? >>> >>> Any pointers welcome! >>> >>> Cheers, >>> >>> Mike >>> >>> Michael White >>> eLearning Developer >>> Information Services >>> >>> T: (01786) 466877 >>> E: michael.wh...@stir.ac.uk >>> A: S8, Library, University of Stirling, Stirling, FK9 4LA >>> >>>> -----Original Message----- >>>> From: Michael White >>>> Sent: 09 June 2015 10:17 >>>> To: dspace-tech@lists.sourceforge.net >>>> Subject: Shibboleth and role based groups? >>>> >>>> Hi, >>>> >>>> DSpace v5.2/JSPUI. >>>> >>>> I've set up Shibboleth authentication for a new v5.2 installation - >>>> the authentication part appears to be working well, but I'm >>>> struggling with automatically placing authenticated users into role >>>> based groups based on their (scoped) affiliation and I'm hoping someone >> might be able to help. >>>> >>>> I've configured authentication-shibboleth.cfg to add "staff" users >>>> into the group "ALL_Collections_Submit" (and I've double checked the >>>> group name/case etc): >>>> >>>> # The shibboleth header to do role-based mappings role-header = >>>> affiliation >>>> >>>> # Whether to ignore the attribute's scope or value. >>>> role-header.ignore-scope = true >>>> >>>> # Default mappings of roles values to a comma separated list of >>>> DSpace group # names (Case Sensitive). >>>> #role.faculty = Faculty, Member >>>> role.staff = ALL_Collections_Submit >>>> #role.student = Students, Member >>>> >>>> - when I authenticate, I can see in the dspace logs that the shib >>>> authentication module is picking up the affiliation header (amongst >> others): >>>> >>>> 2015-06-09 09:53:05,024 INFO >>>> org.dspace.app.webui.servlet.ShibbolethServlet @ >>>> header:affiliation=st...@stir.ac.uk;mem...@stir.ac.uk >>>> 2015-06-09 09:53:05,024 INFO >>>> org.dspace.app.webui.servlet.ShibbolethServlet @ header:unscoped- >>>> affiliation= >>>> 2015-06-09 09:53:05,025 INFO >>>> org.dspace.app.webui.servlet.ShibbolethServlet @ header:entitlement= >>>> 2015-06-09 09:53:05,025 INFO >>>> org.dspace.app.webui.servlet.ShibbolethServlet @ header:targeted-id= >>>> 2015-06-09 09:53:05,026 INFO >>>> org.dspace.app.webui.servlet.ShibbolethServlet @ >>>> header:persistent-id= >>>> 2015-06-09 09:53:05,027 INFO >>>> org.dspace.app.webui.servlet.ShibbolethServlet @ header:sn=White >>>> 2015-06-09 09:53:05,027 INFO >>>> org.dspace.app.webui.servlet.ShibbolethServlet @ >>>> header:givenname=Michael >>>> 2015-06-09 09:53:05,028 INFO >>>> org.dspace.app.webui.servlet.ShibbolethServlet @ >>>> header:mail=michael.wh...@stir.ac.uk >>>> >>>> - but, even though the authentication is successful (and creates a >>>> new ePerson record for that user using the supplied header data if >>>> they don't already exist in the system), I can't seem to get the auto >>>> population of this group working. >>>> >>>> I only have a handful of test collections in this DSpace currently: >>>> >>>> 0 Anonymous >>>> 1 Administrator >>>> 2 Test_Collection_SUBMIT >>>> 3 ALL_Collections_Submit >>>> >>>> - where ALL_Collections_Submit has group deposit permissions to >>>> Test_Collection_SUBMIT. >>>> >>>> If I manually add a user to the "ALL_Collections_Submit" group, then >>>> when I log on as that user via Shibboleth, I do get the appropriate >>>> deposit permissions for "Test_Collection_SUBMIT" (so the group logic >>>> seems OK), but it doesn't work if relying on Shibboleth to >>>> dynamically add the user to the "ALL_Collections_Submit" group . . . . >>>> >>>> I also tried amending the shibboleth attribute filter policy to only >>>> supply "st...@stir.ac.uk", just in case it was the semi colon >>>> separated list of scoped affiliations that was behind the problem, but it >>>> still >> didn't work . . . . >>>> >>>> Does anyone have any thoughts on what I might be missing? Do others >>>> have this working as intended? Have I misunderstood or done something >> stupid? >>>> >>>> Thanks in advance for any thoughts or insights anyone might have. >>>> >>>> Cheers, >>>> >>>> Mike >>>> >>>> Michael White >>>> eLearning Developer >>>> Information Services >>>> >>>> T: (01786) 466877 >>>> E: michael.wh...@stir.ac.uk >>>> A: S8, Library, University of Stirling, Stirling, FK9 4LA >>> >>> > ------------------------------------------------------------------------------ _______________________________________________ DSpace-tech mailing list DSpace-tech@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
