[DS-48] shibboleth+dspace1.5.1 patch - ID: 2412723 about dspace HOT 24 CLOSED

bollini said:

I like to include this patch to the main code of dspace but before you should change the copyright of the code according to the contribution terms at:
http://wiki.dspace.org/index.php//HowToContribute#Copyright_and_Licensing

Please note also that the change made for the DS-88 should make pointless the method fixGroupMembership. Also the package names should be changed to use standard structure org.dspace...

Are you able to make this changes in the next few days? if so we can attempt to include this patch in the 1.5.2 release.

from dspace.

kevin_melcoe said:

Hi, Andrea:

Here we worked out the shib patch against your dspace 1_5_x branche(https://dspace.svn.sourceforge.net/svnroot/dspace/branches/dspace-1_5_x), revision 3613

There are two issues:

1, your fixGroupMembership patch seems not working properly, we have to roll back to use our persistent way.

2, for xmlui, after we logged in using shibboleth, there is authentication error. (the same patch works fine on dspace1.5.1).

Regards,

Kevin

from dspace.

kevin_melcoe said:

Shibboleth patch

from dspace.

kevin_melcoe said:

This is the latested shib patch for 1.5.2, those two issues mentioned above has been solved in this new patch.

ps, you have to patch DS-64 (xmlui-selector-auth-fix-v2.patch) first, to make this patch working.

have fun,
Kevin

from dspace.

mdiggory said:

Quite happy with this solution over the last patch. Committing it (but changing the dspace.cfg to not enable shibauth by default). – Mark

from dspace.

kgilbertson said:

Stuart Hicks, Systems Engineer at OhioLINK, has been working with a slightly older version of the patch than what was released today and found two things that we need in our environment:

1. Anonymous users - We can't guarantee that we'll get an eppn, email address, or much of anything else from the schools except the mandatory affiliation values. This is the issue that the attached patch addresses. Anonymous users are defaulted to a preset account dictated by the email-default value in dspace.cfg
2. Scoping - The authentication.shib.role handlers need to support scoping as we use eduPersonScopedAffiliation attributes rather than the unscoped variety.

Here's the text from his patch (based on an earlier version) to allow anonymous, but Shibboleth authenticated users. Would it be possible to get this change incorporated into the main codebase?:
diff -ur dspace-1_5-with-shib.orig/dspace/config/dspace.cfg dspace-1_5-with-shib/dspace/config/dspace.cfg
— dspace-1_5-with-shib.orig/dspace/config/dspace.cfg 2009-03-27 10:46:22.000000000 -0400
+++ dspace-1_5-with-shib/dspace/config/dspace.cfg 2009-03-27 10:47:55.000000000 -0400
@@ -324,6 +324,10 @@

1. this option below forces the software to acquire the email from Tomcat.
   #authentication.shib.email-use-tomcat-remote-user = true

+# this is the default email used for Shib-authenticated sessions that
+# do not include user-identifiable data (eppn, mail, etc.)
+#authentication.shib.email-default = [email protected]
+

1. should we allow new users to be registered automtically
2. if the IdP provides sufficient info (and user not exists in DRC)
   #authentication.shib.autoregister = true
   diff -ur dspace-1_5-with-shib.orig/dspace-api/src/main/java/au/edu/mq/melcoe/mams/dspace/authenticate/ShibAuthentication.java dspace-1_5-with-shib/dspace-api/src/main/java/au/edu/mq/melcoe/mams/dspace/authenticate/ShibAuthentication.java
   • • dspace-1_5-with-shib.orig/dspace-api/src/main/java/au/edu/mq/melcoe/mams/dspace/authenticate/ShibAuthentication.java 2009-03-27 10:46:18.000000000 -0400
       +++ dspace-1_5-with-shib/dspace-api/src/main/java/au/edu/mq/melcoe/mams/dspace/authenticate/ShibAuthentication.java 2009-03-27 11:09:21.000000000 -0400
       @@ -59,6 +59,7 @@

boolean isUsingTomcatUser = ConfigurationManager.getBooleanProperty("authentication.shib.email-use-tomcat-remote-user");
String emailHeader = ConfigurationManager.getProperty("authentication.shib.email-header");
+String emailDefault = ConfigurationManager.getProperty("authentication.shib.email-default");

String email = null;

@@ -82,6 +83,11 @@
EPerson p = context.getCurrentUser();
if(p != null) email = p.getEmail();
}
+
+//Check to see if they provided a default account
+if(email == null && emailDefault != null)

if(email == null){
log.error("No email is given, you're denied access by Shib, please release email address");

from dspace.

mdiggory said:

I get the sense this either cannot be used with "auto registration" of the user account, or its going to appear that all shib authenticated users will be mapped to the same EPerson in DSpace?

Mark

from dspace.

eshicks said:

The patch that Keith posted is mine. Please bear in mind that I'm only about 3 days or so into doing anything with DSpace so side-effects are possible if there are non-obvious interactions between ShibAuthentication.java and the standard login code.

If the account doesn't exist and auto reg is turned on then it will register it. Therefore, any account you use as the default should already exist and have no more permissions than what you would give someone that you know absolutely nothing about other than that they're able to authenticate against Shib. Determining whether or not we can lock an account down sufficiently and, if not, what code changes would be required to do so is something I'd planned to start looking into next week.

The additional if clause was put at the end of the chain so it would only be used if both email-default was defined and all other possible credential sources had failed. If 'email' has been populated by something else, it won't evaluate to null and be overwritten.

from dspace.

bliong said:

For the [email protected], yes that additional patch seems to be OK. Its usage, IMHO, may not be advisable since your users should be able to be identified one way or another (e.g. rather than grouping all users into one single account), but perhaps in your situation that was warranted...

Another approach of supporting that would be to use the mod_header of apache to set the header value of the email when no such email is being released. For example something along the line of:

SetEnvIf EMAIL ".+" EMAIL_IS_SET
Header add EMAIL "[email protected]" env=EMAIL_IS_SET

Do you have special use-cases for locking down account? As in, why would a particular DSpace user being denied access? There are mechanisms in shibboleth to deny access prior it hits DSpace, that would be a way to do it in my opinion. This blacklisting can add interesting twist...

Do you have the patch for scoped affiliation? Otherwise adding authentication.shib.role.remove-scoping = true (defaulted to false) can easily be done on the mapping code.

Another item for future development on this patch is to integrate NetID, as an alternative to the email for the EPerson identifier.

from dspace.

mdiggory said:

Theres a way to do this without generating EPerson Accounts, the IPAuthenticator is able to do special groups without generating individual accounts. This should be the same behavior in this case as well.

Mark

from dspace.

mdiggory said:

P.S. Stuart and Kieth, kudos on assisting on this issue. We appreciate it!

from dspace.

mdiggory said:

Here is a quick patch that may work to enable successful authentication of an anonymous shibboleth user when the email address is absent.

Index: dspace-api/src/main/java/org/dspace/authenticate/ShibAuthentication.java
===================================================================
— dspace-api/src/main/java/org/dspace/authenticate/ShibAuthentication.java (revision 3642)
+++ dspace-api/src/main/java/org/dspace/authenticate/ShibAuthentication.java (working copy)
@@ -120,9 +120,17 @@

if (email == null)
{

• log
• .error("No email is given, you're denied access by Shib, please release email address");
• return AuthenticationMethod.BAD_ARGS;
  + if(ConfigurationManager.getBooleanProperty("authentication.shib.anonymous-allowed"))
  + { +log.info(LogManager.getHeader(context, "anonymous","shibboleth")); +return AuthenticationMethod.SUCCESS; + }

  + else
  +

  { +log.error("No email is given, you're denied access by Shib, please release email address"); +return AuthenticationMethod.BAD_ARGS; + }

  +
  }

email = email.toLowerCase();
Index: dspace/config/dspace.cfg
===================================================================
— dspace/config/dspace.cfg (revision 3642)
+++ dspace/config/dspace.cfg (working copy)
@@ -291,13 +291,15 @@

1. for installation detail.
   #
2. DSpace requires email as user's credential. There are 2 ways of providing
   1. email to DSpace:
      +# email to DSpace and 1 alterative if it is absent:
3. 1) by explicitly specifying to the user which attribute (header)
4. carries the email address.
5. 2) by turning on the user-email-using-tomcat=true which means
6. the software will try to acquire the user's email from Tomcat
   1. The first option takes PRECEDENCE when specified. Both options can
   2. be enabled to allow fallback.
      +# The first option takes PRECEDENCE when specified. Both options can
      +# be enabled to allow fallback.
      +# 3) by turning on the anonymous-allowed=true, if no email can be determined
      +# the user will still be allowed in the system and special groups assigned

1. this option below specifies that the email comes from the mentioned header.
2. The value is CASE-Sensitive.
   @@ -314,6 +316,10 @@
3. this option below forces the software to acquire the email from Tomcat.
   authentication.shib.email-use-tomcat-remote-user = true

+# this option will allow requests without email header ot tomcat user to
+# pass into DSpace authenticated and acquire mapped groups
+authentication.shib.anonymous-allowed = false
+

1. should we allow new users to be registered automtically
2. if the IdP provides sufficient info (and user not exists in DSpace)
   authentication.shib.autoregister = true

from dspace.

bliong said:

That's a cool feature! Didn't know that creation of an EPerson is totally optional

I wonder whatever happened to the calls like context.getCurrentUser()? Will check that out later, just out of curiosity....

from dspace.

mdiggory said:

Actually, I don't think this will work further up the call stack in the XMLUI AuthenticationUtil and AuthenticateAction. It may work with the JSPUI, in the JSPUI, theres no calls to get the Contexts EPerson up in the DSpaceServlet or other AuthenticationServlets.

I'm going to consider this further as well. It points out a shortcoming in how the XMLUI is testing for an Authenticated user.

from dspace.

mdiggory said:

There are two things going on here that I think we should consider.

A.) Non-Implicit Authentication as a Shibboleth User when accessing a protected resource (much like Password Authentication) requires reentry through AuthenticationAction or ShibServlet to correctly process the shib user into an EPerson

B.) Implicit Resolution of Special Groups when a User has Shibboleth headers present in the request (or Shib groups are in users session) is much like IPAddressAuthenticator and happens on every request, this can be annoymous.

My repsonse about about AuthenitcateAction is incorrect, in XMLUI ShibbolethAction is the controller for verifying that the shibboleth return trip is porcessed correctly. This igves us a chance to manage the lack of an EPerson differently in this class.

At this point ShibbolethAction, expecting this to be a "non-implicit" authentication process forces (A) and requires a Context/EPerson as a result.

We've been having authenitcation/authorization discussion in the 2.0 group as well. There are actually 3 call processes for Authenication/Authorization

1.) Authenticate User Credentials "AuthenticationManager.authenticate"

2.) Get User Groups "AuthenitcationManaer.getSpecialGroups"

3.) Authorize User+Groups "AuthorizationManager.authorize"

AuthenticationMethods mush the first 2 together and make it difficult to operate them separately. (2) and (3) are used in IP Authenitcation while (1) returns BAD_ARGS.

We might try altering ShibbolethAction to not require an EPerson if the configuration allows for annonymous shibboleth authentication, this might be all thats required to make this work with the XMLUI as well.

from dspace.

kevin_melcoe said:

This is the patch to fix the issue about the scoped role header.

Problem: If your SP only provide scoped role header, like scopedAffiliation. This patch can unscope it for you to make it ready for shib role mapping.

How to use it: patch this against your source, then
in dspace/config/dspace.cfg, there is an additional option

authentication.shib.role-header.ignore-scope=false

all you need to do is change the value to true.

from dspace.

kevin_melcoe said:

Sorry, please ignore the first patch, use this new version. This one will be error free to the mixture of both scoped and unscoped role headers from different idps.

from dspace.

eshicks said:

On further testing, I found that Mark was right about one of the side-effects of the patch Keith submitted on my behalf. It, in fact, does not play nicely with the stackable auth and, therefore, would only be useful in situations where Shib is the /only/ login method used. Also, none of this changes the fact that a special groups solution similar to IP auth would probably be a much cleaner way of dealing with an anonymous Shib user.

from dspace.

eshicks said:

Regarding the ignore scoping patch, there may be a problem in cases where the affiliation attribute returns multiple values. I believe that this code will need to be moved down a little into the section within the StringTokenizer while loop. I've submitted a v3 patch above to address this. Please have a look.

from dspace.

bliong said:

Stuart, thanks for that v3 patch, yes that's a better & correct place for it.

from dspace.

bollini said:

Just closing this issue because the main Shibboleth issue has been addressed.
Moving the improvements related to Scoped Role Header and Anonymous login in the new DS-187 issue.

from dspace.

mdiggory said:

Commited the v3 patch, thank you.

from dspace.

Is related to: DS-187

from dspace.

Depends on: DS-109

from dspace.