[
http://jira.dspace.org/jira/browse/DS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10153#action_10153
]
Bruc Liong commented on DS-109:
-------------------------------
Finally got it fixed. Sorry for the false alarm, please close this issue.
For the record, here's what happened:
After initial authentication, the special groups are populated properly from
the shibboleth servlet. It then allows other parts of the authentication system
(and classes) to continue, which at that point they perform queries the special
groups again from AuthenticationManager. AuthenticationManager returns empty
special groups. We've traced it down to the fact that shibboleth servlet is
the only place when the header is properly populated (due to protection
mechanism on shibboleth servlet), hence once it redirects to other pages,
AuthenticationManager will give empty special groups cause it can't find the
proper headers.
the way we did special groups is that we dynamically query the headers and map
the users appropriately to their special groups, hence if the headers are not
there/empty, no special groups are associated between different pages/servlets
We solved this by storing the special groups into session upon successful
authN, and that did the trick.
So, no more persisting groups into DB :)
> Consistent treatment to users in special groups
> -----------------------------------------------
>
> Key: DS-109
> URL: http://jira.dspace.org/jira/browse/DS-109
> Project: DSpace 1.x
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.5.0, 1.5.1, 1.5.2
> Reporter: Bruc Liong
>
> We populate users into their groups via the use of "special groups" on the
> fly (as part of Shibboleth authN integration into DSpace) and had been
> noticing that the mapped users cannot gain access to their resources despite
> they have the aforementioned groups in the special group.
> Temporary fix for this is to persist the group membership, e.g.
> int[] groupIDs = AuthenticationManager.getSpecialGroups(context,request);
> for(int i=0;i<groupIDs.length;i++){
> Group g = Group.find(context, groupIDs[i]);
> //.....
> g.addMember(eperson);
> g.update();
> }
> This is not ideal, it would be better if the special groups are
> loaded/integrated into Group.isMember(eperson), or Group.isMember(groupid),
> etc calls. These isMember seem to be only honouring explicit users assigned
> in DB. Currently special groups only included in Group.allMemberGroupIDs and
> isMember(context,groupid).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.dspace.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
