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 > > > > -- The University is ranked in the QS World Rankings of the top 5% of universities in the world (QS World University Rankings, 2014) The University of Stirling is a charity registered in Scotland, number SC 011159. ------------------------------------------------------------------------------ _______________________________________________ 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
