[
http://jira.dspace.org/jira/browse/DS-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=10162#action_10162
]
Mark Diggory commented on DS-109:
---------------------------------
Yes, reviewing the code, some of the Call stack for the AuthenticationManager
and AuthenticationMethods is pretty "whacked", the abstraction of the
authentication methods and the ability to utilize the dspace servlet as the
controller was never adopted properly by the other commiters after its
inclusion in 1.4. Methods like AuthenticateMethod.initEPerson were never
properly implmented on any of the methods and that call to
AuthenticationMethod.initEPersons simply calls a bunch of empty methods, this
is sad.
ShibbolethFilter doesn't actually do anything outside of call into the
authentication stack the same way that the RegisteredOnlyFilter does. Its
simply assuring that the user is in fact registered before accessing the
resource, thus ShibbolethFilter isn't neccessary, in fact, in your patch it is
not defined in the jspui web.xml, I think this can be left out.
The ShibbolethServlet.assignSpecialGroups method should be happening or
required. Special Groups are determined higher in the Call stack when line 132
of DSpaceServlet calls UIUtil.obtainContext, which is where the real evaluating
of the Shibboleth headers will occur in the ShibbolethAuthenticationMethod. By
the time the Servlet is actually reached, the special groups have been resolved
and placed into the users context along with those retrieved from the database.
If there is a problem with users accessing protected resources with special
groups, that is a bigger problem we should evaluate the cause of, I don't
consider this an appropriate solution.
> 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
> Assignee: Andrea Bollini
> Fix For: 1.5.2
>
>
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
