DMPRoadmap / roadmap

DCC/UC3 collaboration for a data management planning tool
MIT License
106 stars 109 forks source link

issues with shibboleth login when served behind reverse proxy #3018

Open nicolasfranck opened 3 years ago

nicolasfranck commented 3 years ago

Please complete the following fields as applicable:

What version of the DMPRoadmap code are you running? (e.g. v2.2.0)

3.0.2

behaviour:

If you're using roadmap behind a reverse proxy, and let mod_shib in apache pass all user attributes via the http headers, you'll end up with a problem: all values read as "ASCII-8BIT" (which is actually ISO-8859-1), because that is the expected encoding in http headers, and omniauth-shibboleth does not even try to take this into account, although the shibboleth documentation clearly states that it should.

Result: the code halts when it tries to store attrs into the Identifier:

Encoding::UndefinedConversionError ("\xC3" from ASCII-8BIT to UTF-8):

which happens here

I am not sure if this is problematic when storing the name and first_name into the user record.

If you want to see how this happens try the following:

h = { name: "café" }
h[:name].force_encoding("ASCII-8BIT")
h.to_json

I know, roadmap is not the cause of this, but maybe you have encountered users that experienced this problem? Any idea on how to solve this?

briri commented 3 years ago

Hi @nicolasfranck,

Are you using puma or a different app server? We have the following apache config for our Shib SP which is forwarding the information over correctly:

    <Location /Shibboleth.sso>
      AuthType shibboleth
      require shibboleth
      SSLRequireSSL
    </Location>

    <Location /users/auth/shibboleth/callback>
      AuthType shibboleth
      require shibboleth
      ShibUseHeaders On
      SSLRequireSSL
    </Location>
nicolasfranck commented 3 years ago

I use puma as backend server. The shibboleth parameters are passed by HTTP header as shown in your configuration.

I "fixed" this by overriding this function call in omniauth-shibboleth:

https://github.com/DMPbelgium/roadmap/blob/master/config/initializers/devise_ugent.rb#L66

the gem seems to be abandoned? They do not react to other issues as well..

This is not a roadmap issue, but one might stumble upon this problem. Have you tested this against names with non English characters in it (accents and others)?

briri commented 3 years ago

Yes, we have shib generated user accounts with non-English characters (e.g. ç, ö, ñ, etc.)

It could be that the identity providers you are receiving the user info from package things up differently. We use the InCommon federation and EduGain which standardize the response.

briri commented 3 years ago

The gem does appear to have been abandoned :/

This will be problematic going forward if Shibboleth changes in the future.

The gem's owner has only had 6 contributions (to public repos) in the past year so I'm thinking they will not continue support in the near future.

I'm reluctant to take on ownership of the repository (or a fork of it) since we have such limited bandwidth. What do you think @raycarrick-ed and @nicolasfranck?

The current repo has not been updated in 4 years and has several outstanding issues and a PR. I also reviewed the forks and they have no new commits.

Many of the DMPRoadmap installations rely on Shibboleth integration, so it may be worthwhile to commit to supporting a new fork of the gem. An alternate option would be to migrate away from Shibboleth integration and over to ORCID. This would require serious policy discussions for each installation and a willingness to disrupt the User login/account creation workflows.